I’m very pleased to announce my partnership with ThirstyHead.com. ThirstyHead is a training and consulting company that specializes in Groovy and Grails solutions. I’m still going to continue every bit of my work at the August Group as a writer, speaker, and software developer, but I’ll be joining forces with Scott and Andy for classroom training. ThirstyHead is a strong brand in the Groovy and Grails training space, and I couldn’t be more pleased to be a part of their team. Look for continued G2 Goodness from ThirstyHead, as well as new offerings in the near future. Stay tuned for more!

Like a terminally ill dictator in exile, IE 6 has been hanging on for far too long, forcing legions of web developers to to relive the pain of its tyranny every day. Happily, it’s starting to look like the old bugger might finally pass away.

It’s no longer news that Google is phasing out support for the browser, and more anecdotally, a very tech-savvy client of mine has eliminated support for it in its next-generation web app—an app which is responsible for the entire business and is exposed to external customers as well as internal users. When smaller technology companies who lack the power to move the market are making decisions like this, it means the end is near.

A Denver area design consultancy has now gone so far as to schedule a wake for the dying browser. What a fun way to celebrate a laudable technology development and generate some positive buzz at the same time! My hat is off to you, Aten Group.

Everybody who makes software makes bad software sometimes, so I’m always hesitant to blast bad code when I see it. That said, IE 6 was for years a gratuitous drain on the flourishing of the web and the cause of more misallocated capital than a hundred failed dotcoms. It will be a relief to see it go. May the future of the web be more competitive and less autocratic.

Broken IE icon courtesy of Zakar.

I first bought my 100WH HyperMac battery on the recommendation of Scott Davis. It’s a great way to survive a long flight with a layover or spend some time in a cafe without worrying about being near a plug. Scott had warned me about the hiss it caused in the headphones (which didn’t stop me from temporarily convincing myself my headphones, then my MacBook audio output, were broken, before I remembered his advice), so I theoretically knew what I was getting into.

The hiss is actually pretty bad. On my machine, it quickly got to the point where I couldn’t enjoy listening to music while using the battery. Since the my two primary use cases both recommend headphone usage, this was a major bummer.

I have a theory of what caused the hiss. I haven’t been able to test this with my spectrum analzyer yet—yet!—but I think the problem has to do with the power converter in the HyperMac. The unit isn’t just a dumb lithium ion batter and a charger; it’s actually got a DC/DC converter onboard, presumably because the specified voltage on the MagSafe connector was not easy to achieve with lithium ion cells. And switching power converters mean noise.

I’ll skip some tedious details, but you can read more about switching power supplies on your own if you’d like. Basically, despite the best efforts of the power supply designer, a switcher will couple noise into its output at the switching frequency of the converter (plus its harmonics). Linear power supplies, distant cousins to switchers, avoid this, but at the expense of size, weight, and efficiency. This is why your stereo receiver is big, heavy, and hot—but sounds great.

So the HyperMac battery contains a switching power converter, and this switcher is busily coupling its noise into your MacBook when you’re plugged into it. My theory is that some of that noise is getting coupled through the power input and into the audio output circuitry, causing the hiss. Pretty straightforward, and suggestive of a simple fix.

But wait! Before I “fix” this problem, you’re dying to point out a flaw in my argument: Apple’s plug-in power adaptor (what power supply designers call an “off-line” supply, because it draws power off the line voltage) is a switcher too! Why doesn’t it hiss? Well, this is what I’d have to take some measurements to confirm, but I’m guessing the switching frequency of the Apple product is matched to noise rejection circuits in the power input or our audio output circuitry of a MacBook. The switcher in the HyperMac battery either switches at a different frequency that bypasses the MacBook’s filtering, or its noise is just louder. I could be wrong about this, and I don’t mean to cast aspersions on a great product. However, the headphone hiss is certainly real, and this is a decent hypothesis, easily strengthened with some simple measurements.

Which I hope to do soon. In the mean time, it’s easy to knock this noise down below audible levels. Enter the HyperMac user’s best friend, the ferrite toroid:

