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

I wrote about Sun's Lively Kernel web browser based programming environment last month and watched this excellent Lively Kernel talk by Dan Ingalls this morning. I especially liked one point that he made: with the right architectural decisions systems can be fairly simple and still be general.

The demonstration on the video is both impressive and serves as documentation if you want to experiment with the Lively Kernel yourself. As it is, the Lively Kernel is a good prototype but if the performance is improved a bit and the programming environment and IDE (which is like Squeak Smalltalk, only for Javascript) continues to improve, then Lively Kernel is on my (personal) radar for something that I will use in the future.

I remember getting a Xerox 1108 Lisp Machine in 1982 and I also wanted the optional Smalltalk environment which was not in the budget. However, a sales engineer at Xerox did let me use Smalltalk for a month on a trial basis. It is amusing to be able to get a smalltalk like programming environment like Lively Kernel for free that is hosted in a web browser. Something about Moore's Law and also about free software projects...

Off course, by far the best free Smalltalk experience is Squeak but Lively Kernel is still very cool, if only for its possible future use of quickly writing web interfaces using existing web services, etc.

Labels: Javascript, Smalltalk

I experimented with Mjt last year: Mjt is a client side template system: Javascript is used to merge data from JSON web service calls with templates to generate HTML - all in the browser (except for data fetched from a server). Mjt looks solid and has been fairy widely used; an alternative client side framework is Sun's experimental (not for production use!) Lively Kernel project. If you have not played with Lively Kernal, give it at least a one minute try - it uses the Morphic GUI framework, so if you have used Squeak, it will seem familiar.

The big problem, as I see it, of client side Javascript frameworks is issues of maintainability. I have worked with Javascript heavy web applications that other people originally wrote and they are definitely much more difficult to jump into, understand, and modify compared for example to AJAX heavy Rails applications or GWT web applications.

That said, there is something tidy about the idea of writing web applications in two intertwined but separate tasks:

• Writing JSON web services and separately unit testing them
• Interactively developing the client side with a framework like Mjt

I like to recognize technologies as early as possible that I might use in the future. Although I don't (yet) feel really comfortable working with frameworks like Mjt my gut feeling is that this is the future because it makes it easier to work with multiple languages and platforms for implementing web services and makes it easier to mix up data from multiple sources.

Labels: Javascript

I thought that Adobe Apollo might have hit a sweet spot for allowing developers to create hybrid desk top and web applications. I think that Google may have hit a sweeter spot with Gears. Gears installs as a FireFox add-on and uses the SQLite database to store data locally on your file system. Each site that you visit that is 'Gears enabled' causes a pop up permissions dialog to appear - I recommend being careful of which web sites you allow to use the Gears add-on. I have reviewed the developers' documentation and it looks straight forward to set up and a Javascript SQL database API makes it easy to use SQL in your Javascript.

Labels: AJAX, Javascript, web applications

As I wrote a few weeks ago, someone working at Danny Hillis's start up Metaweb recently gave me an alpha invite to freebase so I have been experimenting with both their web services APIs and web application as I get some free time. Very cool stuff.

The freebase developers have released the mjt Javascript template library under a BSD-like license. This library enables you to write rich client applications based on web services that return JSON data. It takes more than a few moments to get used to the idea of client side templates but if you are used to server side tools like Java Server Pages (JSP), etc., the ideas are similar. I have done nothing with mjt (so far) except for reading the documentation and playing with the demos, but my first impression is that mjt would be very useful for developing web applications using back end services that are implemented in several languages/platforms that accept REST requests and return JSON.

I have been getting very comfortable with Javascript in the last year. I wrote an AJAX enabled web application for my customer yesterday and today using Common Lisp on the back end with client side implemented as Javascript, CSS, and HTML - a nice combination of REST web service calls to process AJAX calls and Lisp code to generate HTML as needed. If I was already fully up to speed on mjt, a reasonable alternative would have been to limit the back end Lisp code to just providing the REST web services and serving up static content. Anyway, mjt is well worth looking into.

Labels: Javascript

