Fiat Developmentum

Links for 2009-12-29 [del.icio.us]

Wed, 30 Dec 2009 00:00:00 PST

Links for 2009-12-20 [del.icio.us]

Mon, 21 Dec 2009 00:00:00 PST

NoSQL with MySQL in Ruby - Friendly

Links for 2009-12-08 [del.icio.us]

Wed, 09 Dec 2009 00:00:00 PST

Production Rails Tuning with Passenger: PassengerMaxProcesses

Links for 2009-11-14 [del.icio.us]

Sun, 15 Nov 2009 00:00:00 PST

synergy-plus - Project Hosting on Google Code

Links for 2009-11-13 [del.icio.us]

Sat, 14 Nov 2009 00:00:00 PST

Review Board | Take the pain out of reviewing code

Links for 2009-11-12 [del.icio.us]

Fri, 13 Nov 2009 00:00:00 PST

The Go Programming Language

Links for 2009-11-09 [del.icio.us]

Tue, 10 Nov 2009 00:00:00 PST

Extracting data from iPhone backups

phil — Sun, 27 Sep 2009 01:03:25 +0000

I recently reset my iPhone in an attempt to clear up some weird issues I was having. It wasn’t until afterwards that I realized that I had forgotten to pull my photos off of the phone first. After doing some searching I discovered that the iPhone backup files are located at:

/Users//Library/Application Support/MobileSync/Backup

I then found the bkupextract.pl script that attempts to extract all of the sqlite3 databases from the backup files. I modified the script to also extract the plist, JPEG and PNG files and posted it to a gist. My Perl-Fu is weak, so no complaining about the quality of the code, but it found my photos.

Patron 0.4

phil — Wed, 22 Jul 2009 17:35:32 +0000

The 0.4 version of Patron has been released. This version addresses feedback from the initial public release and fixes a few minor bugs:

Fixed a bug in the Patron.version method
Added HTTP proxy support
Enabled SSL and Win32 support
Added ability to download data to a file with GET
Fixed a bug where header values were prefixed with a space
Made the Session#request method public
Added support for the WebDAV COPY method
Added support for uploading files with POST and PUT

In addition to all of this, Patron has a new home page at http://toland.github.com/patron/.

So, what’s next for Patron? Well, I would like to put out a 0.5 release in the next few weeks with some refactoring and API tuning. Also, I would like to implement the rest of the WebDAV methods. I am toying with the idea of creating a net/http compatible interface so that Patron can be used as a drop-in replacement. Not sure if that is going to go anywhere, though.

Once I am happy with the API and documentation I will release 1.0. Other than that, I try to respond to bug reports and feature requests in a timely manner. I originally wrote Patron to scratch my own itch, and that itch has been scratched. At this point I am looking to make Patron as broadly useful as I can, and your feedback helps with that.

Patches and contributed documentation are always welcome. In particular, if anyone feels like trying to get this working on Windows, I will be happy to integrate the resulting patches and publish a binary gem.

Using DTL templates with Nitrogen

phil — Mon, 13 Jul 2009 20:24:35 +0000

One thing that I did not like about working with the Nitrogen web framework is the way that view rendering is handled. Nitrogen calls the function main/0 in your web modules which, by convention, returns an instance of the template record. This record points to a template file that has HTML code with a little Erlang mixed in. Essentially, you can call functions in your web module and whatever content those functions return is interpolated into your template.

This all makes it sound a little more complicated than it really is. Here is a little “hello world” sample to illustrate how it works. First, the web_page Erlang module defines the main/0 function and a couple of callouts:

-module(web_page).
-include("wf.inc").
-compile(export_all).

main() -> #template { file="./wwwroot/template.html" }.
title() -> "Hello, World!".
content() -> #h1 { text="Hello, World!" }.

This will cause Nitrogen to render the template.html file.



[[[page:title()]]]


[[[page:content()]]]

The callouts in the template will call the respective functions in the web_page module and we end up with a page that displays a bold “Hello, World!”. The template file is really analogous to a Rails layout and the content that Rails puts into a view template is returned from the callouts using a markup DSL based on the Erlang record syntax.

