JD Tangney & Associates

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

Readings on User Interface for Children's Interactive Media

There is a quiet, but knowledgeable community on the ACM's CHI-Kids mailing list. A reader had requested references to "user interface standards and guidelines for children ages 3 to 6 years old. " Another reader collected them, and they are now posted on this wiki.

Labels: user interface

0 comments

Disgruntled employees

I caught a bit of this morning's Forum on KQED (Download (MP3)) which was mostly about some civil servant in SF who sabotaged the City's computer systems, and what that means for employers and "health and security of the workplace."

The interesting bit for me was a Towers Perrin survey of 90,000 employees across 18 countries indicating "widespread disengagement".

• 21% "engaged with their work"
• 38% "partly or fully disengaged"

Also cited was a Gallup survey saying that

• 19% of employees are "actively disengaged" i.e. trying to sabotage the workforce

I bring this up because as XP evangelists we run into people who we want to see succeed and excel, but who might be dealing with the own demons. And a much-cited antidote mentioned on the show was "job rotation" and "employees training each other". So pair programming is not just good for the code, good for the dev, good for the team, good for the enterprise, but it might just stop you from going postal. ;-)

Those numbers also tell us that there is a vast amount of waste. Large numbers of people punch clocks and little else. Again, as XPers, we talk about productivity, but what does that really mean for someone who is comfortably numb?

Labels: xp

0 comments

Facebook Rediscovered

Seriously.

I joined pretty soon after FB started up. I wanted to jump on the social networking bandwagon as a marketing tool. I gave up almost immediately, since I was not interested in dating... That seemed to be the exclusive intent of FB at the time.

A couple days ago, I logged in on a whim. I found old school friends from 30 years ago, my teenaged niece, and various former colleagues. The maturity of the site was impressive, both UI and content. Now my purpose is different. It's social! It's a way to reconnect and keep in touch - and be silly about it!

0 comments

Why FileMaker ultimately sucks

When you have a FileMaker "solution" in place, you have a large investment in UI design and usability. You might, depending on the quality of the original design, also have an investment in the database schema. Porting to another environment - say Java + Spring + Hibernate - is daunting, mostly because re-implementing the UI is such a vast undertaking.

As an XPer, I need to be able to test-drive development. The only reasonable way to do that is by using external AppleScript (or Python + appscript and maybe PyUnit too) tests. I don't know about you, but that sounds like far more trouble than it's worth. Just navigating the maze of what works as expected and what requires arcane tricks in the AppleScript world gives me a headache just thinking about it.

XPers also refactor. Not surprisingly, there are no tools at all for refactoring. Worse, the structure and syntax of FileMaker's scripting language actively discourages refactoring. For example, while it's possible to pass multiple arguments into a sub-script, they have to be packed on the caller side and unpacked by the callee - multiple lines of script. And having to drag commands into place rather than just type like a normal human...

Then there is basic source control. A FileMaker file consists of several elements, the most important being

• Tables and relationships
• Scripts
• Layouts

I need to be able to see what's changed from one version of my FMP file to another. Since all the above elements are stored in a single binary file with a proprietary format, it's impossible to do a diff. Sure, one could export a DDR XML file and diff that, but diffing XML?!

And there are indeed tools that purport to do this. Unfortunately, they are universally hard to use and slow, if you cam get them to work at all. (Of the 3 main contenders, I have only managed to get the demo version of one of them to work consistently. The others are so obsessed with license keys that they fail to work at all.)

Labels: filemaker, xp

2 comments