LoLoCoJr

We sold our apartment a few weeks before the credit crunch hit hard, phew! We already purchased a new house (new construction) last year. Last week we had to move out of apartment. Unfortunately the new house is not yet finished. Well it is, but the utility companies still need to their stuff and the municipality needs to finish the roads, in that order. the new location is just 1 block away because we really like Osdorp and wanted to stay in or around Amsterdam.

In the meantime we'll be moving between my sis and brother-in-law. c'mon waternet, move!

After stearing clear of Apache2 for the last year for all production servers I'm now ready to give it another try, thanks to Phusion's Passenger. I've grown really tired of setting up god scripts for all environments and fighting mongrel's pidfile suckage.

Far too many times have things failed because of a dead worker in the cluster or some stale or (even worse!) non-existent pidfiles on the system. Mongrel has served well, but it's time to look for something better.

A typical setup I use is nginx as the front-end server doing all static content while a pack of mongrels is handling the Rails requests through reverse proxy. nginx is also very important for reproxying requests, where content is streamed from another internal server over the front facing servers. In most of the Rails app I'm writing I have to deal with very large files (audio, video) so reproxy is essential if you want to have any sort of performance on a reasonable budget. Since Apache2 lacks reproxy support (AFAIK, please prove me wrong!) I really want to keep nginx as the front-end server and then do the Rails handling with Apache2 + Passenger through reverse proxy.

I've come a cross a couple of posts on this very topic.

I'll be doing some heavy development and testing over the next couple of days with this setup, will post my findings...

Article was updated. See below, the Option software should work out-of-the-box for Leopard 10.5.5 or higher!

Last week I received my HSDPA/UMTS/GPRS card from XS4ALL. After the major ADSL outtage fiasco It really dawned on me that not having net access for a day actually costs more than the whole wireless plan per month! Think about it, as I telecommute 4 days in the week I would actually have to drive to the office to get work done (luckily our offices were spared from the outtage!), the parking money alone is almost more than the whole plan (go Amsterdam!). Enough justification for the new toy. It arrrived, weeh!

The specs clearly state it should work fine an OS X 10.3.x or later. Unfortunatly the instructions from XS4ALL are completely useless when you are running on Leopard. It probably has more to do with Option and their drivers or OS X and its (shoddy) support for the hardware which is the Globetrotter Express 7.2 card btw.

After 2 hours of fiddling with various releases of drivers and trying all the the blog tricks from people around the world with the same card I was almost ready to give up when I stumbled upon this HOWTO for Linux. As always Linux to the rescue. It turns out the card is basically just a glorified modem and you just need the right AT commands and some pppd magic to get things going.. Grrrreat, familiar territory! (I have to confess, OS X dumbs you down, so having things breaking once in a while is gooooood!!)

After some searching I found the following devices:



Cool, connecting to the cu.GT HSDPA Modem tty device should work:

$ screen /dev/cu.GT\ HSDPA\ Modem
AT<return>
OK

Yes! The device is alive. Now, to find out if there is some combination of settings in the Network Preferences that actually make it work. Some further blogging shows that the Option » GSM configurations comes closest to what this cards expects.

Wow, 5 entries for the card. Just pick one which gives you a modem icon. Then choose "Advanced..." and pick model "Option" and then choose "GSM" (should be the only option anyway). In the "APN" field you should fill in "umts.xs4all.nl".

Back to the connection setup screen. Fill in "*99***1#" in the Telephone number field, although this is not strictly needed I think. Fill in your XS4ALL username and password in the field. Note: even though XS4ALL states you don't need your account password to connect at least I had to fill in the correct password. The pppd connection would immediately be dropped otherwise. Also, select the "Show modem status in menu bar" for convenience.

Now it's time to connect. Select the "Connect Globetrotter HSDPA Modem" from the dropdown modem menu bar. You should see the modem connecting..

You can open up the console and monitor "system.log" and also filter on "pppd" to see the relevant lines

If everything went well you should now be connected to the Internet and have an IP address in the mobile.xs4all.nl range. Enjoy! I have the Mobile start plan which currently gives you 768/128 and I'm happy to say that from all the locations I've tried so far in and around Amsterdam I always get the full bandwidth. Ping times are also quite reasonable, most of the time around 90ms, sometimes in the 300ms range (perhaps when it drops back to GPRS?). Anyway, SSH and web browsing are perfectly doable. Next up.. OpenVPN setup... another day..