Ferrite toroids are a beloved hack of noise-hating hardware designers everywhere. They don’t deal with the noise problem at its source, but they do stop it from spreading. With a 19mm internal diameter toroid from DigiKey, I was able to wrap the HyperMac’s power cord through it several times.

With this in place, I am no longer able to hear a hiss in the headphones. Your mileage may vary, but this hack has no choice at least to help a little bit, plus it looks kind of cool. With this hack in place, you have no excuse not to have a HyperMac battery. Let me know how it works for you!

UPDATE: a reader asked offline if the toroid was a concern near non-solid-state hard disks. The answer is no, since it’s not a permanent magnet by itself. It’s a ferromagnetic material with high magnetic permeability, but on its own can’t harm your hard disk or any of those 8½” floppies you’ve got lying around.

Back when I wrote firmware for a living, every project had an exciting phase in the middle which we called “bringing up the board.” Bringing up the board consisted of getting a fresh, chemical-smelling new circuit board from a short-run manufacturer, applying power to it, and attempting to take control of it with software. It sat neatly in between a very waterfall-ish design and coding phase at the beginning and a very deathmarch-y integration and test phase at the end.

Bringing up a board requires intensive, cross-disciplinary debugging in which very few abstractions are of any use to the engineer. Rarely do enterprise software developers think about things like reset vectors and fetch-and-execute cycles (much less voltages and currents), but these are the stock in trade of the firmware developer working with a brand new hardware design. The phase is full of the seemingly intractable problems and contradictions that normally attend test-last debugging. Inevitably, at least once on each project, some impossible condition will arise in which the engineer knows he is flipping a bit in a control register somewhere, and he knows the corresponding digital output pin is driving a high impedance, but somehow under such-and-such conditions the trace on the oscilloscope barely wiggles when it should be banging back and forth between five volts and zero. He’s sure of everything else in the system, he knows he’s got the address of the control register right, he’s certain he understands the circuit the output is driving. There’s just no other option: Ohm’s Law must be wrong in this case.

Of course it never is. And while widely used, production-ready web frameworks like Grails are less reliable than fundamental laws of physics, they can probably handle trivial form submissions with aplomb. Of course, that still didn’t stop me from thinking Grails had a bug last week.

I had generated some scaffolding for a fairly simple domain class, and had begun elaborating on it in the way that any Grails developer does for a real-life application. The GSP code looked something like this:

When I clicked on the submit button, I got a 404 error. I verified that AssessmentController had a save action, which it did. I bounced Grails, which I was running in dev mode. Still no love. I banged my head against this for a while, unable to believe that I couldn’t get a form submission to work. Was it some strangle UrlMapping oddity? Was it a problem with allowed HTTP methods? Nothing made sense.

So I decided to bypass the Grails GSP tags and code up a form myself. It looked like this:

Question 1: Question 2: Question 3: Question 4:

That worked perfectly! My next task was to figure out what was different between the two requests. Ever a fan of the big hammer (my favorite debugging tool in my firmware days was the oscilloscope), I broke out HttpFox to see what was happening on the wire.

I saw, as you might expect, two apparently identical requests that looked something like this:

No differences in headers, request URL, or anything that might affect how the request would be routed to an action. Everything was the same until I looked at the POST Data tab. The version of the form that was built by the Grails tags looked like this:

while my custom form generated these parameters:

The _action_Submit vs submit difference should have tipped me off right away, but it didn’t. I had simply forgotten that Grails is capable of doing request mapping through the submit button, so I continued plugging away at the code for longer than I’d care to admit. I knew at this point that there was some kind of internal processing of this form parameter going on, and was ready to resign myself to spelunking in the source to figure out what it was. Since this was such a basic operation going on here, surely this had to be a bug in the framework excited by an as-yet-undetected subtlety in my form markup. Surely. Then it hit me: the form code I was debugging used . Shouldn’t that be ?

Sure it should, if g:submitButton is all you ever use. I’ve never been a big fan of scaffolding—a conceit I have long suspected is to my detriment, and one I am currently in the process of reforming—and I had never had occasion to become familiar with g:actionSubmit. What that magical tag does is allow you to include multiple submit buttons inside a single form, each of which targets its own action within a given controller. Great idea, and great tag. And an epic failure if you’re trying to accomplish mapping through the tag and ignore the submit button tag’s parameters altogether.

