Just a quick post to help people enable this. Go to http://www.iphone-notes.de/mobileconfig/ and send yourself the tethering settings.

Next go to Settings > General > Network > Cellular Data Network and enter the following settings for MMS:

APN: portalmmm.nl

MMSC: http://mp.mobiel.kpn/mmsc

MMS Proxy: 10.10.100.20:5080

Leave all of the other fields blank, exit the settings app and restart your iPhone. Have fun!

Reception is a rails frontend for transmission-daemon for people who want to automate torrent downloading.

In contrast to Clutch, Reception does not just download your torrents, it also automates the finding and filtering of them, so that you won't have to.

This is version 1.0 so there are still things to do. In the future Reception will be a gem, automate the cron installation and have automated categorization of downloaded files.

So if you are feeling adventurous or extremely lazy, please head over to http://github.com/barttenbrinke/reception/tree/master

Recently we hired Martin Laksman from Undogo to help us with some visuals.

We wanted cartoons that would identify our main user groups so we could use them in presentations, course material and release notes. We wanted four distinct characters: Managers, Planners, Nurses and Clients. These are the characters he came up with.

We've been slowly integrating them into our communication with customers and we've had very positive responses to them. They seem to be right on the mark!

Now...who wants one of these on a t-shirt :)?

If there is one thing I learned from Euruko 2009, it is that more and more people are using Ruby as a strategy over strategy tool. They are using ruby as a tool to control other tools. This varied from generating music, creating video-games to controlling complex phone switching systems. Also Ruby seems to be becoming the tool to develop your new cloud hosted application in.

The big question is why people are using Ruby to do this? They could have been doing this for years and just as easily have used any other language.

One explanation of that this is just the next level in programming. Right now there are thousands of very powerful and focussed libraries and applications available. This means that almost any desired functionality is available off the shelf. As ruby is used by the leading edge of programmers, these will be first to acknowledge this and try to combine these libraries into something they need. Ruby is just being abused, as it is easy.

Another explanation is that ruby is a very good language to express your strategies in. "It's all about the API!" is an expression used more and more in Ruby. What is meant by this is that Ruby encourages and provides you with more and more powerful API's. The near language type of syntax also lets you express complex behavior more easily.

So what will the future hold? At the moment more and more C and C++ libraries are getting ruby bindings. This might become even more easier by the introduction of D. Also JRuby and ironruby are making the integration of other platforms a piece of cake. On the web-side: RSS, XML, SOAP and ActiveResource are all in the ruby dictionary, so the options are pretty much endless.

What will be your next strategy?

Last week we finally had use for New Relic's RPM service which we have been using for the last couple of months. Our cluster is approaching it's application limit and we are using RPM to monitor it closely.

I found myself needing a quick glance of how our apps are doing wherever I am. Therefore I started work on a small app that would gather and display the RPM statistics using their new API.

It took me about half a day to hack the current 1.0 version together. I have submitted it to the AppStore and it is pending approval. The basic functionality is kept very basic (to scratch my own itch):

• Show basic traffic light stats for all applications
• Shake to refresh
• Easy entry of license key, mail yourself a memento://key_here link
• Somewhat bareable UI
• Free

Below is a screenshot of how it looks in the simulator. I might be adding a single drill-down view to show the actual numbers if I feel it's missing as I use it :)

Update (2009-05-07): App got rejected because I didn't provide a demo newrelic account. So i created a bogus account and re-submitted...Patience

Update (2009-05-14): App got accepted and is in the AppStore

Note: Copy pasting an URL in Mail.app to generate a memento link won't work. If you put your license key in the box below, press the button and copy/paste the link in Mail.app it should all go fine!

Enter your key in the box, and press convert!

Just a quick post. Since our annual fair is coming up next week I decided the Moves login screen could use some new paint. I also added a banner to clearly indicate the demo versions we have running. I just wanted to share the images and see what you guys think!

Old screen


New screen

It is always nice to see that somebody did the work you were planning to do! Gettext has a new implementation that is threadsafe, Rails 2 compatible and FAST!

Fast Gettext and Gettext i18n Rails

Why won't I use the standard i18n?

• It's slow
• It's far from feature complete
• There are no translator tools available
• I really do not want to change the 5000+ strings currently in my application.

Also the new Fastgettext promisses a nice speed bump.

50000 translations

Baseline: (doing nothing in a loop)
0.390000s / 2904K

Ideal: (primitive Hash lookup)
1.010000s / 3016K <-> 1.040000s / 3016K

FastGettext:
1.860000s / 3040K <-> 1.830000s / 3040K

GetText:
14.880000s / 5816K <-> 14.810000s / 6008K

Rails I18n Simple:
31.200000s / 10044K

Yesterday I talked about patching ActiveSupport to enable the use of alternative XML parsers. Today, I took the time and patched xmlmini to allow alternative XML parsers.

2084-alternative-xml-parsers-support-in-activesupport-for-activeresource

I implemented a REXML and a LibXML version, but any other XML parsers can now be added quite easily. It falls back to the old ruby implementation (REXML) if no other parsers are available.

Happy parsing!

As I am apparently one of the very few people that actually uses ActiveResource in a big production environment, I took the liberty of creating some small but essential patches that ActiveResource really needs it it ever wants to become a standard.

Namespacing

Activeresource works great if you have a two apps with exactly the same datamodel or two apps with completely different datamodels. If you have a shared model name (say Client) with different attributes, then you up the proverbial estuary with no mechanical means of propulsion. By having a namespace in front of the external client, you will be able to reference it as ExternalClient and all the magic works again!

2069-namespacing-for-activeresource

Gzip support

ActiveResource uses xml as its language, but it does not support gzip. This is all fun if you have 10 clients, but if you have 10000... So I build the following patch:

2070-gzip-deflate-support-for-activeresource

Faster XML

The last hurdle is that ActiveResource currently uses SimpleXML to do XML -> Hash translations. This is done in ActiveSupport::Conversions. The comment says this:

# TODO: Refactor this into something much cleaner that doesn't rely on XmlSimple

And that pretty much says it all. Currently ActiveSupport injects some extra functions into SimpleXML that do the magic. This is almost as ugly as it is slow. What is needed is that ActiveSupport will use something like LibXml trough Nokogiri if it is available and fallback on a full ruby version if necessary. Who wants to help me write a nice patch for that?

Oh yeah, please +1 :)