JD Tangney & Associates

NIH

Before I knew what National Institutes of Health was, before I moved to the US, NIH stood for "Not Invented Here."

The reappearance of this phenomenon on my radar is coincident with my deepening involvement in the Agile/XP world. Coincidence? I sure hope so. So step forward all you XPers and agilistas and tell me that you are at least as allergic to NIH as I am.

In the last month I have spent hours (with a pair) figuring out why http session management is broken. I have spent days (with various pairs) trying to outwit a half-baked Hibernate session management infrastructure. Today I spent several hours (with a pair) getting some file manipulation utilities to work.

Even back in the days of Struts 0.5, session management was pretty damned solid. And the Spring-like management of Hibernate sessions by tying them to a request/response cycle (in the simplest case) was hashed out years ago. And the Apache commons I/O library is pretty mature at this point. Hell, it's already on our classpath!

So how did this mess come to be? The answers I got in the past were vague hand-waves along the lines of "well we needed something simple and lightweight so we built our own."

Yeah, yeah, "the simplest thing that could possibly work." But surely the definition of "work" also includes "does not require constant repair and debugging"?

Maybe it's just innocence. Maybe those people really believe that an app framework is "too big" and so building out a Struts-lookalike from scratch is excusable. Maybe they really believe that they just know they will never need to manage Hibernate sessions with a broader scope than a single call. Maybe they really believe the file manipulation is just a quickie, undeserving of a library.

To me the simplest thing that could possibly work is to use code that someone else has spent years refining and is known to work.

Please tell me all this NIH is not hubris.

Labels: xp

0 comments

Migrating from FileMaker to MySQL

FileMaker Pro (FMP) has the ability to access a real RDBMS via ODBC dynamically. An "external" table can be accessed in the same way as a native FMP table. FMP calculations, normally associated with a native FMP table, can be added to an external table as "supplementary fields".

So all this sounds terribly glorious. Surely one can migrate one's FMP db to MySQL (or other) so that the data is stored in an industrial-strength RDBMS. That, naturally, allows all kinds of other enterprise apps to hit the same data as the FMP. In fact, one can think of the FMP db as a front end to the enterprise db.

I know folks who have made this work. But migrating is another story. There is no programatic interface to the FMP schema - the definitions of the tables and "table occurrences" (really aliases that allow for the definition of associations that become joins at run time). And FMP's use internally of ids rather than names for fields, scripts, tables, etc – one of its key benefits that allows transparent renaming of objects – means that once a relationship is defined using one table, the only way to switch to another (external) table is to delete and recreate it.

That spells a ton of manual labor. I'll outsource it if I can find someone.

We'll still be left with all the presentation intelligence (FMP layouts) as well as the business logic (scripts, calculated fields, portals) firmly in the FMP world. As we build a parallel implementation that does not rely on FMP, we'll be rebuilding all that stuff. Only this time we'll do it in a transparent, modifiable, refactorable way, using code that can be edited using industry-standard tools like (ooh, gasp) a text editor.

So if you're thinking of building a real enterprise app in FMP, don't. It will bite you.

And to answer my own questions from a few months ago regarding FMP in an XP world: The more I bang my head against the closed, constrained FMP model, the more I realize that its only use is as a spiking tool.

Labels: filemaker, xp

0 comments

Ecto

So it's a holiday, and what better way to spend it than fiddling with an app on a Mac?

I looked around – once again – for a better blog posting client than ecto. The only contender is blogo. It's very nice, but it lacks some of the power features of ecto like a twitter plugin (I still don't have that working..), the ability to ping a bunch of servers, and, most important, custom HTML tags for doing stuff like posting code. Sure, you can hand-edit the HTML, but that gets very old very quickly.

So back to ecto. Time to pimp it up and get all the gibblies to work together. The UI has always frustrated me. Nothing is where I expect it to be. But at least this version (3.0b55) is reasonably stable.

Now, having got it the way I want it, I need to set it up again on my desktop machine. What a pain! I copied the .plist file from ~/Library/Preferences to the other Mac, but some things are still not there, like the list of servers to ping. With a little digging and some help from sudo fs_usage -filesys |fgrep -i ecto I see that all that stuff lives in ~Library/Application Support/ecto3/accounts.plist Bingo!

Labels: macos

0 comments

PHP and FMP

Get FM_API_for_PHP_Standalone from within the FM server download. Use the trial if necessary.

Expand it and copy it into /usr/local/php/fmp. Make the parent directories as needed

Copy /etc/php.ini.default to/etc/php.ini

Edit php.ini. Uncomment and modify include_path = ".:/usr/local/php/includes"

I set up eclipse by copying the features and plugins after downloading from http://www.eclipse.org/pdt/downloads/ I couldn't get the update site to work (mysterious errors.) Finally, after messing with it for ages, I concluded that Eclipse PDT doesn't work with Ganymede. I now use PHPEclipse.

For debugging, we need xdebug. Oopsie. Must install pear to get pecl to get xdebug.

So,

curl http://pear.php.net/go-pear > go-pear.php
sudo php -q go-pear.php

Let the script update php.ini. And don't forget to update PATH like the script told you to.

Then it's

sudo pecl install xdebug