This template mechanism is simple, but it becomes very limiting when working on a non-trivial application. Nitrogen mixes controller functionality with presentation in a way that is reminiscent of PHP or JSP. Also, you cannot compose templates and the markup DSL doesn’t cover all of the HTML elements and attributes.

I ran into this problem while working on a Nitrogen powered site and decided that I just couldn’t live with the default template system. After a little digging around I discovered ErlyDTL which implements a substantial subset of the Django Template Language in Erlang. It turns out that using ErlyDTL in a Nitrogen site is quite simple.

The first thing I needed was a utility function to render ErlyDTL templates. Nitrogen includes implicit elements for the notification flash and Javascript code for all of that AJAX goodnes which I needed to replicate in my render function.

-module(my_util).
-compile(export_all).

template_path(Template) ->
    filename:join([code:priv_dir(my_app), templates, Template]).

render_template(Name, Variables) ->
    Template = template_path(Name ++ ".html"),
    Mod = list_to_atom(Name ++ "_template"),
    ok = erlydtl:compile(Template, Mod),
    {ok, Body} = Mod:render([{flash, element_flash:render()},
                             {script, wf_script:get_script()}
                             | Variables]),
    Body.

Now, I can replace the simple module from earlier with this new one:

-module(web_page).
-include("wf.inc").
-compile(export_all).

main() ->
    my_util:render_template("template", [
          {title, "Hello, World!"},
          {content, content()}]).

content() -> "Hello, World!".

My template file is now equally simple:



{{ title }}


{{ content }}

All of the markup is now in the template file, and the module is concerned only with getting the content from somewhere and making it available to the view. This also allows us to use the full power of ErlyDTL: we can compose templates and perform simple operations on the content to be displayed. Here is an example from the ErlyDTL home page:

Welcome back, {{ name }}!

You have {{ friends|length }} friends: {{ friends|join:", " }}

