Harlan's Development Journal

Hello World 2.0

noreply@blogger.com (Harlan Iverson) — Wed, 15 Jun 2011 18:07:00 +0000

Hello again. I'm back in the real world with a shiny new Computer Science degree, after three grueling years of hard work. I've relocated to the SF Bay Area from Minneapolis in search of greener pastures. I accepted a position with a startup, Emota.net, and am now working with Node.js and Redis. I'm still getting on my feet out here, but I'll be resuming business as usual as I explore the Node ecosystem. Cheers!

Links for 2011-01-14 [del.icio.us]

Sat, 15 Jan 2011 00:00:00 PST

Setting Multiple Inheritance Straight
Compares MI vs Mixin vs Trait and their implementation in a number of languages including Python, Ruby, Smalltalk, Scala, and more. Lots of citations, very interesting read.

Links for 2010-12-14 [del.icio.us]

Wed, 15 Dec 2010 00:00:00 PST

Genetic Algorithm For Hello World

Creating a Javascript Library with Maven

noreply@blogger.com (Harlan Iverson) — Mon, 30 Aug 2010 05:09:00 +0000

A Javascript library consists of some Javascript files, and potentially some resources like images, templates, and stylesheets. In Maven, these are arranged in the following directory structure:


my-library/
.  pom.xml
.  src/
.    main/
.      javascript/
.      resources/
.    test/
.      javascript/
.      resources/

The one item that might require some explanation is pom.xml. It is a “project object model” file, which has information about your project and its configuration. It'll be explained piece-by-piece below.

Initial Steps

The first thing you need to do is install Maven. Go to http://maven.apache.org and grab a copy of 2.2.x. Extract it somewhere and add the bin directory to your path.


$ export PATH=$PATH:path/to/maven/bin && mvn --version

If that worked out right, you should see a Maven version and some Java environment information displayed.

Next you need to edit your settings.xml file. Run the following command:


$ mkdir ~/.m2 && gedit ~/.m2/settings.xml

and add this content to the file:

http://gist.github.com/557035#file_settings.xml

These settings are adding the Sonatype OSS repository where the Javascript plugin and several popular libraries that I have packaged for Maven use are hosted.

Creating the Project

All that is needed to create a Javascript library is a POM and some source code. A simple POM looks like this, and is called pom.xml:

http://gist.github.com/557035#file_pom.xml

There are a couple notes about this file, as seen in the comments above.

1. In Maven, every project is defined uniquely by these 4 pieces. groupId should be a subdomain under your control. artifactId is the name of this project. version is typically [major].[minor].[point]-[type]; type is either a “release” or a “snapshot”. This pertains to deployment which I'll cover in the next article.

2. A project has many dependencies and a few possible scopes. In this case we're using the “test” scope. The other important one is “runtime”, which I'll describe later. Each dependency has a version; is good practice to use a range. In this case we can use any 1.4.x version of jQuery. This is especially important as many dependencies are added to the project, which may all rely on different point releases of the same library.

3. Each project can have many plugins. The one that makes JS development possible is the javascript-maven-plugin. Not all plugins require the 'extensions' element. This one does because it adds 'javascript' dependency and packaging types which are not built into Maven.

Once you have your POM in place, you need to create some Javascript. Create a file called hello.js in src/main/javascript:

http://gist.github.com/557035#file_hello.js

Adding QUnit Tests

Now that we have a little functionality in place, let's create a test for it. Create suite-hello.html in src/test/javascript:

http://gist.github.com/557035#file_suite_hello.js

First, all tests match the pattern suite-*.html. Second, notice your hello.js file is in the scripts/ directory, while external dependencies (qunit and junit) are in scripts/${artifactId}/filename.js. These are conventions I have put in place that mirror web application packaging, which will be covered later.

One thing to notice is that qunit is never declared as a dependency to the project. This is likely to change in the near future. At the moment it is automatically added by the plugin code. It might be safe to declare it explicitly, but I'll leave that as an exercise to the reader.

Now run the following command:

my-library$ mvn test && cat target/surefire-reports/qunit.txt

If everything went right, you should get a message that says “Build Successful” and have a brief summary of the executed test displayed.

Next Time...

In the next article I'll show you how to release your project to an open source repository, and declare where it exists in an SCM for automatic release tagging.

Javascript Maven Plugin Revamped

noreply@blogger.com (Harlan Iverson) — Sun, 29 Aug 2010 03:13:00 +0000

In the process of researching for the Engineering Better Javascript series, I ended up implementing some of my ideas to make them concrete. I've extended the existing Javascript Maven Tools to include a QUnit plugin and report integration, as well as added some integration tests to ensure that things are working as expected. I also added a javascript-project base parent, which takes some of the redundant code out of the POM for a Javascript project. The code is available on GitHub, here.

A good example project to check out is my ActivityStreams JS project. There are just a few things to notice.

In the pom.xml file the packaging type is 'javascript' and the parent project is 'javascript-project'. The former enables Javascript lifecycle phases and packaging, and which also allows Javascript dependencies which you can also notice in the pom.xml.

There is a profiles.xml file. This defines Sonatype OSS repositories, which is where this plugin and several 'vendor' Javascript libraries are deployed. Releases are eventually synced with Maven Central, but that hasn't happened yet. If you're using Maven 3, you need to copy the profiles to your settings.xml.

