Squeak without an OS: I don’t get it

Caught wind of a neat sort of project from OSNews about a project called SqueakNOS which seeks to implement the Smalltalk programming language as close to the bare metal as possible, i.e., without an operating system. It’s not that the real Squeak isn’t cool, but might this be somewhere along the same lines as Movitz is with Common Lisp?

It might just be me, but I’m very happy with my current OS (which is GNU/Linux) and I’d like to see better integration of virtual machines into the system before I do away with the system entirely!

Making things happen with the JOLIE programming language

I caught this really interesting interview over at the KDE news site which talks about a programming language called JOLIE which is used for what seems to be called service-oriented computing. Basically, it seems the admirable aim is to use JOLIE to increase compatibility by replacing inter-application frameworks like DCOP, DCOM and D-Bus. From the KDE perspective, it looks like there is work being done toward integrating JOLIE with Plasma, the KDE desktop shell which sounds to me like it would add a whole new level of programmable richness to Plasmoids. The interview from the KDE site and the JOLIE project page have more details and the concepts seem pretty cool.

Ubiquity search command tutorial

After enjoying using and developing for Ubiquity a great deal, I wanted to provided a brief howto for those wishing to get into Ubiquity command development. I wrote this after reading the command author tutorial (which you *must* read) and heavily consulting the source of the commands included in Ubiquity by default (which you *should* read). As you follow along, try the code provided in the command-editor which comes with Ubiquity.

In this tutorial, we are going to develop a search command that will retrieve word definitions from dict.org. For those who do not know, the DICT protocol (specified by RFC 2229) allows for the retrieval of word definitions over a network (maintained by The Dict Development Group) but they make a web interface available on the home page.

To create our command, we’ll need the following things:

  • Metadata: Ubiquity allows useful information to be embedded in the command itself. You can include data about the plugin such as it’s name, description and license along with the author’s name and contact info.
  • Search URL: This is the URL into which our search query will be embedded. You can figure it out by looking in your browser’s URL bar when you do a search or by dissecting the form which launches the search. In our case, I cheated by having Firefox add a keyword for the search field and then looking at it’s properties in my bookmarks organizer.
  • Icon: There is nothing wrong with a good presentation and it always helps to have an icon! For our example, I scraped the favicon URL from the dict.org home page’s source.

The standard way to create a Ubiquity command is with CmdUtils.CreateCommand() which takes an ordinary JavaScript object (written in object-literal syntax) containing key-value pairs defining your command. The definition for our dict command looks like this:

CmdUtils.CreateCommand({
        name: "dict",
            icon: "http://www.dict.org/favicon.ico",
            author: {name: "Jonathan E. Magen", homepage: "http://yonkeltron.com"},
            license: "GPL",
            description: "Retrieve word definitions from the <a href=\"http://dict.org\">Dict.org DICT server</a>",
            takes: {name: noun_arb_text},
            preview: function( pblock, directObject )
            {
                if (!directObject.text || directObject.text.length < 1) {
                    pblock.innerHTML = "Retrieves word definitions";
                    return;
                }

                pblock.innerHTML = "Retrieve word definitions for <i>" + directObject.text + "</i>";
            },
            execute: function( directObject )
            {
                var url = "http://www.dict.org/bin/Dict?Form=Dict2&Database=*&Query=";
                Utils.openUrlInBrowser(url + directObject.text);
            }
    });

At first glance there is a lot going on here, so take some time to look over the above snippet and check out some of the key features.

  • Metadata: As promised, the name, icon, author data, license and description are all there in plain sight with very little fanciness there. I chose to omit my email for fear of getting massively spammed but it can be included in there for those authors who wish to embed other contact info.
  • Argument declaration: takes: {name: noun_arb_text} is a neat little line which provides some info to Ubiquity’s natural language features. Essentially, it lets the parser know that the argument to the command is going to be some arbitrary noun in text form. There are other nouns of various flavors and I refer you to the source code examples and documentation mentioend earlier as this feature develops. Since Ubiquity is just smart like this, making this declaration lets Ubiquity know that any piece of text can be used as an argument. Therefore, highlighting a word and typing dict this will let Ubiquity know to lookup the definition for whatever word is highlighted.
  • The preview function: The preview function is used to provide a preview (shocker!) in the Ubiquity prompt pane before the command is executed. Since the argument to this can be either a string or a function, there can be an arbitrary amount of complexity here (for example, the Google map command uses the maps API to pre-fetch a smaller map showing you a dynamic preview). We’re going to take a very small advantage of that here and add a little prettiness to our command. As you can see, the preview function takes two arguments, pblock and directObject. The first one, pblock, is the HTML of the block where the preview is contained so anything done to that will immediately be reflected in the preview being displayed by Ubiquity for that command. The second, directObject, is the search term, in whatever form it has and is just what’s it’s called a direct object. If there isn’t anything in the directObject, the preview string is just a general usage statement. If there is something there, the preview string will indicate which word is going to be looked up.
  • The execute function: This is where the magic happens! The execute function takes only the directObject argument, splices it into the correct place in the search URL (in our case this is right at the end) and opens the URL in the browser using Utils.openUrlInBrowser().

