I’ve probably written a hundred render_not_found methods in my life as a Rails dev. Usually they just render a static file under /public, and maybe, if I’m feeling nice, give an XML response. No more!

On December 11, 2008 I presented a FileMaker-made-mobile solution to the members of the New York Motion Picture Collective and the New York FileMaker Developer Group. The presentation demonstrated bringing a database from FileMaker to the iPhone through the use of FMTouch.

In beezwax’s webdev division we generally work in pairs, but our commit logs didn’t used to show this. We wouldn’t bother to reconfigure the git author every time we sat down with a new pair so our git log only recorded one of the programmers’ names. Bryan Helmcamp has a nice script for setting your git commit author in pair programming situations. Here’s another one which works interactively.

In my last post I described how to use reverse ssh tunnels and screen -x to setup a remote pair programming environment.

Several people have commented that this works well for sharing a console based editor (vim, emacs) but that there is no way for the remote pair to look at how things are rendering in the browser. Well here’s a super simple way to use ssh tunnels to share your development server too. I’ve seen variations on how to do this (Advanced Rails Recipes: Pragmatic Programmers has one). The advantage to the below method is it requires no server configuration and is very secure from snooping.

There’s a lot of talk about remote pair programming, but the fact is it can be a pain to set up.  Using iChat screen sharing is a popular method, but can feel a little cludgy, and doesn’t work for developers running linux.  Here’s another method using reverse ssh tunnels and screen -x we use a lot at Beezwax.

In my last post, I described my preferred methodology for integrating Rails and FMP. In this post, I’ll discuss an alternative technique using FMP’s external SQL sources functionality. Since IANAFMPD (I am not a FileMaker Pro Developer), I’ll skip the implementational details and just cut to when it’s an appropriate solution.

Here’s a synopsis of my findings on integrating Rails with FMP.

Goals:

• allow two-way data transmission between FMP and Rails
• minimize development time required for both FMP and Rails
• accommodate as many clients (which may be another application written with FMP, Rails, or anything else) as possible