I’m tempted to conclude that the moral to the story is to know how your web framework accomplishes simple tasks like form submissions, even if it throws a few nice features your way to spice them up a bit. And there is nothing wrong with knowing this; in fact, it’s a good trick if you can do it.

The real lesson, however, is about debugging. Ohm’s Law is never, ever, ever wrong, and when you sit down with ohmmeter and oscilloscope and proceed to prove that it is, all you’re doing is establishing that your mental model of the problem is badly off-base. Grails, like any web framework or well-used public API, sometimes is wrong—it is not a fundamental physical law—but public releases probably aren’t wrong about trivial things like form submissions. If you think you’ve got a bug so obvious that someone had to have caught it in the past, then somebody probably did. The bug is probably with you, either trivially in your code or even in your debugging process itself. In the heat of the chase, it can be difficult to remember this, but how often is the resolution to the story actually some complex subtlety that takes hours to explain? Sometimes it is, but most of the time you’re just using the wrong tag. Looking for the obvious is probably going to pay off well in advance of a deep dive into the code. Or, for that matter, a reconsideration of classical physics.

I’m building some simple .NET web services in a VMWare Fusion VM running Windows XP. I’d like to consume those web services from Grails code I’m developing on the host OS, which is a Mac. The easiest way to hit IIS in the VM is to switch the network connection to bridged mode, as shown here:

I had been doing this happily for a week or so, when suddenly yesterday afternoon it quit working. I tried to put a new VM into bridged mode, and I got this unhappy dialog box:

The guest OS (Windows XP) was insisting that the network cable was unplugged on my virtual LAN adaptor, and I had no way to hit my .NET services from the glorious host OS. Googling around a bit suggested that this was a problem when the Mac had more than one network adaptor configured, but that made no sense: I always have two network adaptors (wireless and wired), and have done bridging successfully while using one or the other, and sometimes while both are recognized by the OS as live options for network traffic.

Skipping to the end for your convenience, it turns out the problem was with the VPN. I can use bridged networking as much as I like, just as long as the Mac is not connected to the VPN. Even if I try to establish bridged mode while disconnected from the VPN, then connect to the VPN afterwards, it still disabled by bridged network adaptor in the guest OS. Host VPN and bridged guest simply will not coexist.

Which is great and all, but the .NET services I’m running in XP need to connect to a database server available on the client’s private network, so without a VPN, I’m sunk. The happy ending is that I can establish a VPN connection in the guest OS—in Windows—while the Mac is happily VPN-free. This still disables some of the tooling I rely on for efficient development, but it’s as good as it’s going to get, and ultimately, it’s workable.

Two weeks ago I finally succumbed to the temptation to order a Kindle. Availing myself of my Amazon Prime subscription—a service which may now find itself obsolescent—I had the device in my hands last Wednesday. My goal wasn’t just to have a new and more convenient way to read, but to figure out whether the Kindle actually delivers on that promise.

It came out of its elegant, Apple-like packaging with an image on its screen—not something you expect from a powered-off device. Having seen a Sony ebook reader before, I expected the Kindle’s screen to look fake, and it did. It was as if someone had cut out a piece of printed paper and glued it on the front of the unit. Its somewhat odd power switch worked fine, and it turned on after a few seconds. It was easy to connect it with my Amazon account (I don’t even remember the process, in fact) and wirelessly browse the Amazon store through the 3G “Whisperlink” connection. My first book purchase, which I made from the web site on my laptop, appeared on the Kindle quickly.

My first impulse, and the first impulse of several other new users who got their hands on it, was to tap the screen. I expected to swipe to turn pages, and I presumptuously expected a multi-touch gesture to bring up a coverflow-like view of the pages through which I could scroll by swiping. Somehow I doubt my reaction is unique, at least among iPhone users. At first blush, it seems imperative that future generation devices support a touchscreen.