Have some primes:
{# this is exciting #}
{% for i in primes %}
    {{ i }}
{% endfor %}

There is one drawback to this approach. The Nitrogen DSL includes helpers for generating links that work with its event system. When using ErlyDTL we have to create those links manually, but it isn’t hard. The key thing to remember is that the link id is the event name that will be passed to your module. Here are a couple of examples:

Do It!

The extra flexibility of DTL is certainly worth the small amount of extra work.

Announcing Patron: a Ruby HTTP client library

phil — Fri, 03 Jul 2009 20:02:50 +0000

I was recently given the opportunity to release several of the projects I was working on at The Hive as open source. These projects are libraries that we built to address specific problems we ran into but were not core to our business. Most of these were always destined to be released, it just took a while before we got around to it. Everything is currently on my GitHub page, but I wanted to do a little cleanup on each project and announce them individually.

Today I am announcing the first of these projects: Patron. Patron is an HTTP client library for Ruby that features a usable API and good performance. As for the name Patron, I searched through the thesaurus looking for synonyms for the word “client”.

The performance problems with the built-in Ruby HTTP client are well documented elsewhere, so I won’t go into that here. The other alternative is the Curb gem which is based on libcurl and offers great performance. Unfortunately, curb is unfinished and doesn’t appear to have an official maintainer. Also, the API leaves much to be desired. These issues are compounded by the fact that curb is primarily implemented in C and is difficult to modify.

I tried to patch curb to get all of the features we wanted, but subtle bugs kept creeping in. Eventually I gave in and wrote Patron. The goal was to have a Ruby HTTP client built on libcurl with a reasonable API. By implementing as much as possible in Ruby I think that Patron is much more maintainable than curb.

I have not made an attempt to support every feature of libcurl. Libcurl is huge and trying to support every feature would lead to bloat and make it harder to maintain. Instead, I built a small API that did what we needed it to do. It has been in use at The Hive for some time now and seems pretty stable.

The documentation for Patron is on Rubyforge and the source code is available on GitHub.

Thoughts on NetBeans 6.7

phil — Thu, 02 Jul 2009 19:56:17 +0000

I used NetBeans back when it was called Forte for Java and have kept an eye on it ever since. Every few releases I would download it and try it out again. Since Eclipse came onto the scene, NetBeans was just “that other Java IDE.” I no longer work with Java, nor do I use an IDE, but I still download NetBeans every once in a while to see how far it has come. When Rails began to gain traction, the NetBeans team began to work in Ruby support. The Ruby support in NetBeans has always demoed well, but always seemed a bit too clunky for me. And it looked like crap on OS X.

NetBeans 6.7 was released on Monday and I dutifully downloaded it and played with it for a couple of days. The first thing that stuck me is that it looks good on OS X.

This is the best looking Swing application I have ever seen, and yet there are little inconsistencies that can become annoying. For example, you can drag a Cocoa window by clicking anywhere on the integrated toolbar, but in NetBeans you have to click on the title bar. This is a big issue since the toolbar in NetBeans looks like an integrated Cocoa toolbar, but it isn’t. Also, clicking on a file in the explorer on the left shows the file’s members in the Navigator, but does not open the file. You have to double click to actually open a file.

All of this would be forgivable if NetBeans offered better functionality than my current toolset. The whole idea behind IDEs is that it is more convenient to have all of the functionality you need bundled into one application than to use several separate apps. However, getting to some of the functionality in NetBeans requires digging around in the UI, and some stuff is just broken compared to the non-IDE equivalent. For example, when running Ruby tests or the Rails server via script/server from within NetBeans, the ASCII color codes are not properly interpreted making the output unreadable.

So far, I have found NetBeans less convenient than the combination of TextMate, GitX, Terminal and Sequel Pro. Part of this is due to the fact that I have a lot of time invested in my current development stack. The latest version of NetBeans shows enough promise, and I am enough of a tools geek, that I am going to tough it out a few more days. That having been said, I am having a hard time seeing the value in an IDE when the components of a non-integrated development tool stack are of such high quality.

My Erlang setup

phil — Wed, 01 Jul 2009 23:45:33 +0000

When setting up Erlang under OS X I have run into two issues. First, how do I keep multiple versions installed at once? I sometimes have a need to evaluate a new version of the Erlang VM while keeping the old version around “just in case.” In a few instances I had two applications which needed different versions of the VM. Second, where do I install all of the 3rd party Erlang libraries? Unlike with Ruby or Python there is no blessed “site” directory for 3rd party Erlang libraries.

After a little experimentation I was able to set things up in a way that solves both of these issues. Some of the details are a bit specific to Mac OS X, but this method could easily be adapted to any UNIX-like environment. The method involves symlinks so Windows users are probably out of luck.

I decided to install all Erlang related stuff under ~/Library/Erlang to generally conform to OS X conventions. While I chose to install under my home directory, you could also put it in /Library with minimal changes to the process. In the Erlang directory I have two subdirectories: Releases and Site. The general idea is that each Erlang release will live in a subdirectory of Releases named after the Erlang release (i.e., “R13B01”) while 3rd party code goes in Site. Finally, I create a symlink named Current in the Erlang directory and link it to the release that I am currently using.

The final setup looks like this:

Erlang
  |-- Current -> Releases/R13B01
  |-- Releases
  |     |-- R12B5
  |     `-- R13B01
  |-- Site
  |     |-- erlydtl-0.5.2.2
  |     |-- mochiweb-0.97.1
  |     |-- nitrogen-0.2.0
  |     `-- webmachine-1.3
  `-- setup.sh

The setup.sh file is sourced in my .bash_profile and it sets up the shell environment:

export ERL_ROOT=$HOME/Library/Erlang/Current
export ERL_LIBS=$HOME/Library/Erlang/Site
export MANPATH=$ERL_ROOT/man:$MANPATH
export PATH=$ERL_ROOT/bin:$PATH

With this setup, all of the libraries in Site are in the Erlang code path and the current Erlang VM is in the shell’s path. I can switch Erlang VMs by changing the symlink to point to a different distribution, but everything else remains the same.

Building Erlang from source is simple. After extracting the source distribution:

$ ./configure --prefix=$HOME/Library/Erlang/Releases/R13B01
$ make
$ make install

You will want to replace the ‘R13B01’ with the name of the distribution you are building.

QLMarkdown 1.1

phil — Thu, 12 Feb 2009 03:19:31 +0000

There is a new version of the QLMarkdown generator available. I didn’t have anything to do with the new release other than zipping up the final product. Michael Dominic K. added some nice new features. You can download the goodies here or grab the source from GitHub.

Keeping track of little things

phil — Mon, 26 Jan 2009 17:43:45 +0000

I have been using GTD for a while now (1 year? 2? Has it really been that long?). By now I have mostly passed the “tinkering” phase and my system has become integrated with my daily routine. Having said that, I am still finding small ways to improve and optimize the whole process.

This morning I was looking over my Today list in Things and I realized that there were two tasks on my mind but not in the system. Safari bookmarks aren’t synching to my laptop properly and I have a memory upgrade for my daughter’s iMac that needs to be installed. I initially resisted adding those tasks to Things with the justification that they are little things and I would take care of them this evening. Of course, I have had the memory upgrade for over a week now and it has yet to be installed.

These “little things” were becoming a source of stress because every time I would walk past the iMac or log onto the laptop I would think: “Oh, yeah. I need to do something about this…but not right now.” And yet, I resisted adding them to my list in Things. Once I became aware of this I thought of several tasks that I had been holding in my head. Getting those tasks into things relieved some of the stress and gave me more confidence that they would eventually be done.

Now all I have to do is become more disciplined about doing the things on my list as opposed to just moving things around.

Nitrogen

phil — Sat, 06 Dec 2008 17:10:35 +0000

I have been using Erlang extensively for the last 6 months or so and it is a very nice language. While I have enjoyed working with the language, I wasn’t really impressed with the existing Erlang web frameworks. Mochiweb is nice enough, and I use it to power an application with an HTTP based ReSTful API, but it is too bare bones to use for building a full-featured site.

Then I ran across Nitrogen. The first thing that struck me about Nitrogen is how it (ab)uses the Erlang record syntax to create a passable DSL for HTML generation. Check out this snippet from the included sample application:

main() ->
  Title = "Postbacks",
  Body = #template { file=onecolumn, title=Title,
                     headline=Title, section1=[

    #button { text="Press Me", postback=button_pressed },
    #p{},

    #link { text="Click Me", postback=link_clicked },
    #p{},

    #label { text="Press enter in the textbox." },
    #textbox { text="This is a message...", 
               postback=textbox_enterkey },
    #p{},

    #checkbox { text="Toggle Me", postback=checkbox_clicked },
    #p{},

    #dropdown { postback=dropdown_changed, options=[
      #option { text="Option 1" },
      #option { text="Option 2" },
      #option { text="Option 3" }
    ]},
    #p{},

    #span { text="Mouse Over Me", 
            actions=#event { type=mouseover, 
                             postback=span_mousedover } },
    #p{}

  ]},
  wf:render(Body).

The second thing that caught my attention is the event model. The postback attribute on the elements in the above snippet cause the Erlang term that is assigned to it (in this case symbols) to be posted back to the server using AJAX. This example simply shows an alert box with the posted symbol. The code is very concise:

event(EventInfo) ->
  wf:wire(#alert { text=wf:f("~p", [EventInfo]) }),
  ok.

The nice thing about this model is that you can use Erlang’s pattern matching to catch events from different elements. If you have elements that look like this:

#button { text="Next", postback=next },
#button { text="Previous", postback=previous },

then you can handle the events using pattern matching:

event(next) ->
  %% Go to the next item...
  ok;
event(previous) ->
  %% Go to the previous item...
  ok.

This is clean and easy to understand.

I have not spent as much time as I would like with Nitrogen, but it certainly has my attention. It currently addresses two of the gripes I have had with other frameworks, but there are other issues that have not yet been addressed. For example, how easy is it to deploy or update a site built with Nitrogen? What does the performance and efficiency look like? Using Erlang gives Nitrogen a head start in both of these areas, so I am optimistic.

app_version Updated

phil — Sun, 10 Aug 2008 23:47:23 +0000

I have updated my app_version Rails plugin to support getting build numbers from Git. This is of necessity a little kludgy. The plugin allows you to specify either ‘git-revcount’ or ‘git-hash’ as the build. ‘git-revcount’ will set the build number to the number of commits on the current Git branch and ‘git-hash’ will set the build number to the first six digits of the Git HEAD hash. Neither method is really equivalent to the Subversion revision number, but either might be useful in certain contexts.

The source code for the plugin is available at http://github.com/toland/app_version.