See, this code isn’t so scary at all! In fact and indeed, it should be very easy to see that Ubiquity is actually quite flexible and clever.

Ubiquity comes with a number of helper functions which are very useful in command development. One such command is the makeSearchCommand() utility which provides a convenient wrapper around the more general CmdUitls.CreateCommand() function and takes fewer parameters. This helper function also makes certain assumptions about your search command and takes care of details for you, such as automagically declaring the argument as noun_arb_text and implementing the execute function for you based on the URL you provide. Using makeSearchCommand(), our command looks like this:

makeSearchCommand({
        name: "dict",
            author: {name: "Jonathan E. Magen", homepage: "http://yonkeltron.com"},
            license: "GPL",

            url: "http://www.dict.org/bin/Dict?Form=Dict2&Database=*&Query={QUERY}",
            icon: "http://www.dict.org/favicon.ico",
            description: "Retrieve word definitions from the <a href=\"http://dict.org\">Dict.org DICT server</a>",
            preview: function( pblock, directObject )
            {
                if (!directObject.text || directObject.text.length < 1) {
                    pblock.innerHTML = "Retrieves word definitions";
                    return;
                }

                pblock.innerHTML = "Retrieve word definitions for <i>" + directObject.text + "</i>";
            }
    });

The only major difference here is the passing of a the search URL with the {QUERY} at the end showing where Ubiquity should put the search term. The other parameters in the search URL for this example specify that this is a dict query and that results should be returned from all definition databases on the dict.org server.

This command definitons works exactly the same way as the one before it and has the same result. So, the moral of the story is that if you are creating a simple search helper command, then makeSearchCommand() is your friend.

I hope that this tutorial has helped to illustrate both the coolness of Ubiquity and the ease which one can develop commands for it. I eagerly encourage feedback in order to make this howto better and thank the Mozilla folks who gave us such a wonderful tool!

Facebook search for Ubiquity

I recently mentioned Ubiquity, Firefox’s new experimental command line for the browser. Anyway, I was tinkering about with the command author tutorial after the upgrade to 0.11 and browsing the source of the included commands when I decided to try my hand at authoring my own command. After messing about with some of the basics and testing things out, I came up with this, my own search command for Facebook. As of it’s current version, it’s actually very simple (making use of the excellent makeSearchCommand() helper function) and works just fine! Subscribe to it here for updates in the future.

Google releases new web browser called Chrome

Even after Google agreed to continue funding the overwhelming majority of Mozilla’s operating budget for another three years, they decided to be absolutely crazy and release their own browser.  It’s called Chrome and it’s actually really cool. The official announcement on the Google Blog is a little bit scarce on details but it does have a link to a 38-page cartoon (drawn by Scott McCloud) introducing the browser and it’s key features and concepts. Among the more notable cool points are sandboxed tabs (so when one page goes awry, the whole browser doesn’t crash), a super vast JavaScript interpretter (called V8) and ultra-tight integration with Google Gears along with other Google services. TechCrunch has details and alleged screenshots while Ars has a characteristically thoughtful writeup of the initial announcement. Chrome has some very cool ideas and the comic should be entertaining to almost anyone.

I do still wonder about certain things, even in spite of my curiosity and excitement. For example, although the browser is supposed to be Open Source, how liberal will the license be and what will it mean for Firefox?

Firefox to get crazy JavaScript speed increase