Actual reading is quite pleasant. Text is almost suspiciously crisp and passive-looking, just like a printed page. The digital paper display is famously slow to update, reminding me of laptop screens from twenty years ago. This makes interactive functions like scrolling through menus, navigating tables of contents, or shopping in the store somewhat frustrating (and it would render my expected touchscreen functionality all but useless), but is easy to overcome in actual reading. I soon learned to anticipate the page refresh delay by pressing the next page button while my eyes were somewhere near the beginning of the last line of text on each page.

Later, I pushed a few of my book purchases to the Kindle app on my iPhone. There is an immediately obvious difference in the feel of reading on the iPhone and on the Kindle. On the iPhone, the expected touch gestures work. There’s still still no multi-touch coverflow interface, but there is a draggable slider that quickly scrolls to any location in the book. The book seems more interactive, and has a massless quality to it. Compared to the Kindle, the iPhone screen itself looks alive. You can quickly be anywhere in a text almost as easily as flipping the pages of a bound paper book. The same text on a Kindle has some random access capability through the table of contents and the search function, but otherwise the slow speed of the display rewards sequential, page-after-page reading.

In other words, reading the Kindle is more like a reading scroll than a bound book—a scroll with a search box.

So my first reaction is positive, and I’m going to continue favoring it for the delivery of new books when possible. I’d like to use it for several different kinds of material (i.e., fiction, technology, theology, article-sized works, etc.) to get a sense for how the different reading habits associated with different texts work on the device. My larger question, which can only be answered over the course of months, is how the new form will alter my reading habits and my perception of the texts themselves. Even if, pace McLuhan, the medium isn’t identical the message in a strict sense, the message is clearly shaped and constrained by the medium in important ways. It seems clear that ebook readers will be a big part of the future of text, so understanding the new form might be a good plan.

I had a great time speaking at DOSUG last night on Talend Open Studio, the eponymous open-source ETL product by the French start-up. I realize ETL doesn’t exactly capture most developers’ imaginations the way cool dynamic languages or cutting-edge web frameworks might, but I think we had fun. The attendees were engaged and had many good comments and questions. I suspect at least a couple of them know the ETL landscape a lot better than I do, but they seemed happy to know there’s a credible open-source product in the marketplace.

I had two main examples to show. The first was a simple (and contrived) transformation of an OPML file into an Excel spreadsheet and a text file. The Excel file contained a list of the names and URLs of all my feeds in a human-readable format. The text file was supposed to contain a list of the unique link types (hint: they were all “rss”), but that part of the demo actually didn’t work properly due to some fault of mine. This being an occupational hazard in live coding not to be dwelt upon when your audience is patiently waiting, I dropped it and moved on.

After the first demo, I talked about basic data warehousing principles a little bit as outlined in by Kimball and Caserta. This kind of thing is tricky with a diverse audience, because the speaker runs the dual risks of insulting the informed and not informing those new to the subject. Brevity is usually the best policy.

The second demo showed a real-life transactional schema from a start-up I had been involved with a few years back. (The present custodians of the data were kind enough to share a sanitized copy of it with me for this demo.) I showed a few transformations of transactional data of varying levels of complexity into the relevant fact and dimension tables, including some look-ups from external text files and one or two interesting joins on the transactional inputs. Mind you, I didn’t proceed to show any neat analytical tools running on the newly minted warehouse, but the OLAP world is your oyster once the ETL job runs to completion. Relatively speaking.

I was frank about Talend’s weaknesses. There are a few tutorial screencasts on the web site, but other than that I don’t consider the getting-started documentation to be particularly smooth. The Business Modeler is a confusing addition to the product—a third-rate drawing program that distracts the newcomer and adds no discernable value to the suite. The lack of credible Mac support is as disappointing as it is surprising, given that the tool is entierly Eclipse-based. However, I still see the tool as an option very much worth evaluating if you have needs in the space.

All in all, I’m happy with how the talk went, and I’d like to put the tool to use in a production environment at some point soon. I hope to be able to make a few upgrades to the talk and give it at some other local groups as the opportunity arises. I’ll update with a link to Slideshare as soon as I get the deck upgraded.

