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

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

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

Selenium-RC

My "Mastering Selenium" tutorial has been approved at Agile2008. I am very excited about that.

Meanwhile, in preparation, I have been putting Selenium-Grid through its paces at Industrial Logic. We are formulating a high level lingua franca to use in describing executable Storytests. This is a big deal. It was the promise of FIT, but for one reason or another (and theories abound!) Customers stayed away from FIT in droves.

Our old Selenium tests had been constructed using a wiki language and template processor. This provided a powerful toolset with which to construct Stroytests, but we ran into 3 major issues:

1. Selenium Core is slow
2. With the HTML Selenium tests, there is no guaranteed tear-down as there is in xUnit
3. Our toolset, while providing a fair bit of power and reasonable readability, did not come close to the expressiveness of a language like Python, Java, or Ruby in Selenium-RC.

So we went full out for Selenium-RC, using JUnit to drive the tests against a local Selenium-server.

To get the ball rolling, we grabbed the HTML from an old Selenium test by simply firing it up in Selenium Core and grabbing the code from the browser. It's a trivial matter to translate it into one of the Selenium-RC languages - we're using Java - with the Selenium IDE. Some deft text editing massages the Java file into shape so that it fits into it's place in the class hierarchy. More about the hierarchy later. We found reworking these legacy Stroytests to be an illuminating process. It meant bottom-up - starting with a very long list of Selenese commands, and doing extract method on clumps of code. The original source file with its template language was found to be lacking in many cases. The tests had grown over time and had not been refactored. We found some very interesting issues:

• Code that verified conditions that had absolutely nothing to do with the story at hand. These were presumably checks that had been copied/pasted from some other test where those checks were relevant.
• Some tests attempted to do too much and veered off on a tangent.
• Once we put in place some decent setup and (dependable!) tear-down, the test body was short and to the point.

So what does the class hierarchy look like?

The immediate superclass of each Selenium test class contains domain-specific helper methods. Its superclass is essentially a proxy for the Selenium server (or a hub, which is in turn a proxy for the runners.) For that class, we started with the SeleneseTestCase that is provided in the download, but decided that we didn't like it for a variety of reasons. In particular, we needed to do some magic so that a new Selenium session (and hence a new browser) is only launched if none already exists for the current thread. That's because we exploit the good ol' JUnit 3.x suite and test decorators to run allow for parallelization of tests. Sure, we could have used testng but its seemed a little haphazard to us and that business of generating an intermediate xml file just doesn't seem right.

The next chunk of learning relates to just what is needed to get tests to run in parallel so that they don't stomp all over each other.

Labels: java, xp

0 comments

Macworld | Mac OS X Hints | Add more power to 10.5's screen sharing

[From Macworld | Mac OS X Hints | Add more power to 10.5's screen sharing]

I live by VNC, since we are a distributed XP team. So I was thrilled when I found this MacWorld article on tweaking the build-in VNC client on Leopard.

Now if only it would get over some of its temperamentality so I can use it reliably over an SSH tunnel or to a non-Mac machine.

Labels: macos, xp

0 comments

TDE - test-driven exploration

So I was geeking out last night, as Mike would say. I was writing some code to fix some corruption in my calendar. It's in iCalendar format, so I found an ical4j framework on SourceForge and fired up Eclipse.

The first thing I did was to copy some snippets of sample code from the ical4j docs into a JUnit test and see what happens. I did this for 2 reasons: (a) the docs for FOSS are often wrong, and (ii) I needed to get all the config set up (e.g. to make a test calendar with events in it containing the properties I was interested in.)

As I worked, my "production code" kept evolving inside my test class. When I had successfully TDD'ed a step, I extracted the code into a real production class. I could move code around with Eclipse's refactoring tools and I had solid tests to save my butt.

Nothing startling in any of this. The interesting thing for me was that I was exploring ical4j. It was something of a spike - I didn't know ahead of time if the framework would be up to the job - yet each success immediately resulted in moving the code to the production classes.

So what do you think of this approach of evolving the code in the test and moving it as soon as it's green?

Redux: Keith Ray says: It's good. I think Kent Beck or someone called these "Learning Tests"when learning an API via TDD.

Labels: java, xp

0 comments