In a bit of really exciting news, I caught on to some news from the Mozilla world that future versions of Firefox will bring huge speedups for JavaScript execution. Ars Technica has a fantastic writeup on it and Reuven Lerner wrote a nice summary of things over at OStatic. Also, one of the Mozillazine blogs has some very telling data plots. This is very exciting because the speed of JavaScript code in the browser has been a major barrier holding back much development of true applications that live in the browser. Personally, I know that I’ve certainly experienced moments of irritation when waiting for some webapp to quit making my browser hang while waiting for some UI update or large sort to finish. Apparently, all of those little instructions add up!

What should my XML look like?

Great article from IBM Developerworks on how to design a good XML-based dataformat with maintainability in mind. Covers usage of namespaces, XSD and working with modules, extensions and format revisions. This is an interesting article because of how it treats the subject and the technologies so read it if you have even a peripheral involvement with XML.

Wait, so Firefox in Qt is not just a dream?

Well, it would seem that my tiny-little-private dream is not just a fantasy! It looks like Nokia is helping to port Firefox to Qt instead of GTK+, which I personally believe to be butt-ugly in most instances. This is most likely because I’m a proud KDE user…

IMHO, Qt is a better technical platform but I wonder if this is just a port of Firefox or whether it’s a complete Qt version of XUL and such. A complete port of XUL would actually be amazing and would have some serious potential! Even if it’s just an Firefox thing, I’d like to have my favorite browser fit in with my desktop a little better!

A $200 tablet?

A recent blog post on TechCrunch discusses their plans to try for the construction of a $200 tablet for light browsing with a modified Firefox 3 (in a special kiosk mode) and VOIP thanks to Skype. Now, we’ve heard rumblings of low-cost, touch-based computing devices before. Remember concept stuff from the XO-2 which was supposed to be the second OLPC? The idea was to have it be an ebook-style device with dual touchscreens and a sub-$100 price tag. Shortly following the announcement by the OLPC guys, some researchers from Maryland and Berkeley showed of a prototype ebook reader that responded to hand-generated movement like opening and closing the leaves to advance the displayed pages.

While the dream of a lightweight, $200 tablet seems a little far-fetched, the blog post does show that some serious thought went into this. They are very insistent that the proposed device run a stripped down version of Linux that will boot right into Firefox instead of a traditional desktop. From there, the plan is to have a special start page with “large buttons for bookmarked services” linking to sites of great interest and/or utility.

With this in mind, it stands to reason that SproutCore would be an excellent way to build this start page. By designing the startup page as a SproutCore application, the whole experience can be constructed in a completely customized way while still maintaining whatever parts of the traditional application experience are desired. Furthermore, SproutCore apps can be cached can be automagically and transparently upgraded as well as cached on the client so that basic functionality can be maintained even in the absence of a WiFi link.

After a little bit of thought, I think that the main interface (with the big buttons) should be a draggable grid of icons so that a user may reposition applications according to their preferences and usage patterns. Additionally, there should be a basic configuration interface allowing users to add or remove sites from the startup page. After that, anything else seems like an added complication even if it’s really, really interesting.

Wait, is static typing good or bad?

Though I haven’t taken that much time to learn about type systems, I have read up a little bit. I devoured Chris Smith’s essay on What To Know Before Debating Type Systems and briefly tinkered around with a typed lambda calculus before trying to really get into some of the heavier stuff that my program covered in a seminar earlier this year. All of this, combined with my personal experiences using dynamically and statically typed languages, gave me just enough of a background to get by when learning or comparing various programming languages.

While I favor dynamically-typed languages (like Lisp, Ruby and Python) as a matter of personal preference, I have tremendous respect for statically-typed languages (like C and Java). In my humble opinion, some of the most interesting languages are those which allow one to switch between the paradigms as need or desire dictates. Take for example, Haskell’s type annotations or Common Lisp’s type specifiers (particularly declare). The former allows one to annotate Haskell function definitions with type information to enforce type constraints while the latter can be used to turn off Lisp’s dynamic typing system when trying to do something special like optimize certain functions.

After I discovered all of this and determined that I think it’s pretty neat but not something I have the time to pursue right now, my interest has been rekindled by a recently delivered presentation entitled Types Considered Harmful. Perhaps it’s also time for me to re-read another famous type-system paper, Java is not type-safe.

Next Page »