Another thing: as , I did wear all black to the talk. And yes, Matthew McCullough did play a Johnny Cash song just before the meeting got started. See his post on the event for another account of how it went.

The effect of a No Fluff, Just Stuff conference is not unlike that of a conversation with a beautiful woman: afterward, you feel simultaneously like you can do anything, and also like you’re the biggest moron ever to walk the face of the earth. The analogy runs out of gas pretty quickly after that, but still: you can’t help but feel pumped when you’re done with the weekend.

The networking was, as always, first-rate. I got to reconnect with Denver-area peers I already knew and make new acquaintances as well. The speakers themselves are also very accessible at No Fluff, and I enjoyed getting to get to know several of them a bit. Most of these guys are pretty big guns, but you never get the idea that they believe their own press, as the saying goes. If you want a chance to talk to or even share a meal with published authors and industry thought leaders, this is the conference for you.

Here’s a brief summary of some of my favorite sessions:

JVM Memory and Garbage Collection, by Ken Sipe. Ken led us through the structure of the Java heap and the life cycle of that Java objects that live in it. He showed us the heap monitoring tools we should be using. My ignorance of the JVM’s memory management was nearly complete before this session, so it was quite an eye-opener for me. I now see how a poorly configured heap can hobble the performance of a program that should otherwise run well on a given hardware configuration, and I know how to begin diagnosing such a problem. This was one of those sessions that leaves you wondering, “How could I not have known that?” But now, next time I run out of memory, -Xmx is the last thing I’ll be doing.

It occurred to me while listening to Ken speak that some exposure to embedded systems would be good preparation for this material. Only during Ken’s keynote that night did I discover that he (like another outstanding software engineer I know fairly well) began his career in firmware. So there you have it.

Security Code Review, by Ken Sipe. My notes on this session were not great, due to the combination of flaky WiFi and my strange and unexamined unwillingness to take notes in anything but Google Docs. (And yes, Docs supports offline editing with Gears now, but you can’t create a new document without an Internet connection.) However, I had two takeaways: first, that security considerations ought to pervade the development process, rather than be tacked on the end in an external review, or worse, in response to damaging exploits and bad press. The second was Ken’s proposed threat model, which struck me as a handy and reality-conforming way to think about the bad things that people can do to your software.

JSF: Whirlwind Tour, by David Geary. I am not a JSF user, nor am I a likely JSF adopter in the near future. I understand that JSF enjoys very good uptake in the enterprise, but most of my work is done outside of a classical enterprise context, so it’s probably just not something I’m going to do much. Going for the throat, one might even say JSF is the buttoned-down nerd of the technologies covered at NFJS, relying heavily on tooling, enjoying the embrace of the likes of Oracle, and being all JSR-y as it tends to be. I mean, compare this to the shorts-and-Birkenstocks free love of Grails! No contest among the self-proclaimed cool kids.

Nevertheless, if there’s anybody who can make JSF fun, it’s Dave Geary. This is a technology that is in no way near and dear to my heart, but I really enjoyed learning the basics in this talk. You can’t go wrong listening to this guy. (And for the record, you can go wrong thinking you’re too cool for JSF. It may, in fact, be a bit more buttoned down than other options in the space, but there are more developer jobs open right now for it than for Grails, hot shot.)

Git Control of Your Source, by Stu Halloway. This was one of four very good Stu talks I attended, and easily the most impactful. The cool kids have been refusing to allow me at their lunch table since springtime for my continued use of Subversion, and now I have some idea why. I have heard Git sold as a decentralized version control system, which synchronizes many noncanonical repositories across a project rather than rely on one centralized server—sort of a postmodern VCS, in terms Brian Sletten might appreciate. Stu actually didn’t cover that aspect of Git all that much, but instead focused on its more sophisticated concept of what constitutes a controlled file, a “commit,” a branch, a merge, and so forth. VCS scatology was discussed. He  made the point strongly that SVN discourages branches by imposing too much cognitive cost on the practice (largely through the anticipated difficulty of resolving merges or changing plans with a branch-in-progress), which is precisely the kind of thinking about tools we should be doing more of. It’s not the mechanics of what is technically possible with a tool that are important, but rather the woodgrain of that tool or the intellectual sensibilities it engenders that matter over the long term. Git doesn’t want you to worry about what will happen to the repository when your workstream is interrupted, and it makes it cheap to accommodate those interruptions when they occur. I predict this more than anything else will turn out to be a compelling reason for its adoption. We shall see.

