RefTagger

I've added Logos RefTagger to this blog. I have to say from a user standpoint it's pretty cool. It auto-links Bible references like John 3:16 or Gen 1:1-10. From a technical standpoint, it has some of the most impressive regular expressions I've ever seen. Once you drill into the regular expressions, it's not super hard to figure out what's going on, but at first glance they look like monsters. Kudos to whoever had the patience to work those out.

One thing I noticed is that the CSS for the tooltip has a rule:

#tooltipBody p {
  display:inline;
}

which causes multi-lined verses to run together without a space between words, e.g. Prov. 1:2 or Isaiah 54:17. The "display:inline" should be removed or there should be a space between the <p> tags for each line in the verse.

Open Source Software

Here's my philosophy on open source software: all software has bugs; at least with open source, you can debug it yourself instead of waiting for the author to do it.

Of course there are other benefits to releasing your software as open source and using open source, but that's a pretty big one for me. The early web service stacks had some real problems. I could work through the JBoss and Apache Axis bugs by fixing them myself, but for closed platforms, I was at the mercy of Microsoft, BEA and friends.

Events and Threads

Ed Ball over at Logos Bible Software has written an interested series of articles on events and threads. In part 3, Ed discusses locking around adding and removing delegates and firing the event. There is somewhat of a parallel in the Java world.

Java doesn't have delegates but by convention uses event listeners and the observer pattern. The observable keeps a list of listeners and iterates through them when firing an event. The same issue of locking the list comes up, but if consequences of not locking can be even worse. Most list implementations in Java do not handle the case where a list is changed while it is being iterated over. The iterator is invalidated and will throw a ConcurrentModificationException when hasNext() or next() is called.

One solution is to lock the list while adding and removing listeners and firing the event. This has the same problems that Ed points out in C# that it's scary from a deadlock perspective calling arbitrary code while holding a lock. Another solution in Java is to use the CopyOnWriteArrayList from the java.util.concurrent package or Doug Lea's util.concurrent package. It does exactly what it sounds like it does. This works perfectly for the observer pattern because its iterator is guaranteed to not throw a ConcurrentModificationException. It's expensive to add or remove listeners, but that typically isn't done very often. Before the concurrency tools were available, I would sometimes lock the list, copy it, unlock the list and iterate over the copy to fire the event. This is less performant in most situations because you'll probably be firing events much more often than adding or removing listeners.

Thanks again Ed for the interesting series.

Groovy DOMBuilder update

I finally got around to submitting my NSDOMBuilder code to the Groovy dev list. I got the "why didn't you just fix the existing class instead of creating a new one" response that I sort of expected, which made me go back and figure out what that didn't work when I tried it. Someone in that thread did point out StreamingDOMBuilder, which would probably work for the situations I need, except default namespace handling is currently broken in the releases, but now fixed in svn. It's not documented anywhere that I could find, but it's not too hard to figure out.

Very un-groovy

I really like Groovy as a language, but it does have its flaws. My colleague and I came across some very strange syntax and weird behavior surrounding GPathResult. GPathResult is fine and dandy for a read-only view of an object graph, but it does support some write operations. The documentation says you should only use it for read operations and then gives examples of how to write.

Unfortunately, those write operations are a bit broken. You can add nodes but the changes won't be reflected by the iterators or size() method. There is not method to remove a node, but you can effectively do so by replacing it with an empty closure. Unfortunately there are some downsides that as well because in some cases the nodes act like a linked list and if you replace one in the middle, you lose all the nodes after it.

Probably the worst thing about GPathResult is the overridden plus operator. I have never seen the plus operator overridden to perform a mutation on the object, but that's what GPathResult does. Take this from a mock Grails plugin for example:

class AGrailsPlugin {
    def doWithWebDescriptor = { xml ->
        def mappingElement = xml.'servlet'
        mappingElement[mappingElement.size() - 1] + {
            'servlet' {
                'servlet-name'('a')
                'servlet-class'('com.discorp.web.AServlet')
            }
        }
    }
}

That actually adds a new servlet node right after the last servlet node in the tree. That has to be to most un-groovy syntax I have seen in Groovy. It's not at all obvious what going on and it's very hackish. Unfortunately I don't think there is any other way to perform that function in Grails, though I have a ticket open for it.

Google I/O thoughts

I attended the Google I/O conference a couple weeks ago. Here are some thoughts I had from that.

Google has resource constraints, makes mistakes and misses deadlines too. They work in small, focused teams. 40% of Google’s new products in the last year have come out of 20-percent time projects. They do a lot of split A/B testing where they test different versions of the site on small groups and use metrics to determine what’s best. Google’s view is that anything that expands the web is good for Google, so they’re providing all these cool APIs for free.

It will be hard for a small company to keep up with the technology, especially if it is spread thin. Disruptive innovation will always happen before implementation and deployment of a current technology can be completed on a large project.

The web as an application platform is getting much better. It still sucks in many ways, like Javascript as a language, tool support, desktop integration, etc., but there initiatives to address those problems. Gears is a big step forward. SSBs (e.g. Prism and Fluid) and platforms like Adobe Air solve some of these problems. Web applications will never keep up with desktop applications in terms of user interface, performance, and integration.

Javascript still sucks. GWT does solve a lot of the suckiness, but what's the long term viability of it? GWT is pretty cool and is not an all-or-nothing venture, so it would be good to investigate. Javascript 2 is still a long ways off and may not even address the enough of the suckiness. This is a downside of going to a mostly web-based platform.

There seems to be a trend for moving more application logic to the client side Javascript layer of the application. This is necessary if offline support is to be achieved. This does open up security issues unless constraints are also enforced on the server side, creating duplication and therefore maintenance issues.

The web is moving away from RDBMSes as a back end data store. They just don't scale. An emphasis is being placed on what information is "current enough" instead of always the most up to date. In what contexts can this method be used vs. strict transactional, relational data? To what capacity does a project need to scale? That will be the biggest factor in determining whether or not to move to a data store like HBase.

Android is a cool platform, but will still be limited by the wireless companies that use it. No accessory (e.g. printer or signature capture pad) support in the near future and it's unlikely to be able to hack it in because you can't install native apps. It’s an open platform, but can and most likely will be locked down by the wireless companies. Android will have Gears support though.

Targeting WebKit will likely be the best way to get apps to the iPhone and Android phones for the next few years. It may be the only way to target both platforms without significant development overlap. It may be possible to provide specific hooks to the native platforms via browser plugins (currently impossible) or apps that embed the browser (will be possible on Android and iPhone 2.0, though limited).

The best way to develop apps for the web may be to determine if it is possible to deliver 80-90% of the requested features with just the browser and then make up the next 5-10% with optional native hooks. For example, one could deliver a web-based contact manager. If the user has installed Gears, the user can get offline lookup of some subset of contacts and perform some, but not all, actions on those contacts. Providing offline support will require architectural overhead, which may be minor or very significant – I can’t really say at this point.