I have been investing a fair amount of time learning the Dojo Javascript library but I had an application where I only needed AJAX to handle HTML form input - I wanted a server side function to return HTML to be inserted below the form. Dojo is a huge library so I pulled the prototype.js library out of one of my old Ruby Rails projects (prototype.js is only about 70KB). I put the following in my form JSP page:

<form id="myForm2">
 <input type="text"  id="input_test_form_text" />
 <input type="button" value="Search" onclick="getS()" />
</form>
<div id="searchresults"></div>

<script type="text/javascript" src="prototype.js"></script>
<script>
 function getS() {
  var params = 'query=' + $F('input_test_form_text');
  var x = new Ajax.Updater('searchresults', '/ajax_search.jsp',
                           {method: 'get',parameters: params});
 }
</script>

The follow is a trivial server side JSP ajax_search.jsp that does nothing but returns the original query as an HTML snippet:

<%@ page contentType="text/html;charset=UTF-8" language="java" %>

<%
    String req = request.getParameter("query");
    out.println("<p>request for 'query' is:" + req + "</p>");
%>

Labels: AJAX, Java, Javascript, JSP

Although I spend most of my time working on artificial intelligence (AI) projects, I have spent a lot of personal time in the last year working on basic web application skills. I have been prototyping a system using the Dojo Javascript library - great stuff, but definitely heavy weight. However, by loading up all required Dojo library and application specific Javascript at once, and then using AJAX does provide a responsive user experience - after the initial load up time.

After dinner last night, I re-wrote the web UI for my current commercial development project using minimal CSS, HTML, and a small amount of Javascript - although switching work contexts now requires fetching more resources from the server, the amount of data transfer is minimal and the web app is still very responsive, even factoring in slower network connections.

I have looked at Open Lazlo and other heavy weight client frameworks - they look great, but for someone like me whose primary work does not involve building web applications, I like reducing my own learning curve by choosing technologies that cover all of my requirements and simply using them unless some far more compelling comes along.

Labels: AJAX, CSS, Javascript

Javascript is a flexible functional language similar to Common Lisp and Scheme, if not in syntax, at least in spirit. Bruce Tate wrote a good overview JavaScript's language features that is well worth reading.

I find HTML's DOM model to be unpleasant to work with, but Javascript the language is fun to use. I have been using the Dojo toolkit a lot lately and the authors of Dojo have done a fine job of building a platform that insulates programmers from the hassles of DOM and browser incompatibilities.

I am currently working on another AI book (using Ruby for the examples) but I would enjoy later writing a Javascript book from my own perspective (a developer who wants to use the same Javascript skill set when developing using Ruby on Rails, Java, Common Lisp, etc.).

Labels: Javascript

I have been using the fine Dojo Javascript library in a web app written in Common Lisp and this morning added Dojo to the code base for a current Rails project. The easiest way to get started using Dojo and Rails is to simply install the developer's version (non-compacted) of dojo.js and the src directory directly in your Rail project's public/javascripts directory, so it looks like this:

public/
  javascripts/
    dojo.js
    src/

Again, the "src" directory contains the dojo source files (besides the dojo.js loader). Dojo will complain about rendered Rails web pages withot HTML and HEAD tags, so I added the following HTML with Dojo setup to the view for my main application controller:

<html>
 <head>
  <title>KBSportal KnowledgeManagement</title>
  <script type="text/javascript">
  djConfig = {isDebug: true}; 
 </script>
 <script src="/javascripts/dojo.js" type="text/javascript"></script>
 <script type="text/javascript">
  dojo.require("dojo.io.*");
  dojo.require("dojo.event.*");
  dojo.require("dojo.widget.TabContainer");
  dojo.require("dojo.widget.LinkPane");
  dojo.require("dojo.widget.ContentPane");
  dojo.require("dojo.widget.LayoutContainer");
  dojo.require("dojo.widget.Checkbox");
 </script>
 <style type="text/css">
  body {
   font-family : sans-serif;
  }
  .dojoTabPaneWrapper {
     padding : 10px 10px 10px 10px;
  }
 </style>
</head>

Dojo is definitely "heavier weight" than the prototype.js Javascript library that is provided with Rails so you may not want to use Dojo for very high traffic sites.