This weekend was the first opportunity I’ve had to hear Stu talk, and I’m very glad I did. He’s a great speaker and a quotable guy, plus his laptop has a name nearly as clever as mine.

FP on JVM, by Venkat Subramaniam. I have in the past described Venkat (accurately) as a live-coding ninja. His Livecode-Fu was in evidence in this talk, in which he covered the basic concepts of functional programming with examples mostly in Erlang, Haskell, and Scala (with some Groovy for illustration purposes). Having been a Computer Engineering major, I can still do some elementary op-amp circuit design, but I am complete functional programming n00b, never having seen so much as a line of Lisp or Scheme in my undergraduate program. This left me at a bit of a deficit at the start of the talk, but Venkat did a good job introducing the requisite concepts and illustrating them in code. This truly was a good introduction to functional programming concepts in emerging languages of the JVM (plus Erlang, which does not run on the JVM) in Venkat’s inimitable and highly dynamic style.

Sometimes Venkat’s live coding feature becomes a bug when you try to take notes on one of his talks. There’s no way I can type as quickly as he can bang out code in his highly Bundled copy of TextMate, but happily the slides contained complete listings of everything he did. It will be easy to refer to them for review going forward.

Groovy Metaprogramming, by Jeff Scott Brown. Mere minutes before I left the home office for the start of the conference, I was coding an ugly hack to work around a “bug” in a Groovy MarkupBuilder I was using to render some XML in a Grails action. The darn thing wouldn’t emit XML for an element called “phoneNumber,” and I couldn’t immediatley figure out why. I hacked it into submission in a most shameful fashion, realizing there had to be a better way, but not knowing what it was. When Jeff covered closure delegates, I smelled something promising, but when he went over Builders, I knew I had my fix. I actually changed the code right there in the session and committed it to the SVN repository (not yet having sufficiently internalized Stu Halloway’s Git talk). Thanks, Jeff!

I already knew a fair amount of the Groovy metaprogramming material besides that, but this fix was definitely worth the price of admission.

Well, with the Dow making its biggest single-day point gain ever today, maybe things aren’t going to be so bad after all. However, the economy is still on everyone’s mind these days, especially us independent consultants. Will shrinking demand for development services cause our business to decline, or will hiring freezes and tight budgets cause IT managers to look to variable-cost options like consultants and small development firms to keep key projects alive? Time will tell.

In case it’s the former, I’ve put together my predicted top ten growth industries for 2009, so we can all focus our limited resources wisely:

1. Brisk trade in gold, guns
2. Generating electricity for
3. Foraging for nuts and berries
4. Being a Democrat in elected office/Not being a Republican (tie)
5. Repurposing credit default swaps into lightweight, waterproof shelters
6. Issuing public guarantees of underperforming bank assets/nationalizing the banks (tie)
7. Innovative financing methods to enable less-creditworthy borrowers to participate in the dream of home ownership, only in this case the dream is a blood-chilling national nightmare
8. Law practice specializing the the raft of rushed and poorly thought-out regulations about to be imposed on the financial industry
9. Fix and flip!
10. Providing Agile training and coaching at recession-sensitive prices to give businesses the tools they need to remain competitive in the face of shrinking budgets and to position themselves for success in the recovery, following Tim Bray’s recent suggestion

With so many options to choose from, 2009 could still really be an exciting year. As for me, though, I think I’m going to go with #10. Who’s with me?

At the DOSUG meeting last night, Matt Quinlan talked to us about his company’s product, Appcelerator. Appcelerator seems at first blush to be another JavaScript framework wanting to make AJAX and UI widgets easier, but actually does have a pretty neat spin on the problem that makes it something more than just another dōjō or jQuery. Appcelerator brings delcarative, remotable messaging to HTML. Put another way: the Observer pattern is back in your web UIs, and it misses you.