And do NOT do what it says (You should add "extension=xdebug.so" to php.ini")

Instead, add this:

[xdebug]
zend_extension=/usr/lib/php/extensions/no-debug-non-zts-20060613/xdebug.so

Then confirm that it's working by doing php -mxdebug will show up both under [PHP Modules] and [Zend Modules] Get phpUnit installed. See Sebastian Bergmann's site: http://www.phpunit.de/manual/3.3/en/installation.html

sudo pear channel-discover pear.phpunit.desudo pear install phpunit/PHPUnit

Labels: filemaker, macos, php

0 comments

Wired

All of my on-stage experience to date has been unplugged. That is, I have never dealt with amplification of any sort. I have sung the lead in operettas and musicals of all sorts as well as numerous musical roles, of course. All of it unamplified. But I have never – until tonight – had to sing onstage with a full band, had to deal with mic technique, had to try to follow exactly where the hell we are in the song with a monitor blaring the bass line alone...

The "Music Masti" at Agile2008 was my wired debut. Damn, it's hard to figure out where you are, to keep track, to be able to hear un-monitored instruments when you are singing in a band.

Now I have designed sound for stage productions, even mic'ing actors where needed. But now I know what it's like to be on the performing end. Who'd a' thunk it was so hard? This is what happens when you let popular culture pass you by.

Sigh. There's a lesson in this. There is no substitute for doing, even when it seems that "it" is a natural extension of what one already knows. Maybe it's the geek mystique: "How hard could it be?" But when you pick up that mic and you realize that it's actually not that self-evident,.. it's no longer an extrapolation from the known the assumed, but genuinely into the unknown, it's a bit of shock.

Regardless, it was unbelievable fun.

Rock on!

Labels: xp

0 comments

tSQLt

I attended a demo today in which tSQLT was put through its paces. It's a microtesting framework for databases. So what makes this one different? For one, the two dudes who presented totally get TDD. The framework eats its own dogfood (it was TDD'ed with itself.)

Downside? So far, it appears to be MS SQL Server-only. It's "pre-alpha" in the words of the authors, so it may not be as mature as one might like.

Still, the promise of real, grown-up TDD in a database is mighty appealing.

0 comments

FileMaker – the war continues

Now that I am starting to add some web-visible components to the SIS I am building with FMP, I finally have the opportunity to test-drive what I'm doing. What a pleasure it is to make a Selenium script that logs in, clicks around, types a bit and validates the contents of the web pages!

Of course, the best part of test-driving (albeit in this rather coarse, macro way sans microtests) is that it is so much faster! I spent a few minutes putting the script together. I didn't even bother using Selenium-RC but instead just run the thing straight from the IDE. Then, logging in with the right credentials and doing all the preliminary navigation is done precisely once in my script. I don't have to do that mind-numbing, repetitive work that machines enjoy but I don't.

The test, simple as it is, is a one-click, red/green litmus test. If it's red, I hack around in the gibblies of my app, and click again. Rinse and repeat. When it's green, I refactor a little then check in.

Of course, checking in a giant FileMaker file as an opaque, binary monolith really only has value as a backup. There ain't no way anyone's ever going to do a diff on those puppies. Maybe I should take the extra 5 minutes to generate a new DDR in XML and check that in.

And since you brought it up, refactoring's a larf in FMP. Maybe I'll write a book called "Refactoring to FMP Patterns." In reality, all I actually do is to get rid of any debug fields or relationships I created. 

While the scripts seem like an obvious target, the real, hard-core refactoring of scripts is something I have skirted. As I mentioned in a previous post, the overhead of passing parameters into a "sub-script" feels like it outweighs the putative benefits. Maybe there are some tricks that I can come up with... I'll have to think about this more seriously. 

Meanwhile, even if we can't do much beyond the basics regarding the size of scripts, we can start with intention-revealing names for scripts and variables. Deep nesting of if's might be reduced by using guard clauses.

Other refactorings might come from the database world. At least that's well-understood! Most of the time it's not much of an issue for the schema itself; it's a question of factoring correctly in the first place, thereby obviating the necessity to re-factor. It's not rocket surgery: normalize the schema. Don't duplicate. Consider whether a 1-1 relationship is worth the overhead of maintaining it. The usual bitrot kinds of things like lousy names of fields and tables are quite trivial to deal with in the FMP world – references are transparently updated.

Layouts, being primarily collections of visual elements, yield to modest refactoring goals like maintainability through revelation of intention. Reduction of duplication by parameterizing the layout is not something I have pursued very rigorously. There is probably room for exploration there. One concern is that supporting such techniques might require introducing temporary tables. I suppose I shouldn't be afraid of that, but the though of copying data back and forth just seems like a lot of heavy lifting, again outweighing the minor inconvenience of duplication. Sigh. Another area I guess I need to delve into a bit more deeply.

Although FMP retains references to internal objects by some means other than their names (so you can, e.g. rename a table and all references to it show the new name), it's possible to delete some objects and leave unused objects in the file. This is where an analysis tool is yer only man. It often takes several passes to get a file "clean", but it's worth it as a regular part of pre-checkin refactoring hygiene.

While writing this, I have noticed areas that might be fertile ground for further XP-oriented study. You'll be the first to know.

0 comments