Harlan's Development Journal

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

Tue, 02 Mar 2010 00:00:00 PST

Minimax / Negamax with alpha-beta pruning applet

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

Thu, 25 Feb 2010 00:00:00 PST

C++ Header File Include Patterns
Infinitely useful pattern for including c++ headers and using forward declarations.

Links for 2009-10-06 [del.icio.us]

Wed, 07 Oct 2009 00:00:00 PDT

The Pimping Lemma | Lyrics
Pumping Lemma Contents
Nice interactive pumping lemma utility.

Links for 2009-09-04 [del.icio.us]

Sat, 05 Sep 2009 00:00:00 PDT

Video of Deadlock Detection Using the NetBeans Debugger
What's New in JSF 2?
beautiful summary of many new features condensed to one place.

Links for 2009-09-02 [del.icio.us]

Thu, 03 Sep 2009 00:00:00 PDT

Comparison of Java Mocking Frameworks
Mockito seems to take the cake, except for static/final and equals/hasCode methods.

Links for 2009-08-22 [del.icio.us]

Sun, 23 Aug 2009 00:00:00 PDT

Test-Driving a SimpleFormController with Spring MVC
Good example of mocking a Spring MVC service and controller. Uses EasyMock but it's a simple example so it applies to any mocking framework.
Testing JPA Hibernate with Spring & DbUnit

Links for 2009-08-16 [del.icio.us]

Mon, 17 Aug 2009 00:00:00 PDT

Create a simple RESTful Webservice with Jersey and Spring

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!

Maven2 + Soashable

noreply@blogger.com (Harlan Iverson) — Wed, 26 Sep 2007 16:01:00 +0000

The other night I did some tinkering and got Soashable + xmpp4js building with Maven2 (without JSLibBuilder). Basically what I did was create some ‘war’ artifacts for scriptaculous + prototype, extjs, and xmpp4js (none are checked in yet). I also created one for soashable-web that depends on xmpp4js.

Basically the dependency tree looks like this:

soashable-web

xmpp4js

extjs
scriptaculous

extjs
scriptaculous

I have a preliminary way to run the JSUnits on xmpp4js (though I'd really like to just create a plugin, probably based on Selenium), and hopefully the Selenium plugin works as advertised.

This means I’ll need to open up a repository for the soashable-web, xmpp4js and js dependency artifacts, and at that point one will be able to build soashable-web with a single mvn jetty:run command on the checkout. In the longer haul, hopefully I can sync up with the central repository and extjs/scriptaculous will create and maintain their own artifacts.

It's a little ghetto at this point. The projects are war projects and the overlay happens 1:1 over the war (may be possible to override, but I don't want to look into it now), so a standardized tree under src/main/webapp will need to be used; js/xmpp4js/..., js/extjs/..., etc. However there is a little hope for JS development on the horizon; just yesterday a maven jstools library was checked in to CVS.

If I can get JSUnit working, this stuff should be in by late tonight or tomorrow evening. Matt and I will be working tonight.

On a side note, it would be cool to start something like 'jsrepo.com' as a public maven2 js library repo. At the very least, I’ll contact the authors of extjs et all.

Fwd: The Deep Synergy Between Testability and Good Design

noreply@blogger.com (Harlan Iverson) — Thu, 20 Sep 2007 14:40:00 +0000

Just a bit of blog-o-spam. I completely agree with the hypothesis presented in this blog post, so I thought I'd pass it on. I've definitely observed this first hand as I've aimed for full unit test coverage of things over the past 6 months:

The Deep Synergy Between Testability and Good Design

College Degree

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

Warning: personal entry.

I started going to college again summer term of this year. Not having a degree has never really been an issue, but new circumstances made it senseless to not work on it, if only part time. I got a new job that will almost never require more than 40 hours per week, and is located a few blocks from a school that offers night classes. So I figured I might as well work on prerequisites for a CS degree 1-2 classes at a time, and have been doing so. The 6 year plan.

But in the past several months I have been contacted by a few interested parties about my status on the job market. Some of them didn't work out for non-degree related reasons, but the opportunity of my dreams landed on my lap and I was not able to take it due to working on my degree. Believe me, that poured a LOT of fuel on my fire to finish my degree ASAP.

So after a few weeks of careful consideration, I took this previous Friday to find the answers I need to become a full time student. Whatever the cost. It will be expensive to make the transition (as in, my lifestyle will change a lot), but it is more expensive to both my career and directly in terms of salary to not finish my degree. In economic terms: if I could be making 10k extra by having my degree, then 3 years has 30k opportunity cost. So if I can finish my degree in 3 years instead of 6, then college actually costs 30k less than if I had gone part time for 6 years. And the assumption of 10k more is ridiculously understated.