The source code to the project lives in src/main/javascript, and the QUnit tests live in src/test/javascript.

When you run 'mvn test' on the command line, all source and test source is copied to a work directory, where all dependencies are also expanded under the lib directory. These can be included by the test suites. After tests are completed, failures are recorded to target/surefire-reports/qunit.txt where they are placed into generated reports exactly as JUnit tests are for Java.

This project does not contain integration tests, but to the best of my knowledge it can easily be done using the Jetty plugin with an integration testing tool of your choice fairly easily. This is a feature I'd like to implement sooner rather than later.

All these tools also work for Webapp projects. I will write a short post about that when I have one working well. To see a sneak peak, check out the hi-og-integration branch of the Soashable OSW project.

This post is lacking on the theory and technical details behind this project, which I've been slower than I'd hoped to deliver. But it's a practical taste of what I've been doing in the past few weeks.

Benefits of a Repository Manager

noreply@blogger.com (Harlan Iverson) — Sat, 14 Aug 2010 00:28:00 +0000

On the same day I started this series, Tim O'Brien at Sonatype started a series describing the benefits of using a repository manager and saved me a little work ;). He essentially replaced the piece that I've been working on this past week, but he likely did it better (and I still learned tons while researching and writing). Here are links to his articles:

Further pieces to this series are still in the works, though I'll need to do some refactoring and may change the format of some of them to comment on his series with details specific to Javascript, since I'd be repeating much of what he says anyway.

Links for 2010-08-05 [del.icio.us]

Fri, 06 Aug 2010 00:00:00 PDT

How to explain Euler's identity using triangles and spirals

Engineering Better Javascript

noreply@blogger.com (Harlan Iverson) — Thu, 05 Aug 2010 01:37:00 +0000

This is the first in a series of articles exploring a divergent idea for engineering better Javascript using ideas from the Maven build system.

Just a few years ago Javascript became used extensibly enough to warrant automated builds. It went from a language which was embedded sparingly in HTML pages to validate forms, make interactive menus, and disable right clicking, to the central language of the biggest social applications today. Not only is it used in the browser, but increasingly it is used on the server as well.

In these short few years, the need for a build system has arisen. The most popular systems today are Rake, Make and Ant; and recently Jake was introduced. These systems are declarative and task based, and can generally perform any build that is thrown at them with varying levels of complexity. In the simplest case, they concatenate scripts and replace tokens, download a compressor/test framework and other dependencies, run a compression/optimization routine, execute tests, and create a distribution package.

So what's the problem? If every Javascript library requires the same build steps, why should they all have their own slightly-different declarative build script? What happened to DRY? Why can't there be a build system which performs all these steps and allows for customization and extension when necessary, but is zero-config in the general case? It turns out that in Java land there are such systems, including Maven and Gradle. And in Maven's case, there is a plugin which extends it to Javascript.

A few years ago I created a Javascript application that had several library dependencies, and a supporting library for it that also had several of the same dependencies. Having spent a long stint in Java land, building several projects using Ant and eventually porting them to Maven, I had come to love what Maven offered even if it was slightly painful in the beginning. So naturally I wanted to go back to life without the pain of manual transitive dependency management and repetitive build scripts. This is when I found and began using (and contributing to) the Maven Javascript plugin.

Everyone knows the bad things about Maven, myself included. XML based project models are a nightmare. Plugin creation is way harder than it should be, thanks to Plexus. Project creation requires verbose command line arguments. The entire Internet must be downloaded the first time you build a project. There are plenty of less obvious ones, but I'll spare you, dear non-believers. But believe you me, I know Maven can be painful.

Despite this pain, there are some redeeming ideas which I think can be salvaged and used toward the betterment of Javascript development. The key ideas, I believe, are: the build lifecycle with plugins and project archetypes, and transitive dependency management with version ranges and a distributed repository architecture.

Over the coming weeks I will post a series of articles covering these ideas in more depth, and exploring what I see as a good solution to some of the woes of Javascript development. Stay tuned.

Links for 2010-08-03 [del.icio.us]

Wed, 04 Aug 2010 00:00:00 PDT

Versions Maven Plugin - Introduction

Links for 2010-08-02 [del.icio.us]

Tue, 03 Aug 2010 00:00:00 PDT

Asynchronous CommonJS Modules for the Browser (and Introducing Transporter) | SitePen Blog

Links for 2010-07-28 [del.icio.us]

Thu, 29 Jul 2010 00:00:00 PDT

Night Owls vs. Early Birds: Who Will Win? Morning or Night People? - Home - Looking For My Life

Links for 2010-07-15 [del.icio.us]

Fri, 16 Jul 2010 00:00:00 PDT

What Caffeine Actually Does to Your Brain

More Thoughts on Maven Loader

noreply@blogger.com (Harlan Iverson) — Tue, 01 Jul 2008 18:27:00 +0000

Continuing the train of thought I started laying out last night, I have some more details about the MavenLoader client module.

The Maven JS Plugin could generate a Javascript file or replace a token in HTML files in war projects that sets up the MavenLoader in the way talked about yesterday automatically based on the war project's POM dependencies upon Javascript artifacts. I suppose this could also be a stand-alone plugin that operates on wars.

