This is the first of several articles on designing and implementing FM/Web integrations. Future articles will give in-depth discussion of implementation details.

One of the basic questions when considering a FM/Web hybrid solution is how FM and the Web will relate to each other as clients, servers, or peers1. Each possible architecture has characteristic strengths and weaknesses.

A client is essentially a frontend to a server. It relies upon the server to house and process data, and does not share its resources with any other nodes (nodes are any other entities) in the network.

I’ve been doing work on a couple projects integrating Rails with FMP over HTTP. There are a few different FMP features and plugins the FMP developers use to connect to Rails, none of which I truly grok. Notwithstanding my lack of FMP knowledge, I wanted to write-up what I expect from FMP as an HTTP client, and what I think would be neat to see.

A Good Foundation

When I’m integrating with another system over HTTP, I usually provide usage examples for my Rails-based service using the lingua franca of *nix system tools like Bash, Curl, WGet, LWP, and Telnet. I expect an integrating client like FMP to be able to perform the same basic functions those commandline tools perform.

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!

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

I love git and I love to be lazy, so lately I’ve been playing with git hooks.

Git’s default pre-commit hook is really handy, but today I’m in more of a post-commit kind of mood.  Like all git’s hooks it comes with an example script.

This one isn’t particularly useful.  It evaluates Nothing and returns a successful exit code.  Big deal.

Git’s default post-commit hook.

#!/bin/sh
#
# An example hook script that is called after a successful
# commit is made.
#
# To enable this hook, make this file executable.

: Nothing