But perhaps more important than the bare dollar amount is the chance to work on cool projects and make money doing so. At present, I work on a fairly boring project at my job, and then spend 40 hours a week working on open source for no pay at home. It would be great to work 80 hours on interesting stuff, and I want that as soon as possible.

My not going to college was never really a choice. I went for about 1.5 years, until I ran out of money. Then I tried to complete a FAFSA, but due to some special circumstances I wasn't able to. I thought maybe I'd wait until I'm 24 and can be considered "independent," and went back to working full time. But I'm 22 now, and too impatient to wait any longer, so I started taking classes even though I can't really afford it.

Why get a degree if it hasn't hurt me so far? 1) It will hurt me at some point, 2) I need to learn. Emphasis on the latter. There are certain applications that I want to be capable of creating, which I am not, due to my lack in knowledge of statistics, set theory, and algorithms/data structures in general. I could just self-teach myself, but I am already self-teaching myself so many other things. And I might as well work towards a tangible goal, of having a degree, while I learn.

I'm excited but a little scared. According to the admission guy I spoke with (who, incidentally, will also be reviewing my application), I'll have no problem getting into the UofMN based on GPA in college, SAT scores, and GED scores (yea, I'm a high school dropout), as long as it's all in by Oct 12. My records clearly show that I've redeemed myself from my early-day sins in high school. Wewt.

Meebo Does File Transfers & Amazon WS

noreply@blogger.com (Harlan Iverson) — Tue, 11 Sep 2007 13:56:00 +0000

Always on the cutting edge, Meebo does file transfers using Amazon WS. Perhaps validation that the Soashable project is not crazy; we have been discussing that very thing since I became curious about EC2 after TCLUG announced a speaker from Amazon would be coming.

It will be interesting to study their implementation, and whether they contributed any patches to GAIM. As usual, it's very possible with Jabber but may require some patches to the gateway components.

With Jabber, it would be implemented by creating an AJAX server to receive file transfers and connect on behalf of the user (Jabber supports multiple resources) and initiate the transfer of the uploaded file to the target JID. This works regardless of which network the remote party may be on, since the gateway component handles translation between Jabber file transfer and the file transfer mechanism of the remote network.

And of course with all of this running in the EC2 cloud, S3 would be there to store the files.

Taking Testing Fore Granted

noreply@blogger.com (Harlan Iverson) — Fri, 07 Sep 2007 04:25:00 +0000

It feels like I've spent all my time over the past few weeks in front of JUnit and JSUnit test runners. It's true, but it's a hell of a lot better than in front of a browser doing some 'old school' iterative development.

It doesn't seem like long ago that I would manually test functionality until I believed it was solid, forget about it, and have to re-test everything manually a few months later when I wanted to change something. Did I really even re-test everything? Not usually. A change would be requested and I would do it and check it in (at least I used an RCS, eh eh?), hoping that the change I made would have no impact. This was my life for several years.

Normally I would have learned from my mistake and set up something to help me out. At work, we did finally started using Maven, which runs tests automatically on every build... but proper testing wasn't exactly in the budget, so it was kinda moot. -Dmaven.test.skip=true was pretty much hardwired into my brain. At home, I was too impatient and my interest was too fleeting. TDD was just something I'd read about in books, and nobody I knew did it. But oh how I wanted to do it.

It seems it would be hard for anyone working on any project to get into the habit of testing, without tasting the fruit of it first. It is tedious and it makes progress seem to wither away. I started Soashable almost two months ago, and am no farther along now than I was then--as far as new features. Part of it is that I rewrote the XMPP library from scratch, and created a builder for it. Another part of it is that I had finals last month. Excuses aside, I wanted to test this one.

Now I'm completely confident in the new code. Over the past several days I have swapped out the Roster GUI rendering code and made changes to the various components without worry. I simply add new test cases for new functionality, and update cases in code similar to tests that fail. No more having to memorize the whole program and rely on that for refactoring. And being that I'm working on Javascript, a dynamic language where Eclipse can't help me out, that says a lot.

And a nice side effect of being confident about my code and having great results, is I seem to not get frustrated and stop making time for the project. With high confidence, I know that the thing isn't going to crumble apart and have wasted all my energy. This leads to more net results, despite the lower (initial) throughput.

I'm sure you, dear reader, are familiar with testing. But I just thought I'd remind you of the hell you lived though before it was in your life. I am at the point now where I completely take it fore granted--I test at work (I spend more time writing tests than code) and I test at home. So while it seems like I spend my life in front of test runners, I see better results when they finally do come out; I can browse to a page full of complex code for the first time and KNOW it will work, and it does. Because I've already seen all the parts work independently. And I am confident in my code, and can not worry if I forget pieces of the system exist.

I love taking fore granted that my code works.