bricker

ARTICLES = %w[ and the a an of ]

class Book
  def title=(val)
    @title = val.split(" ").map.with_index do |s, i|
      (ARTICLES.include?(s) && i != 0) ? s : s.capitalize
    end.join(" ")
  end
end

bricker

def some_data_is_available?
  begin
    obj = data['a']['b']['c']
    obj && !obj.empty?
  rescue ArgumentError
    false
  end
end

bricker

            $.get("path/to/embed.js", function(e) {
              // ...
            }).fail(function(e) {
                console.log(e) // 200 status

            }).always(function() {
                console.log("always")

            })

bricker

class JobBase
  add_transaction_tracer :perform
end

class SomeJob < JobBase
  def self.perform
    # ...
  end
end

bricker

grails {
   mail {
      host = "smtp.correo.yahoo.es"
      port = 465
      username = "myuser"
      password = "mypassword"
      props = [ "mail.smtp.auth":"true",
                       "mail.smtp.socketFactory.port":"465",
                       "mail.smtp.socketFactory.class":"javax.net.ssl.SSLSocketFactory",
                       "mail.smtp.socketFactory.fallback":"false"  ]

bricker

# Protect against replication lag.
# This only works when looking up single objects, so lists
# may still be stale for a few seconds, but that's a reasonable tradeoff.
#
# This module protects against the (common) scenario where someone saves
# an article and is immediately redirected back to its edit or show page.
# If they just updated the object, the data they see on the next page
# will be old. Or, worse, if they just created the object, they'll just
# get a 404.
#

bricker

describe 'something' do
  let(:something) { Something.new }
  
  it 'is something' do
    $stdout.puts something #=> nil

    something = "Something"
  end
  
  it "is not something" do

bricker

Thinking Sphinx has some convenient tasks to manage searchd processes per-app. You can deploy multiple apps to a single server and have separate searchd processes for each one. This is great! What's not so great is figuring out how to monitor each one, while still retaining the normal functionality of the rake tasks.

"Just use [some monitoring software]!". Great idea. Except [some monitoring software] probably doesn't have a concept of "allow this service to be down while [some condition is true]". In our case, [some condition] is ts:rebuild. ts:rebuild is a convenience method to stop, index, and then restart searchd. It is a normal operation, necessary when you've made changes to your index schema (by adding, removing, or changing an attribute in your index definition).

The problematic flow that we're trying to solve looks like:

1. God.rb is monitoring searchd.
2. App user runs ts:rebuild, which stops searchd.
3. God.rb notices searchd has stopped running, and promptly restarts it (as it should, beca

bricker

app_host = if %w[ localhost 127.0.0.1 ].include?(app_db_config["host"]) ||
new_resource.loadbalanced == true
  #do something
end

bricker

chefbump() {
    for i
    do
        cd $i
        ruby -e 'c=File.read("metadata.rb");c.sub!(/^version.+$/) { |m| m.next };File.write("metadata.rb", c)' &&
        berks install && berks upload
        cd ../
    done
}