Update: Forgot to mention this, but you need to disable the PIN on your SIM card for all of this to work. You can do this by putting it in your mobile phone and disable it using the phone's config menus.

Update 2: After upgrading Leopard to 10.5.5 the above instructions were completely invalidated for me. However!!! The GT Mac Connect 1.3d0-164 software (downloadable from Option worked for me out of the box, where previously it failed mysteriously!! Try it!!

My first Rails 2.0.x project has been running in production for a couple of months now. It's the website for KRO's "De TV Flat", a children/teens program airing every Saturday on dutch national television around 9am (channel Nederland 3) untill the beginning of summer. I'm very proud to actually get one of my projects on TV! The premise is basically "Youtube for kids" with the chance of getting your self-made video's broadcasted on TV!

I really like the instructional video's made by the TVFlat crew, very helpfull tips for creating your own video content.

• Linux
• Nginx HTTP server
• Mongrel
• MogileFS clustered storage
• Rails 2.0.2
• Merb 0.54 for critical code paths, beats Rails to a pulp when it comes to roundtrip times
• Memcached
• MySQL
• Lucene
• mplayer / ffmpeg / faac for transcoding, direct broadcast quality feeds are generated!
• Flash video

Hope I can find some time later on to write a bit about the different parts.. anyway, go check it out!

It has been very quiet on this blog, but not so much here at home. On March 2nd 2008 our daughter Mia Morena Elisabeth Lo-A-Foe was born.

Mia is a healthy baby girl who regularly eats every 3 hours, around the clock. After 6 weeks we're completely comfortable with the new schedule. Andrew loves his baby sister very much but still pokes here once in a while just to see what's she's made of :)

P.S. Better late than never: Happy 2008!!!

So I'm rewriting yet another subsystem which consists of a mismash of several languages and programmer ego's (hardcore C being the largest one, aargh) to what else .. Ruby. Everythings going smoothly. Every line of Ruby code replaces about 10 lines of "put other language here" cruft. Life couldn't be more beautiful. But then I hit the wall, the Java wall. Here I'm confronted with a full enterprisy Service Manager complete with dependencies on Java-only libs. Now what? I could rewrite the whole thing in Ruby. But then there would be 2 implementations of the same thing to maintain, not to mention reading through Java code, bad.

Enter JRuby. Since the main code blob of this project is captured in a Mongrel plugin I thought about just deploying the whole of Mongrel on JRuby. Unfortunately JRuby Mongrel support was not there yet (Mongrel 1.1 supports JRuby). So the next best thing was to build some kind bridge between JRuby and Ruby + Mongrel + Plugin. Distributed Ruby (DRb) is a perfect fit:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

#
# server.rb (this)
# jars/big-bad-service.jar
#
APP_ROOT = File.join(File.dirname(__FILE__), '.')

require 'java'
require 'drb'

require "#{APP_ROOT}/jars/big-bad-service.jar"

BigBadService = com.blah.BigBadService

class JRubyServer
  def initialize
    @bbs = BigBadService.new
    @bbs.initialize_service
  end

  def bbs_call(param) 
     @bbs.bbs_call(param)
  end
end

if __FILE__ == $0
  DRb.start_service 'druby://127.0.0.1:6666', JRubyServer.new
  DRb.thread.join
end

Execute like ruby server.rb, and then you'll have the server listening on port 6666 of localhost. Nice, we can now call our Java service from other Ruby code with this simple snippet:

1
2
3
4
5
6

require 'drb'
DRb.start_service

java_bbs = DRbObject.new(nil, 'druby://127.0.0.1:6666')

puts  java_bbs.bbs_call("Whack!") #=> "Whacked!"

Kewl! Except for one big caveat. As of JRuby 1.0.x Java objects cannot be marshalled correctly so passing them to your Ruby code will cause all sorts of interesting hangs and crashes when you access them concurrently (see JRUBY-1235). Untill JRuby 1.1 is out you can synchronize all your calls to JRuby and making sure you convert any results to proper Ruby objects before using them elsewhere in your Ruby code.

This hack saved me loads of (Java hacking) time!