Labels: AJAX, Javascript, Lisp, Ruby Rails

I feel like I have come full circle (almost) in AJAX development: I started out a few years ago adding some simple AJAX enabled forms to a JSP based application. When first starting out, it took hours to get something working. Then a year ago, I discovered how simple it is to use AJAX in Rails: fine, except that Ruby does not have high enough performance for some applications (unless large parts are written in C - Ferret, for example).

I have spent many evenings playing around with various release versions of the Google Web Toolkit (GWT) and it is very compelling, especially if you already are used to developing GUI applications in Java - the only new wrinkle worth mentioning is getting used to handling events asynchronously. The problem with GWT is that it really does tie you to the Java platform. I spend most of my time developing AI applications, but that said, who does not want basic knowledge and competence at building web applications?

I use Common Lisp, Java, and Ruby for development, so for the occasional AJAX tasks that I have, I have settled with the well respected dojo Javascript toolkit because it plays very well with both Lisp and Java JSP based web applications. Dojo is also easy to use with Rails, if you want an alternative to Rail's great AJAX support.

By using Dojo, I basically have to deal with just one learning curve no matter what platform I am developing on. Here is a simple example for a JSP page (assuming that this would be more interesting to most people than a Lisp example):

Add this to your <head> section on a top level JSP page:

    <script type="text/javascript">
     var djConfig = { isDebug: true };
    </script>
    <script type="text/javascript" src="dojo.js"></script>
    <script type="text/javascript">
            dojo.require("dojo.io.*");
            dojo.require("dojo.event.*");
    </script>

Then try putting this somewhere on your JSP page (note: this assumes that you have another JSP page ajax.jsp that gets the form values and returns content to be placed into the DIV element with ID=ajxplydiv. Anthing that ajax.jsp writes using out.print() gets inserted asynchronously into the "ajxplaydiv" DIV element):

    <h3>test AJAX Form:</h3>
    <form id="myForm">
        <input type="text" name="input_test_form_text" />
        <input type="button" name="button1"
               value="Try AJAX form" id="ajaxButton" />
    </form>

    <div id="ajxplaydiv">
       initial context for AJAX play div
    </div>

    <script type="text/javascript">

    var buttonObj = document.getElementById("ajaxButton");
    dojo.event.connect(buttonObj, "onclick",
                       this, "my_onclick_button");

    function my_onclick_button() {
      var ajaxargs = {
        url: "ajax.jsp",
        load: function(type, data, evt){
           dojo.byId('ajxplaydiv').innerHTML = data;
        },
        error: function(type, data, evt){
         alert("Error occurred!");
        },
        mimetype: "text/plain",
        formNode: document.getElementById("myForm")
     };
     dojo.io.bind(ajaxargs);
   }
</script>

The call to dojo.io.bind sends a request containing the form data to the ajax.jsp page, and whenever the results are returned then the Javascript functions "load" or "error" defined in the data block in my_onclick_button() is called. This is just one example of processing form data and adding HTML below the form without refreshing the page - but is a common use case for using AJAX. This example assumes that I have both the dojo "src" directory and dojo.js in my top level web resources directory. The great thing about dojo is that it encapsulates all asynchronous event handling, offers a good supply of visual components (that map to HTML elements) and is simple to use no matter what programming language you are using for a web application.

Labels: AJAX, Java, Javascript, Ruby, search

I (mostly) earn my living designing and developing interactive web applications and web services. Putting up with different implementations of CSS and JavaScript in FireFox, Safari, IE, etc. seems like a small price to pay in order to enable anyone to use a web application with a browser.

That said, I love it when web portals open up their systems with public APIs. Flickr's API is especially nice since they support REST, XML-RPC, and SOAP. For Mac OS X 10.4 users, there are two great Flickr rich ("fat") clients that I think are very cool: Flickr Export for iPhoto and tickr for Flickr which allows you to search on Flickr tags and see a scrolling list of matched thumbnail pictures that scroll up the right side of your desktop.

The important thing here is that Flickr did not have to write these fat clients - they just had to make a public web services API available.

Labels: CSS, Javascript