There could also be a POM configuration option whether to prefer local copies of dependencies or ones from a specified repository (repopath). The code that expands the artifacts and rolls them up into YUI Loader format could be shared between the daemon and the Maven plugin.

This would close the circle a little more for Maven developers but still not require Maven in order to take advantage of the system. It would also be a step toward building the YUI Test integration with the JS plugin that I want :)

Javascript Dependency System using Maven + YUI Loader

noreply@blogger.com (Harlan Iverson) — Mon, 30 Jun 2008 23:36:00 +0000

I started thinking a while back about how to create a repository of Javascript libraries / applications using Maven for decentralized transitive dependency management. The progression of things that has led to these thoughts are Maven, Maven JS Tools (feature request), Google AJAX Libraries API, and YUI Loader.

My initial thoughts include using the Maven JS Tools plugin to build Javascript libraries in the same fashion as library jars for Java. These can be pushed to an external Maven repository and synced with the central repository.

A daemon could then pull Javascript artifacts from the central repository and process them. This would include extraction, building dependency meta-data for YUI Loader so that it could discover dependencies and download them as needed, and making both items available on a public HTTP server using YUI Loader's layout conventions.

On the client side, there would exist a MavenLoader model as a module loaded YUI Loader as normal. It would use addModule() like:

loader.addModule({
name: "mavenloader",
type: "js",
fullpath: "http://jsrepo.maven.apache.org/mavenloader/mavenloader.js"
});

// pull in the mavenLoader module now
loader.insert();

From this point, you could create a new MavenLoader as a decorator for YUILoader:

//Add the module to YUILoader
var mavenLoader = new MavenLoader({
loader: loader,
// maybe this can be inferred based on the loaded mavenloader?
repopath: "http://jsrepo.maven.apache.org/"
});

mavenLoader.require( "com.soashable:xmpp4js:1.0-SNAPSHOT" );
// or
mavenLoader.require({
groupId: "com.soashable",
artifactId: "xmpp4js",
version: "1.0-SNAPSHOT"
});

The meta-data that the repo adds to the Javascript artifacts would call register() and addModule() just like regular yui modules work, except it would be on MavenLoader and actually wrap the YUI Loader functionality under the hood:

mavenLoader.addModule({
groupId: "com.soashable",
artifactId: "xmpp4js",
version: "1.0-SNAPSHOT",
requires: [{groupId: "com.prototype", artifactId: "prototype", version: "1.5.1"}]
});

// ...

MavenLoader.register({
groupId: "com.soashable",
artifactId: "xmpp4js",
version: "1.0-SNAPSHOT"
}, YAHOO.xmpp4js.Module);

At this point, a call to the normal YUI Loader's insert() method should pull in all Maven dependencies transitively, with tranitive modules being added, registered and included recursively.

This is of course rough speculation, but my initial experimentation leads me to belieive that this system should be possible.

Observations of Doxia Menu Inheritance

noreply@blogger.com (Harlan Iverson) — Sun, 18 May 2008 17:33:00 +0000

I couldn't find much/any documentation on inheriting menus from a Super POM using Doxia + Maven 2. Here is a quick overview of what I think I have learned using a small reference example to illustrate.

Project Layout

superproject
|
+- src/site/site.xml
|
\- module1
 |
 \- src/site/site.xml

Super Module site.xml Content

<?xml version="1.0" encoding="UTF-8"?>
<project name="${project.name}">
<body>
1   <menu ref="parent" inherit="top"/>
  
  <menu name="Super Menu">
      <item name="Parent A" href="parenta.html"/>
      <item name="Parent B" href="parentb.html"/>
  </menu>

2   <menu ref="modules" inherit="bottom"/>
3   <menu ref="reports" inherit="bottom"/>
  </body>
</project>

Sub Module site.xml Content

<?xml version="1.0" encoding="UTF-8"?>
<project name="${project.name}">
 <body>
4   <menu name="Menu A" inherit="bottom">
       <item name="Link 1" href="link1.html"/>
       <item name="Link 2" href="link2.html"/>
   </menu>
5  <menu ref="reports" inherit="bottom"/>

   </body>
</project>

So what does all this mean?

interitance="top|bottom" - put a menu node before or after sub module's menu items
1 - will only be visible and have content in sub modules
2 - will only be visible and have content in super modules
3 - put reports at the bottom of all modules
4 - inherit="bottom" is not completely clear to me, but either top or bottom is required for the menu to show up
5 - I wanted project reports to always be at the bottom of the menu and could not figure it out without explicitly putting it there; this seems to override the report menu specified in the super site.xml.

Please correct me if I'm wrong about any of these observations/assumptions, and point me to documentation if you know of any. Otherwise, I hope this helps somebody.

Internet Identity Workshop (IIW) - Thoughts

noreply@blogger.com (Harlan Iverson) — Fri, 16 May 2008 19:26:00 +0000

I had the privilege of attending the Internet Identity Workshop (IIW) in Mountain View this week. It was a very cool experience, and my first time out to the valley. On a whole people are pretty sharp, but I think what differentiates them from the local talent in the Twin Cities is their connections. The majority of people there weren't much beyond my punching weight, but a key difference is that a good number were. I want to be the least talented person in a given setting; not by striving to be the worst, but simply by being surrounded by people who are great.

