Mark Watson's opinions on Java, Ruby, Lisp, AI, and the Semantic Web

I have been working on and off for 16 months on a book about Semantic Web (or Linked Data) application programming using the AllegroGraph product. I have decided to substantially increase the scope of this applications/tutorial style book to also include support for Sesame. The figure on the left shows the software architecture road map for the book using JVM languages.

I am splitting the book into two volumes, and using Latex makes this really easy to share small amounts of common material so both books stand on their own. Latex also makes it easy to combine both books into one all-inclusive book, eliminating the duplicated parts. The two volumes are:

• Volume I: will cover the use of both AllegroGraph and Sesame using JVM languages: Java, Scala, JRuby, and Clojure. I am working on a common wrapper written in Java that supplies my own (rather simple) API to both AllegroGraph and Sesame. My wrapper implements Sesame support for geolocation and free text indexing and search so the wrapper is adequate to run all of the book examples using either AllegroGraph or Sesame "back ends."
• Volume II: will cover only AllegroGraph using both the embedded and client Lisp APIs.

Both AllegroGraph and Sesame are great development tools, but fill different needs. On projects that can support a several thousand dollar a year per server license fee, I would choose Common Lisp + AllegroGraph for development. AllegroGraph is very scalable and the Lisp APIs are really nice to work with. For Java (or other JVM languages) applications, I would still choose AllegroGraph for the scalability and support if a project can support the license costs. The good thing is that for most small to medium size projects, the free version of AllegroGraph or the open source Sesame project both are good choices, so as a developer you have some real flexibility. There are also other good RDF data store platforms like Jena, Joseki, Kowari, Redland, 4store, Swi-Prolog Semantic Web library, Talis, Virtuoso, etc. but I have relatively little (or in some cases no) experience with these. I use AllegroGraph and Sesame so that is what I write about.

Labels: Clojure, Java, JRuby, Latex, Lisp, RDF, Scala, semantic web

I finally got around to trying nailgun tonight. On OS X with JRuby 1.4.0RC2, I built nailgun using:

cd JRUBY_HOME/tool/nailgun
./configure
make  # I ignored the warning "no debug symbols in executable (-arch x86_64)"

In one terminal window just leave a nailgun server running:

$ jruby --ng-server
NGServer started on all interfaces, port 2113.

When you want to run JRuby as a railgun client, try something like:

jruby --ng text-resource.rb

On my MacBook, this cuts about 5 seconds of JRuby startup time off of running this test program.

Sweet. For small programs, using ruby is still faster than jruby but this makes developing with JRuby faster.

Labels: JRuby

Although I have been paid to work on both the Enhydra Enterprise Java application server and on the JBoss based Jaffa framework, I must admit that Tomcat has always been my favorite platform: lean, and add just what I need.

As a result of my 'build up just what I need' preferences, I just got around to experimenting with Glassfish. The Update Center is great, and as more instant install frameworks and applications become available, this will be a time saver. The web admin tool is refined - no complaints there.

I do have one complaint about the 200 MB resident memory footprint. A lot of what I do involves deploying to low cost servers, often semi-managed VPS systems. Smaller memory use is cheaper, but for most large server deployments, an extra 100 MB makes no difference.

I thought that it was very cool that one of the available instant install components is JRuby with the most excellent Goldspike. I have written before in this blog about the ease of running Rails web apps with Goldspike and JBoss. With Glassfish and the Update Center, it is even easier. Cool stuff.

Labels: J2EE, Java, JRuby