Early in his talk, Matt laid out the competing philosophies in the RIA space: to wit, plug-ins vs. the open web. These terms themselves are a bit tendentious (whatever is the opposite of “open” can’t possibly be good), and some of his arguments in favor of the open web were a bit thin, but at the end of the day I am with him here. Despite the power of the Flash plugin to deliver pixel-perfect UIs, cross-domain networking, and snappy user interaction with impunity, I still think HTML, CSS, and JavaScript are the best way to go most of the time. Call me a masochist.

Appcelerator includes some nice UI widgets and a framework-agnostic means of wrapping others’ JavaScript- or Flash-based UI widgets with a consistent API, but the talk was not about the widgets. The real value of Appcelerator comes in its in-browser message bus. Using nonstandard HTML attributes in your markup (something like

), any of a large set of DOM events, key presses, mouse events, drags, drops, etc., can be published to a message bus running in the page in JavaScript. Likewise, any scriptable element can be delaratively advised to subscribe to messages in the bus. Thus HTML elements become Observers of an impressively generalized stream of events in the browser, and you are free to think about your UI at a level of abstraction bordering on the appropriate.

But wait, there’s more! The message bus isn’t constrained to the browser alone. You can publish messages to remote endpoints, which in the case of Java are consumed by annotated POJOs on the server (presumably through the agency of a canned servlet-cum-Controller you’ve mapped in your WAR). Back-end services are responsible only for returning JSON data, which is more or less automatically consumed by the Appcelerator front end according to some friendly-seeming naming conventions and the message subscription declarations already described. This is cool in the extreme.

This architecture has several positive implications. Chief among them is that your HTML pages become an entirely static resource, able to be served from a vanilla Apache instance disconnected from Tomcat, JBoss, WebLogic, the Black App Server of Mordor, or whatever. Your code does not render HTML anymore. Further, it becomes easy to mock back-end services in pure JavaScript. This allows front-end developers to write a complete and functional front end user interface—an artifact which is not a mock in any sense of the term—while easily mocking the back-end services by including a single JavaScript file. This JavaScript mock (really just a bunch of functions returning some JSON) then becomes the ultimate Agile spec document to be consumed by the back-end team one iteration at a time. It’s like the product practically builds itself.

And hey, as an aisde: some Appcelerator ninja should suggest a convention for this mock file, perhaps using JavaDoc-like comments that could easily be processed at build time into a publishable HTML spec document for quick reference. The code itself shouldn’t be too hard to read, but this extra step would be a nice touch.

Matt also talked about tooling a little bit, but with Appcelerator’s embrace of the open web, the tooling question becomes less important as a part of their value proposition. They can assume that we all have tooling we like for building HTML, CSS, and JavaScript—or perhaps more to the point, tooling we hate, but tooling we at least can call our own.

Appcelerator  was founded and is advised by veterans of the open-source world, including Matt himself, who was Employee 31 at JBoss and an early hire at Appcelerator. The company’s site puts forth the image of an open-source startup, but there is no mention of any way to give money to them, and Matt was coy on this question when I asked him. Given the recent tremors in the Enterprise Java community caused by Spring Source’s changes to their support policy, I feel a new sense of caution on this front. The product is licensed under Apache 2.0, so there’s no questioning its open-source-ness, but I’d still feel a little more relaxed about trying to adopt it for a future project if I knew how the company planned to make money some day. Now, don’t get me wrong; I love philanthropy, but the knowledge that somebody, somewhere is trying to make money from a product I use still gives me a certain sense of comfort, as if I need not speculate about future motives or present sources of funding. It makes sense that Appcelerator would be giving things away with abandon now, while trying to grab market share, but I’d recommend that they modify their messaging to include something about their future business plans. It would just give us a warm fuzzy, is all.

Notwithstanding that minor note of caution, this is a really impressive product that I’d like to try to take for a test drive as soon as I can. I’m very glad to have seen Matt’s talk.