My favorite session was of course my own, "Identity Beyond The Web"; it would have been nothing though, without Jeff Hodges there. We went over the basics of SASL and SAML, talked about various SAML profiles and how they would plug into the design pattern of SASL. We also talked about n-tier authN/authZ and bashed OpenID a bit. Not that OpenID sucks, it just doesn't solve any non-web related identity problems.

Another interesting talk that indirectly tied in to SAML was given by Bryant Cutler and Devlin Daley; I don't have the session title, but the part I caught related to patterns of assertions about n-tiers of parties. I'm looking forward to reading their work.

My biggest hope for future IIW is more discussion of identity beyond the web and OpenID. I think it's a reasonable solution for a very limited space (probably its intended purpose), but it does not solve the more fundamental problem of ubiquitous identity.

I have gained a reasonable understanding of the identity space, but it is much, much deeper than the lay person can possibly imagine. I still have a long, long way to go. Otherwise this blog post would be much more insightful :)

There is no sense reiterating a review of the entire event, as there are plenty out there; just search for IIW2008a or IIW6.

XMPP on the Web: Soashable (upcoming MinneBar Session)

noreply@blogger.com (Harlan Iverson) — Fri, 25 Apr 2008 22:58:00 +0000

I'll be hosting a session at MinneBar this year: "XMPP on the Web: Soashable" on Saturday May 10th, at Coffman Union; it's FREE. I've never done anything like this, so hopefully they get out the free beer early ;).

XMPP on the Web: Soashable

Soashable is a web based, Open Source, multi-protocol instant messenger based on XMPP(Jabber) using BOSH (XEP-0124 and 0206); it is similar to Meebo. XMPP is anything from an IM protocol to a poor-man's middleware solution. Subject matter will range from technical details of XMPP and Soashable, to high level discussion of Jabber and standardization, to direction of the Soashable project.

Even if you don't come to my session, be sure to check out MinneBar if you're in the area. Last year it had an awesome turn out (I think I heard it was the biggest BarCamp ever), and the MinneDemos throughout the year have become more and more popular (though sometimes the presentations have reflected that... people market/seek VC rather than sharing interesting ideas). The unconference style gets some great conversation outside of the sessions going; I've never had a problem joining any conversation that's sounded interesting.

Twitter

noreply@blogger.com (Harlan Iverson) — Fri, 25 Apr 2008 14:14:00 +0000

Along with Clayton, I hesitantly signed up for Twitter. Social broadcasting is something that I don't yet understand; well, I should say I don't see as useful; but I'll give it an honest try.

I remember the days when people made fun of LiveJournal because people posted about mundane things like eating a delicious peanut butter and jelly sandwich. I think I'm stuck at web 1.5.

Hit me up: http://twitter.com/harlanji.

What I've Been Up To

noreply@blogger.com (Harlan Iverson) — Wed, 16 Apr 2008 03:57:00 +0000

Hello Blogosphere. It's been a busy couple of months; lots has happened. Aside from my extremely busy personal life, I've had a pretty fruitful career as well:

Soashable
The little project that could. I actually haven't had a chance to touch it since Feb (the night of my previous blog post). It's seen a healthy surge of traffic throughout March. I can say that I've reached my first attainable goal of 10,000 unique visits :). How soon till 100k? Let's try for this Summer.

There will surely be some time to work on this around the end of April or early May. The focus will be on improving documentation, polishing up the GUI, and making it scale. I have some fun ideas, but have no idea which ones I'll end up executing. I will not have a day job for a month or two this summer, so we'll see what kinds of progress I can make on it.

Another quick nugget: the technique I am using for the Soashable/Xmpp4Js webapp "launcher" is being added to the Jetty Maven plugin; I was excited to see that somebody picked up on it before I got around to creating a feature request :).

Day-Job
Perhaps the most interesting thing happening right now is my day job (yea, I know. wtf?). We've recently dropped a $20m vendor contract, and I am heading research on shifting from a procedural to a declarative rules engine. The prospective engine is JBoss Drools 4.0.

Drools is an extremely exciting piece of technology. I had been interested in it for some time, but had never been able to wrap my head around how it was different from a scripting language. I was recently introduced to logic and predicate calculus at University, and that primed me to accept the basis for declarative rules. Having the opportunity to experiment with Drools full time for a couple weeks and play with concrete examples got me the rest of the way there.

The JBoss Drools + BRMS + IDE tools blow all other OSS rules engines out of the water, hands down. The Drools team has their head on the right way when they talk about creating tools to strongly integrate process and business rules; that is really the missing link, and supposedly the value that a rules engine adds to business: transparency into the rules by non-technical folk.

I've amassed a huge collection of knowledge and resources in this area, much of which I've presented to the business team at work. I'm going to try to get permission to post some of my Drools propaganda here on my blog. My references are here: delicious / harlanji / drools.

From small business to large, there is a very very compelling case for business rules.

University
Okay, a bit more of a personal note. You can leave now if you wish :)

