One of the drawbacks of EC2 is that there are no static IPs to be had, so short of using an external (to ec2) solution, the only way to have redundant load balancers is to use dns round robin. If a load balancer instance goes down, we should ideally remove it from the round robin so that clients don’t continue to use the dead IP.
I’m in the process of writing some capistrano recipes to make deploying to Amazon’s Elastic Compute Cloud (ec2) easier. Since I’m making this project available for general consumption, I wanted a way to make it easy for someone to try it out without having to check something into source control. (more…)
Learned a little bit about scRUBYt! today (damn thats hard to type!).
It looks like a pretty cool way to do web crawlers. To use it, you define a “learning” crawler using the scRUBYt! DSL, which combined with the actual site at a specific point in time, creates the real crawler to do the dirty work - essentially, example text gets converted to xpath expressions. The cool thing about this is that when the site changes, one has to do minimal changes to create a new working crawler, not to mention that creating the crawler in the first place is a lot easier.
I ran into some problems trying to setup a custom logger in rails which I thought I would share to ease someone else’s pain. Everything I read said that to setup a custom logger instance, I should set config.logger in my environment.rb, e.g.
environment.rb:
config.logger = MyLogger.new(config.log_path)
However, I just could not get this to have any effect! It turns out that this was because I was starting up my server using script/server using mongrel. Using “script/server webrick”, or “mongrel_rails start” worked just fine.
I think this is caused by code in the mongrel.rb file that script/server uses which loads just the logging environment (but not my environment) in order to figure out which log file to tail
railties/lib/server/mongrel.rb:
require 'initializer'
Rails::Initializer.run(:initialize_logger)
Loading the environment here causes the RAILS_DEFAULT_LOGGER constant to get set, and thus when my config finally gets loaded when mongrel itself starts up, the config.logger I set gets ignored as the rails init code does nothing if RAILS_DEFAULT_LOGGER is set:
railties/lib/initializer.rb:
def initialize_logger
# if the environment has explicitly defined a logger, use it
return if defined?(RAILS_DEFAULT_LOGGER)
...
end
The patch on this bug report seems related, but didn’t fix my problem.
I’m too much a rails newb to figure out the right way to patch this, hopefully someone with more of a clue will see this blog entry and submit a patch 
After viewing this presentation I now have a much better understanding of how the Java Memory Model works, and how important the synchronized and volatile keywords are when sharing variables across multiple threads. Previously I have only really used the synchronized keyword as a critical section, and never really accounted for how it protects against shared data access.