Eli Miller

Getting postgresql and git to play nice on Mac OS X

noreply@blogger.com (Elijah Miller) — Thu, 10 Apr 2008 03:09:00 +0000

If you installed postgresql83 using macports, you may run into some trouble building the apr dependency.


In file included from misc/unix/rand.c:39:
/opt/local/include/uuid.h:94: error: conflicting types for 'uuid_t'
/usr/include/unistd.h:133: error: previous declaration of 'uuid_t' was here

uuid_t is defined in the port of apr(git dependency) and ossp-uuid(postgresql83 dependency). Simply uninstalling postgresql83 and ossp-uuid does not solve the problem. Apparently macports is happy to let one port overwrite files from another without a huge red flag. The commands below should do everything you need.


port uninstall postgresql83-server postgresql83 ossp-uuid
port clean apr
port install git-core +svn
port install postgresql83-server



How many HTML elements can you name in 5 minutes?
noreply@blogger.com (Elijah Miller) — Tue, 18 Dec 2007 14:22:00 +0000
51

I missed a lot of easy ones still. . . 


Easily display svn revision
noreply@blogger.com (Elijah Miller) — Sat, 15 Sep 2007 17:50:00 +0000
In one of my projects we'll occasionally have production servers that don't get restarted on a deploy and this is a nightmare when it comes to tracking down bugs. Following the easy svn info parsing with YAML, we create a constant that holds our revision that gets set only when the server is starting.

Put this in your environment.rb:

Revision = YAML::load(`svn info $RAILS_ROOT`)["Revision"]

We can then easily display it along with other debug information to certain user accounts.

Note: since this is set in environment.rb it will only be set once at application startup. This is great for performance but will show stale revision information in development mode. This should be a non-issue for everyone since this exists solely for debugging production server failed restarts.


Less is more with redgreen
noreply@blogger.com (Elijah Miller) — Sun, 19 Aug 2007 08:10:00 +0000
When running tests, it's normal to put the most basic functionality tests at the begining, but when you run a test with a lot of errors you'll end up with more complex end tests staring you in the face. I used to try to solve what was in front of me, so I would start at the end. This is obviously harder and basically a waste of time, so my next move was to run the test case and pipe it through less.

ruby test.rb | less


That worked perfectly fine until I installed redgreen to highlight my successes and failures. Now less ends up escaping all of the color codes and I'm left with a messy screen of numbers and reversed colors.

ruby test.rb | less -R


Shouldn't less default to displaying color codes? Alias that!


"duck typing made easy".gsub(/y$/, 'ier')
noreply@blogger.com (Elijah Miller) — Thu, 21 Jun 2007 05:32:00 +0000
I was reading through the ever amazing Beast Forum code and came across this bit in distance_of_time_in_words method of application helper.

from_time = from_time.to_time if from_time.respond_to?(:to_time)


Duck typing is great, and you should use it when possible, but look at how ugly it makes things. You have to type to_time twice, once as a method and once as a symbol. The object has to be typed twice as well, maybe if I had some fancy Textmate snippet or something to help me. Or some slightly clever Ruby code.

def method_missing(method, *args)
  return super unless method.to_s =~ /_if_respond_to$/
  method_name = method.to_s.gsub(/_if_respond_to$/, '')
  return self unless self.respond_to? method_name
  return self.send(method_name)
end

Now we can easily do:

from_time.to_time_if_respond_to
# => Thu Jun 20 17:25:13 -0400 2007

123.to_s_if_respond_to
# => "123"


# What if it doesn't respond_to? your method?
123.to_roman_numerals_if_respond_to
# => 123




Proper cache expiry with after_commit
noreply@blogger.com (Elijah Miller) — Sat, 16 Jun 2007 04:11:00 +0000
I'm using cache_fu to handle all of my ActiveRecord memcaching these days. It is an amazingly simple and powerful addition to AR to easily use memcached, and I highly recommend it. I've really only had this one problem with it, the suggested cache expiry is:

after_save :expire_cache
after_destroy :expire_cache

I noticed a troubling thing about using after_save to expire caches, after_save is still within the transaction that save is automatically wrapped in. I assume this is to protect against an error during the after_save call, so you can roll back the database to it's previous state. When you're expiring caches though, you need to make sure the underlying data is actually changed before you expire the cache, otherwise you risk caching the old data before the new data is committed. This could go unnoticed, but if you're using optimistic locking, it raises exceptions when you try to save stale data.

To be a little more clear, a normal post.save looks something like this:

SQL (0.000363)   BEGIN
Post Update (0.000572)   UPDATE posts SET "created_at" = '2007-06-13 21:15:40.212720',
"last_edited_at" = NULL, "user_id" = 8, "body" = 'hello world', "updated_at" = '2007-06-16
18:45:24.412415', "topic_id" = 7 WHERE "id" = 11
SQL (0.000893)   COMMIT

Notice how everything is wrapped nicely with a BEGIN and COMMIT.

Now after adding an after_save method that simply logs "Expire Cache!" we can see the order of events:

SQL (0.000363)   BEGIN
Post Update (0.000591)   UPDATE posts SET "created_at" = '2007-06-13 21:15:40.212720',
"last_edited_at" = NULL, "user_id" = 8, "body" = 'hello world', "updated_at" = '2007-06-16
18:49:49.869814', "topic_id" = 7 WHERE "id" = 11
Expire Cache!
SQL (0.000874)   COMMIT

If we imagine that Expire Cache! took 10 seconds to run, we can see that there is a measurable amount of time between Expire Cache! and the COMMIT. Database servers don't want to hand out incomplete or just wrong data, so they will serve the "old" data during this time, switching to the UPDATEd data after the COMMIT. If this post gets requested again during that 10 second window, it will be cached as the "old" data. Now we have a database with one value, and a cache with another, but they both think they have the correct data. We need to move the expire cache operation outside of the commit to remove this problem area.

Enter after_commit

We add a callback right after any save or destroy operation, which does the operation and then calls after_commit. Theoretically this works with update_attribute and any other AcitveRecord write operation, but I haven't fully tested those cases.

module ActiveRecord
  class Base

    class << self


      # Class methods


      def after_commit(*callbacks, &block)
        callbacks << block if block_given?
        write_inheritable_array(:after_commit, callbacks)
      end

    end


    # Instance Methods


    def save_with_after_commit_callback(*args)
      value = save_without_after_commit_callback(args)
      callback(:after_commit)
      return value
    end
    alias_method_chain :save, :after_commit_callback


    def save_with_after_commit_callback!(*args)
      value = save_without_after_commit_callback!
      callback(:after_commit)
      return value
    end
    alias_method_chain :save!, :after_commit_callback


    def destroy_with_after_commit_callback
      value = destroy_without_after_commit_callback
      callback(:after_commit)
      return value
    end
    alias_method_chain :destroy, :after_commit_callback

  end
end

Since we wrapped save and destroy to call after_commit, we need only add one callback to expire caches now:

after_commit :expire_cache

And here is the log:

SQL (0.000365)   BEGIN
Post Update (0.000772)   UPDATE posts SET "created_at" = '2007-06-13 21:15:40.212720',
"last_edited_at" = NULL, "user_id" = 8, "body" = 'hello world', "updated_at" = '2007-06-16
19:05:55.108429', "topic_id" = 7 WHERE "id" = 11
SQL (0.000929)   COMMIT
Expire Cache!


assert_changes
noreply@blogger.com (Elijah Miller) — Fri, 04 May 2007 17:07:00 +0000
Update: I have a patch awaiting approval on test-spec to add should.differ, change, increase and decrease. These read a lot better than the assert_difference/change methods.

# Checks multiple methods on object before and after the block asserting that there is
# a different value returned for each method. This is especially good for non-numeric fields.
def assert_changes(object, methods = nil)
  methods = [methods] unless methods.is_a? Array

  initial_values = {}
  for method in methods
    initial_values[method] = object.send(method)
  end


  yield
  object.reload if object.respond_to? :reload


  for method in methods
    assert_not_equal initial_values[method], object.send(method), "#{object}##{method}"
  end
end

alias assert_change assert_changes


Static Controller Shortcuts
noreply@blogger.com (Elijah Miller) — Thu, 25 Jan 2007 20:02:00 +0000
Update: Gabe da Silveira is doing something similar at Routing Nested Static Content in Rails.


The first tidbit.

Most sites tend to have at least 4+ static pages. Typically: about us, user agreement, contact, privacy policy and 404. I'll assume you already have a static controller that holds these view templates. Instead of making a bunch of static routes from "/about" to "views/static/about", you can add one simple to direct everything that doesn't go to an existing controller to your static controller.

# Add this after your default route ':controller/:action/:id'
map.static ':action/', :controller=>'static'

Since the Rails default route will only match a url if the controller name exists, /about will not match and it will be displayed by our new static route. For bonus points this is a named route and you can use this code to generate the url for the about page:

static_url(:action => :about)


'Bout time.
noreply@blogger.com (Elijah Miller) — Thu, 25 Jan 2007 19:33:00 +0000
Today I decided to resurrect my blogger account from my Informatics days at IU Bloomington, and actually do something worthwhile with it. So here is the story that starts this saga.

Last year I was contracted to code a pretty basic social networking site in Ruby on Rails. Although my main competency was PHP, the client was certain that they wanted it done with Rails. This was fine with me, I had read a few articles about Rails and knew that it had a lot of features that I've been dying for in PHP.

So over the next few months I learned Ruby and Rails and implemented a few iterations of the site. Since Rails is a relative newcomer, I was purchasing lots of books on it and Ruby while subscribing to many ruby news/blog feeds. All the while I struggled through all the deployment issues, multiple hosts and rails version change breaks. If it weren't for the sheer joy of coding Ruby and using Rails, I am sure I would have stopped after a month.

Anyhow, I've come to find that the Rails documentation does go a long way, but I learned the most from reading the weblogs of people who use Rails daily. There is a project underway to improve not only the documentation, but the way the documentation is created. I will happily contribute to that once it is available, but until then I will hopefully be sharing bits of Ruby and Rails wisdom on this blog like those before me.