I moved on campus and sold my house and car this month. So-far I haven't looked back; all I need now is a moped 8-). I haven't had a chance to go out and get smashed at the local bars yet, but soon enough I'll make it down. It has been nice to feel like I'm integrating with student life, if only a little bit. I'm still only taking one course; this situation is a nice logical step between working full time and being a student full time. Which, by the way, I've informed my employer that I am leaving this June/July for the student life.

I'm excited to start taking Intro to Programming classes next year. For a for a long time the thought of taking that class was insulting, after having programmed for 10 years. But my attitude has chanced after looking into what really goes on in that class. I'm really excited by the prospect of learning algorithms and data structures and augmenting my existing practical knowledge of software engineering with a solid theoretical foundation. I think this shift in attitude has been across the board in my life. I'm less about proving how smart I am and more about taking things in as they come, and actually being a student of life.

I'm looking forward to learning advanced mathematics at least as much as programming. I'm convinced that the next big thing relies heavily on statistics; things like content suggestion, data mining, and otherwise filtering and relating the plethora of information from all different sources that we are bombarded with every day. Applications are already starting to emerge as nice features of popular sites, but I don't think we've scratched the surface in making all this data that we have useful. The connections between things in many cases is superficial and only related by a natural dimension. I have a research group in mine who I want to do undergrad research with.

Outside the realm of business and technology, I will take piano and German classes next year. I want to study abroad in Germany at some point (say, 2010), so I'll see if I can hook that up. And as far as piano goes, I want a nice leisure activity and I also want to see how it expands my mind.

It's an extremely exciting time in my life right now. I feel like I've broken free from my shackles of debt and ignorance and am completely free to expand my mind at the University and in life in general.

Cheers!

Soashable 0.1 Beta RELEASED

noreply@blogger.com (Harlan Iverson) — Fri, 29 Feb 2008 04:42:00 +0000

Soashable is an Open Source (on SourceForge) web-based, multi-protocol instant messaging client written in pure Javascript. It connects to an XMPP/Jabber server using BOSH (XEP-0124), which is a COMET protocol that provides instantaneous transport of messages between the web browser and XMPP network. It is supported in all major browsers, and currently has core IM features including messaging and roster management.

Soashable is Open Source because I believe that any one or any company should be able to creating a competing product, in a cooperative way, as this raises the user experience bar for everyone. I hope it serves as the base for research of web-based UIs, public-facing commercial applications, internal communication applications, and tools in every niche imaginable. XMPP truly is the future of online communication, and finally, I am proud to be able to provide you with yet-another-tool that utilizes it. It's been a LOT of work, but it's finally here!

Soashable is the test bed for my recently released Xmpp4Js library, available on SourceForge.

I hope my work is used in ways that I could have never thought of!

This release is far from perfect and needs a lot of polish, so all feedback is welcome and appreciated. Please use the bug tracker liberally! It is located here: http://code.google.com/p/soashable/issues/list . But I am confident that she will be ready for MinneBar (I just hope I can get a presentation slot; nudge nudge, anyone with hookups)!

You can either try it out online at https://soashable.com (self-signed cert, safe to ignore warnings), or you can download a stand-alone version that is runnable with nothing more than a 1.5+ JVM. That is available through SourceForge, here:

http://sourceforge.net/project/showfiles.php?group_id=217403&package_id=262062

Simply download and click run.bat. If you're on mac or linux, use the command:

java -jar lib/start.jar

I haven't tested it on unix, so please, somebody let me know if it works before I officially perform a release with an sh file.

For you hard core people out there, here is the Maven site with info about how to check the project out of SVN and start hacking:

http://soashable.sourceforge.net

Again, this release needs plenty of polish, so please let the bug tracker be your best friend.

Happy Hacking!

Creating a Distributable WAR Project With Maven and Jetty

noreply@blogger.com (Harlan Iverson) — Thu, 28 Feb 2008 23:52:00 +0000

I've always had an itch to give the simplicity of trying out a webapp with jetty:run to people who do not have Maven. It came time to release my project, and people were having trouble getting a third-party component set up (or knowing that they needed to). So naturally I scratched the itch.

My solution was to use with the Maven Assembly Plugin to create a distributable zip file that contains Jetty jars, configuration, the webapp in question and a batch file to execute start.jar.

Basically I created a sub project (webappname-launcher, or similar) which depends on the webapp and Jetty. The assembly component descriptor then defined a target to copy Jetty jars, the src/main/launcher directory, and the war file into.

The src/main/launcher directory contains a run.bat, jetty config, and any distribution files such as README.
Optionally I could include the project generated site with the distribution as well, which could be a nice touch.

As far as the POM is concerned, simply declare the assembly plugin and execute it the the package phase.

This can be accomplished without using a subproject, as part of a regular war. But doing it that way causes jetty jars to be included in your war file. I'm sure there's a way to filter out those dependencies, but I took the most straight forward approach.

I will be using this pattern for all my web projects, but my opinion is that this sort of behavior should be built into the Jetty plugin itself, for example jetty:create-distributable, and operate directly on war projects.

On that note,

I created a launcher for the xmpp4js demo site using this method. It's available for download on SourceForge, here and in SVN here. It requires no Maven, no Jabber server, no Apache proxy. Just download and run :).

Xmpp4Js: Initial Release

noreply@blogger.com (Harlan Iverson) — Mon, 25 Feb 2008 15:30:00 +0000

Xmpp4Js is an XMPP client written in pure Javascript. It connects to a server using BOSH (XEP-0124), which is a COMET protocol that provides instantaneous responses.

It allows any web page to be active on an XMPP network. Uses can range from a simple Meebo-like chat client, to a phpLive-like support interface, and beyond.

Xmpp4Js is supported in all major browsers, which removes compatibility limitations inherent in browser extensions like xmpp4moz.

The initial release includes a sample chat client with basic in-browser messaging functionality, and all dependencies.

Xmpp4Js is dual-licensed under LGPL and Apache 2.0. It is available for download here.

Midwest Meets Southwest

noreply@blogger.com (Harlan Iverson) — Sun, 17 Feb 2008 18:36:00 +0000

I made up an awesome dish, today, from left-overs! It's not software development, but it is development, no less.

Slather some mashed potatoes on a tortilla, and throw some chopped chicken breast and nacho cheese on; leave unwrapped, cover with a paper towel and microwave for about a minute. Top it with some sour cream, salt, pepper and salsa. Wrap it up and enjoy!

Remember: always use safe food preparation practices.

TokBox API + Servlet

noreply@blogger.com (Harlan Iverson) — Sat, 19 Jan 2008 22:08:00 +0000

TokBox is a free service that allows anyone to embed video chat in their website. For more advanced implementations, it offers an API that allows any 3rd party site (with an API key) to register and query user accounts by email address and password. It is used as the voice and audio chat application on Meebo.

I started adding video chat to Soashable the other day (surprise, surprise), and have made the fruits of my labor available as a stand-alone TokBox API wrapper and Servlet Maven artifact.

To use, simply map the Servlet and make a GET request for /tokbox?op=getInfo&jid=whateverjid. It will query TokBox for userId and widgetId of the given email address, and if it's not found it will register and return it. This allows you to not worry about it in your application, and just assume that that URL will always return the current user's TokBox info.

Okay, so jid= is specific to jabber, but it works with any email address. If you don't like it, submit a patch :).

Maven project site: http://labs.devspan.com/tokbox-servlet/

How Logic and Truth Tables Can Apply To Unit Testing

noreply@blogger.com (Harlan Iverson) — Thu, 13 Dec 2007 00:53:00 +0000

In the past month I have done nothing but code reviews and mentoring. It's forced me to work muscles I didn't know I had, but out of it has come one shining gem: a systematic method for determining test cases. Basically it's the same as the set up part of a Logic problem: figure out exactly what the code is doing (in my case, we have a written spec for each class), break it down into variables, write a truth table for all combinations (2^n rows, where n is the number of variables), and go at it. The variables can require an understanding of the code, to an extent.

For example: “Return whether there is a dependent care child or step child in A1 household” turns into: P=”There is a dependent care person who is a relative”, Q=”The relative is a child or step child”, R=”The dependent care person is in A1 household”. This may seem like white box testing, but really the code necessarily reflects the structure of business objects and these variables must reflect that as well—the objects will not change in this lifetime, so we'll call it gray box testing.

At first glance, I came up with a method to intelligently ignore certain cases rather than write all possible combinations (in this case 8, reduced to 5): test the TTT condition, and then each variation with one false (FTT, TFT, TTF), and for good measure the FFF case. This method would become more useful as the number of variables grew (t=n+2, where t is the number of tests and n is the number of variables), with 6 for 16, 7 for 32, etc. The theory was to test each variable in isolation (under the assumption that a single F would make the whole statement F):

P	Q	R
T	T	T
T	T	F
T	F	T
T	F	F
F	T	T
F	T	F
F	F	T
F	F	F

Unfortunately that logic does not follow unless you can independently test P, Q, and R without side effects. And if that is the case, then it's futile to even test the compound combinations since you could easily prove that all outcomes would be correct!

I had to work the problem using Bayes' theorem before I really believed that the shortcut method was ineffective, because (for me, anyway) common sense would dictate that if one F were present, the whole statement would be F, and therefore testing a statement with two F`s would be moot. The problem with that line of thinking is that it is assumed that the code checking Q has no side effects on P or R. I wish the shortcut method worked!

In the end, the first part of the solution works and it's easy to develop the table of all test cases. There just isn't the shortcut that I hoped there would be. It makes me wonder if a functional language might allow a provably correct program; but more than anything, it makes me wish that I could work with a true inference engine.

Bayeux, Jabber and XEP-0124

noreply@blogger.com (Harlan Iverson) — Thu, 15 Nov 2007 17:27:00 +0000

The other night I was introduced to something called Bayeux by a fellow at a local meet up. It seems like an ideal way to fight the known limitation on scalability that Soashable (and XEP-0124 in general) will inevitably suffer from when the service goes live.

At first glance it appeared that Bayeux didn't quite fit the bill for this type of one-on-one client<->server session, due to its channel subscription and indiscriminate repeating behavior. But alas, it is indeed possible without hackery because of the reserved /service/* channel name space that is specifies.

The problem with the XEP solution is that it specifies a client must use an XmlHttpRequest (or equivalent) connection in such a way that limits it by the beloved same origin policy. As a result, in order to be functional (with a non Java web server), a proxy must sit in front of the main web site and funnel jabber http binding requests to the binding server. This could be hardware, software or Apache/lighty mod_proxy. For example: soashable.com is running Apache on port 80, serving up content and Javascript; and the HTTP binding servlet (for XEP-0124) through Jetty on port, say, 9999. Because of the same origin policy, XmlHttpRequests can only talk to soashable.com on port 80. In order to bridge the gap, one needs to use the proxy on port 80 and pipe certain requests to Jetty on port 9999 (two servers can't occupy the same port). In this case we could reduce overhead by using mod_jk, but we are ultimately still tied to having a heavy-weight process for each and every COMET connection, and that will not scale well.

In addition to the limited scalability of the XEP, I can't begin to count the hours I've spent tweaking xmpp4js's polling code due to policy-violation disconnects. The XEP basically defines its own version of what Bayeux specifies, and each client implementation must reinvent the magic. In fact, section 1.4.5 i of the Bayeux 1.0 draft spec is functionally identical to the protocol that the XEP lays out. This means that 1) replacing the polling code with a Bayeux polling client is trivial, and 2) it doesn't make sense to not use a spec and libraries that made for the specific task of polling; they can do one thing and do it well, while the Jabber programmer can worry about their Jabber. Bayeux can be thought of as a socket implementation for Javascript.

I've spent a few hours over the past couple days messing with the clients and servers of Bayeux and it is all very immature. But there is a very active community of people pushing it forward. I'm extremely excited to push forward with it when it stabilizes a bit, and possibly even put forth a new XEP to supersede XEP-0124 if nobody else does it first.

The Future of JS Dev Tools Is The Parse Tree

noreply@blogger.com (Harlan Iverson) — Wed, 31 Oct 2007 23:59:00 +0000

Today I read an article from Sun research, entitled Using Javascript as a Real Programming Language. This obviously struck a chord with me, because it talks about exactly the stuff I've been pushing for since I started using it as a real programming language, a few months ago. Recently, I have been collaborating with a fellow from the Maven list who is building a Javascript packaging plug-in for Maven, and trying to integrate all the features from the late JSLibBuilder.

One point I've been touching on lately is that code coverage testing is the key to the sanity of any code base written in a dynamic language (same point applies to rails). While having 100% coverage can be fool's gold, it is a good measure of which code needs to be better exercised by tests.

My research has found me one complete tool for doing such a thing in Javascript: JSCoverage. It runs on the command line and instruments specified code to see which lines were executed. Basically what it does is add a Javascript function call on every other line, and when it is runs its special runner, it produces a report with annotated code coverage data. In unison with JSUnit, this gives the same sort of functionality as Java tools like Cobertura + JUnit (though, AFAIK it is only line coverage, not branch coverage).

I'd have liked to have integrated it with JSLibBuilder or javascript-maven-plugin, but because it is written in C (based on Spider Monkey), distribution would be hell. So I was doing some research to see if I could find an alternative Javascript parser that runs in Java or Javascript to port JSCoverage to, and came across a piece of gold: Narcissus, a Javascript interpreter written in Javascript. It is also, incidentally, based on Spider Monkey :). Easy porting of JSCoverage? I hope so. The reason a tool written in a Java friendly language is important is because it would be able to run during a Maven build, and be distributed through the central Maven repository.

Let me backtrack a little: the best Javascript code monkeying tools available right now are Dojo Shrinksafe and YUI Compressor (from a strictly 'safety' standpoint, others have achieved better compression ratios), for the simple fact that they are based on the Rhino Javascript engine, rather than relying on regular expressions and other potentially flaky methods to parse. Because source files are parsed and modified as they are serialized from a real Javascript parse tree, the engines produce 100% safe results. Naturally I wanted to see what else I could do with the parse tree available at runtime (cyclomatic complexity and other code analysis), but it turns out there is no public API for accessing the parse tree in Rhino(!), and no plans to implement one.

I only have to wonder whether anyone knows about Narcissus and there is a problem with it, or if it is just sitting there waiting to be discovered (it looks like it's been around since at least 2004). If Javascript is ever to be a first class language as people are treating it, it needs first class tools. This single tool is the key to getting so much more out of Javascript.

I'll surely be writing about this more.

Admitted to the U of MN

noreply@blogger.com (Harlan Iverson) — Wed, 10 Oct 2007 18:10:00 +0000

Warning: personal entry.

Just an update on the college post a while back. I applied to the U and just learned that I was accepted for Spring semester, CLA Pre-CS. Not that it's a really hard school to get into, but for somebody with an academic background like mine it's one hell of an achievement. It was the last step in officially clearing my name and turning my academic career around. From here on, I have the same opportunity as a 'normal' student--even a good grad school is on the table, if I keep working hard.

Thanks to everyone for all the support.

Speedier Maven2 Webapp Development

noreply@blogger.com (Harlan Iverson) — Mon, 08 Oct 2007 16:22:00 +0000

Now that Soashable is ported to Maven, I want time savers because the change/compile/package/deploy/test cycle is way too slow. I did a bit of research and here's what I've found.

Some goals that are useful alone or combined:

war:inplace - copies all dependencies into the webapp source, including overlays, classes (made with 'compile'), dependencies. See caveat below.
javascript:inplace - copies javascript dependencies, the same way war:inplace works
jetty:run - runs the inplace webapp; scanIntervalSeconds of 1 makes rapid 'testing' possible

Using jetty:run in its own terminal requires no recompilation or packaging in order to see changes reflected in the running webapp, since it runs out of the source directory. A javascript:inplace or war:inplace in another terminal will copy any updated dependencies into place and work while the application is running.

This method cuts several seconds off of the change/test cycle, from around 10 in any case to 5 or less for dependency changes, and immediate for local changes.

The caveat is that it copies dependencies into src/main/webapp, which might confuse some junior developers or perhaps make svn:ignore invaluable. A slightly slower alternative is to use war:exploded and jetty:run-exploded.

Perhaps the best solution would be a hybrid resource resolver that first checks src/main/webapp and then falls back to the war:exploded target.

maven-javascript-plugin

noreply@blogger.com (Harlan Iverson) — Fri, 05 Oct 2007 20:01:00 +0000

I've been watching and trying out new development on this new Maven plug-in that's coming together after the recent threads [1, 2, Codehaus Proposal]. I've given a couple patches, and am becoming much more familiar with both it and the internals of Maven and the build lifecycle. I've spent more time than I would have liked encountering bugs and discovering that I’m an idiot, but the main developer has been extremely helpful. And all of this bug chasing has taught me a ton, so it hasn't been a waste by any means. As I told one of my colleagues: it’s the cost of early adoption; in the same way that some people lay down extra dough for the newest gadgets, I lay down extra time for the newest software.

I think this plug-in will be a great success and could potentially have a wide scale impact on the JS development community. The mature JS projects like dojo, scriptaculous and jsjac all have their own custom build scripts that do about the same thing as maven-javascript-tools. It will unify effort and allow people who like dealing with build tools to deal with build tools, and people who like dealing with libraries to deal with libraries.

I’ll be doing my part a bit more this weekend by creating some archetypes and maybe a screen cast if I’m feeling ambitious. I have to keep in mind that Soashable is my main project, and that I still have to do my homework. But man, does this project excite me!

It has the potential to raise confidence in JS and propel it to its place as a first class language. It’s been treated as one for quite a while now, but finally it will be able to walk the walk.

Another JS / Maven2 Thread

noreply@blogger.com (Harlan Iverson) — Mon, 01 Oct 2007 06:00:00 +0000

More on JS packaging for Maven:

http://www.nabble.com/recommandation-for-JS-packaging---%28was-Using-maven-for-JavaScript-projects%29-tf4534791s177.html

And a wiki page came to be as a result of the discussion. All of the ideas from JSLibBuilder will be included, including a script artifact repository. :)

http://hammerfest.wiki.sourceforge.net/mavan-javascript-tools

More on JSLibBuilder to Maven2

noreply@blogger.com (Harlan Iverson) — Thu, 27 Sep 2007 16:54:00 +0000

Seems like a good time to be thinking about the topic of Javascript development tools.

Here's an interesting thread on the Maven Users' list that started yesterday:
http://www.mail-archive.com/users@maven.apache.org/msg73451.html

and my contribution to it:
http://www.mail-archive.com/users@maven.apache.org/msg73613.html

It looks like there is a good array of tools coming to light from this
thread. I, myself, have been tackling the problem of making JS library
development more like Java development, as far as automated running of unit
tests, documentation, packaging, etc, in recent months.

I see a growing demand for a nice tool chain of things like jslint,
shrinksafe, jsunit + jscoverage, selenium, jsdoc, and dependency management.
Maybe it's because I just came back to JS after several years with a bunch
of Java development under my belt; but I see all these tools and feel like
they should be integrated. Especially when I make the connection between
web2.0 and people who promote Agile development practice. JS tools are
hardly in the state to accommodate good Agile, IMO. If integration were
better, it would be a different story.

My original approach was to create an Ant script that would download various
things using the <get> task, and use Maven Antlib for JSUnit, Selenium and
ShrinkSafe dependencies. But now I am getting to the point where I want to
break my library into multiple parts (project-core, project-ext,
project-ext-gui, etc) and Maven seems like the natural answer. And of course
when Maven comes into the picture, I want to manage my other JS dependencies
as such.

So last night I gave it a shot, and it seems to work well using war
packaging and their built-in overlay behavior. There are a few kinks to work
out, and probably Mojos to write, but I think it will work.

My immediate need is for JSUnit, which I have hacked into a series of
executions (see pom link below). I'll definitely be looking at some of these
tools and seeing how I can use them (namely the ShrinkSafe mojo!), and
hopefully getting a JSUnit mojo out of them at the very least. I've never
written a plugin (beyond hello world), but I'm eager to give it a shot.

I have high hopes that Maven can bring the state of JS development up to par
with the Agile way that so many web2.0 people want to develop. I'm looking
forward to hearing more of everyone's great ideas!

Harlan

ps.
Here's my main POM with JSUnit (in-progress proof of concept, by no means a
final product). The executions for JSUnit are basically a copy of
Selenium's:
http://soashable.googlecode.com/svn/xmpp4js/branches/maven/pom.xml

And here's my old Ant script "JSLibBuilder":
http://soashable.googlecode.com/svn/jslibbuilder/trunk/

Adios!