An American in Laval

After finishing up a fantastic summer at Mozilla, I hopped on board a plane to France to begin my 3 month odyssey abroad.  I was still exhausted from the all hands meeting at Mozilla.  I woke up at 4am to catch the shuttle to the airport, with a layover in Philly, followed by an hour shuttle from Charles de Gaulle to the train station at Montparnasse, followed by a 2 hour train ride to Laval, finally to arrive at my destination at about noon the following day.  I think I am just finally catching up on sleep now.

I have been in France for almost a week, and I've been overwhelmed by my reception.  The people here have been uniformly friendly, and have gone out of their way to make me feel welcome.  The town of Laval is lovely, and the food has been delicious.

The Saturday market in Laval was overwhelming.  In California, we have farmer's markets, but these are pitifully small compared to Laval.  There was fresh-baked bread, giant tubs of paella, seafood so fresh that it was literally trying to escape, and produce that has to be seen to be believed.  I think the produce section alone would be equivalent to 3 or 4 farmer's markets back home.  I think I will enjoy my time here.

So far, the biggest difference that I have noticed is that there is a sharp divide between work and play.  In the states, we buy huge cups of coffee and take them to go so that we can go back to work.  Half the time, 'work' might consist of Facebook and Farmville, but the pressure to be at our desks is very strong.

In France, cups of coffee are small, and no one gets them to go.  You sit and chat with friends, and when you are finished, you go back to work.  And then you work.  I'm not sure who comes out ahead in terms of production, but I am gaining an appreciation for the French approach.

Counting Tiger Vim Fu, Macro Monkey Vim Fu

In my travels, I have seen many masters of their text editors, but none to match the masters of the ancient and complex art of Vim Fu.  In contrast to the arts from The Land of The Darkened Sun or the Builders, the art of Vim Fu has great subtlety and variety.  If you were to see two different masters of Vim Fu, you might not even realize that they were practicing the same art.  And so, in this article, I attempt to chronicle several of the more common types of Vim Master that you may encounter.

The Counting Tigers have a straightforward, powerful style. With a near Rain Man like ability to count at a glance, practitioners of this style will frequently use commands like 5dd or 2y{.  To Counting Tigers, the world may be broken up into units and numbers.

The masters who follow the Path Of One Thousand Stars (though they use an equal number of question marks, pluses, dots, and other meta characters) eschew the straight-forward approach of the Counting Tigers, instead opting for the elegance of patterns.  Their forte will be commands like yt,.  And :%s/old/new/gc is deeply ingrained into their muscle memory.

The Masters of the Hidden Mark rely on mx and 'x extensively, whereas the Counting Tigers would remember the line number and type 166G.  The Visionaries rely extensively on visual mode, highlighting relevant sections and applying their commands to all the region.  Members of this clan frequently rely on column mode editing, an art that other masters often see as being of little value.

The Way of the Macro Monkey leads practitioners to define mini programs of character sequences, constantly creating ephemeral, custom scripts to achieve their goals.  The Pure take this craft to another level, constantly redefining the basic art of Vim Fu to the point that it is not recognizable by other Vim Fu practitioners.  Their .vim/plugin/ directories may have thousands of .vim files.  They can also be readily identified by their fierce, nearly fanatical refusal to use any other tool.

In great contrast to The Pure, there are a number of Wandering Masters.  While Vim is their first weapon of choice, they will use Eclipse, NetBeans, or any other tool that makes their task easier.  They eschew the more esoteric features of Vim Fu, instead seeking to synthesize features of other arts with the core basics of the Vi Path.

Here I feel I must make a special mention of the masters of the Viper Clan.  Though not proper Vim Fu masters, they seek to join the great art with techniques gleaned from the masters from the strange, twisted lands of Emacs.  Some consider their art an abomination.  Others hope that they will bring civility to Emacs.  Yet others prophesy of a chosen one that will at last bring true peace and unity to the House of Vim and the House of Emacs.

Lastly are those of "No Style".  Borrowing from the philosophies of Bruce Lee, these rare few strive to master all aspects of Vim Fu, and yet limiting themselves to no one approach.  These masters can do things with their Vim Fu that seem magical even to other Vim Fu masters.  While it is not meant for all of us to truly master the art of Vim Fu to this degree, by aspiring to perfection, and constantly extending our mastery of our craft, we can become better practitioners of the Noble Art.

Switching to LaTeX

I am giving up on Word.  After many years of use, I've gotten too irritated with its many quirks.  The final straw for me was when it inserted section breaks in the middle of my novel and would not let me delete them.

So instead, I am now using Aquamacs and LaTeX.  When I started the process of converting over my novel, I was not sure if it was really a good idea.  LaTeX is great for technical papers (especially greek-letter heavy ones that we are so fond of in programming languages research), but I was not sure if it would really offer much for a fiction writer.

Almost immediately I found the benefits.  Although there are some hassles, the precise control of formatting is fantastic, and that alone makes the trade very worth while.  Also, being able to use my vi key bindings with emacs viper mode has been a true delight.  And I can actually track my changes through source control.

It has also been interesting what I have not found useful.  I had expected that variables would be a useful feature.  For instance, I could make a command for a character's name, and then allow myself to change it easily if I thought of a better one.  I tried this for one of my characters briefly, but found it to be more of an irritation than anything else.

But there is one feature that I did not give much thought, and yet has me fully committed to a life using LaTeX for all of my non-technical documents.  And that is comments....

It seems so obvious now, but before I had a wide variety of text files and hand written note-cards; all of these have been collapsed into the .tex file itself.  I use simple line comments for things like 'fix up this section' with no worries about cluttering up the document for anyone I ask to review it.  For more complex notes, like outlines and lists of my characters, I make new commands.  When I set the command to do nothing, the notes are invisible.  But when I change it to output the text, I can share those details with anyone who wishes to review it.

LaTeX is not a program for everyone.  But if you are familiar with it, don't be afraid to use it for less technical documents.  Many of the same benefits will still carry over.

Narcissus addon available

Today I uploaded a plugin for Narcissus JavaScript.  Details can be found here.

It requires Firefox 4, so to test this out, you will need to build from source for the time being.  Longer term, the plan is to swap out the JS engine at will.  But, it is at least usable for experimenting currently.  Enjoy!

More Awesomeness: jstests.py

In working with Narcissus, I've uncovered a jewel of a resource in Mozilla's JavaScript unit tests.  The value of unit tests is well understood.  The most critical quality, however, is that they are maintained.  Mozilla has done an exemplary job of this.  The unit tests are constantly growing.  As I write this, there are just shy of 3000 unit tests.  All of them pass with the Tracemonkey engine.

The organization of the tests is well thought out.  Each version of JavaScript has its own test directory.  So if you don't care about certain batches of tests, it is easy to ignore them.

Unfortunately, as with many other things at Mozilla, there is an abundance of out of date documentaion.  The JS Test Library page refers to a Perl script, which appears to be more or less abandoned.  Instead, there is a python script 'jstests.py', written by Dave Mandelin in his copious amounts of free time.  Unfortunately, the old version of unit testing documentation comes up first when searching for it on Google.  Alas.

One thing that is sadly not emphasized is just how easy it is to plug in a different engine to use these tests.  In fact, I have a "shell" for Narcissus JS, written in 30-some lines of Python code.

To hook into the testing framework, you need a "shell" that supports two command line options:
1) -e, which interprets a string of JavaScript code.
2) -f, which handles a JavaScript file.
It must be possible to support multiple files and strings of code, though this is not a particularly difficult challenge.

Some tricks:

• The -m option will let you specify your own module of JS tests.  This is also a convenient way to insert a little JavaScript into the testing process to handle tests relying on non-standard JS features.
• The -x option allows you to ignore a list of tests.  Since Mozilla includes tests for special Firefox-only features, you will want to use this.
• The --failure-file option will write the failing unit tests to the specified file, useful as input for the -x option.

On another note, Narcissus now runs without special extensions in Firefox 4.  Huzzah!  Now to make it interact smoothly with the DOM...

This summer I am working at Mozilla. It is an awesome, awesome place to be. The people here are friendly and amazingly bright. Plus there is a dinosaur in the lobby. How can you beat that?

My work has been looking at Narcissus JavaScript. Narcissus is a JavaScript implementation written in JavaScript, and as such, it is an ideal vehicle for playing around with the language.

Narcissus relies on a few special extensions, which require a special build. It is not hard to build, but it is not all that well documented either. Here is the process that I use (in OSX):

  $hg clone http://hg.mozilla.org/tracemonkey/
  $cd tracemonkey/js/src/
  $autoconf213
  $./configure --enable-narcissus
  $make

With that, you are good to go. From the command line, ./js will give you a tracemonkey shell. Here, you can use evaluate(prog) to test out narcissus.

With some adjustments, Narcissus should run within a standard Firefox build. I am down to a handful of failing unit tests. After that, running Narcissus within a browser should be as simple as loading the Narcissus js code.

NetBeans -- The Least Terrible IDE

My favorite text editor is MacVim. It lays a nice Aqua interface over the top of the classic editor. It is not perfect. I could rant for hours on its shortcomings, but it is still a shorter rant than I have for Aquamacs and TextMate, and these are the only two other text editors that I find even usable.

But text editors and IDEs are not the same thing, despite the fact that they do many of the same tasks. When I start working with a Java or Scala project, I want the advanced functionality that a full-featured IDE offers. (And yes, I am aware of Eclim, but that does not really change the fact that an IDE has been brought into the process.)

I have played around with a number of IDEs over the years; I have yet to settle on one. Eclipse is the classic, with extensions and plugins for about everything. Now that IntelliJ has an open-source version, I have been spending a good deal of time with that. Nonetheless, NetBeans is still, in my opinion, the best.

It is not that it is the prettiest. In fact, it is by far the ugliest of the three on any other system besides OSX, and still not that pretty even then.

It is not that it has the best Scala plugin. While I have had more success with the NetBeans plugin than the Eclipse one, I have found IntelliJ's to be more full-featured (albeit a little more of a hassle to install, since the version offered through their plugin manager does not seem to work. But that is another rant...).

And while I love some of the plugins available (the jVi plugin in particular being the best vi emulator that I have seen for any IDE or editor), they still pale compared to the wealth offered by Eclipse.

No, these are pluses, but relatively minor points. The reason that I keep returning to NetBeans, in a word, is Ant.

There is a fantastic article by Jeff Atwood titled "F5 is not a build process". This comes close to the core of the issue: every project should have a build process that functions outside of the IDE. This is a problem I have seen even with some open-source projects. Instructions like "start up NetBeans" or "download the Eclipse plugin" should never appear for any tool that is not specific to an IDE.

Unlike Eclipse and IntelliJ, NetBeans does not have its own special build tools. It defers this to Ant (or yes, you can use Maven instead). As a result, the build process is available outside of NetBeans. In my experience, projects designed with the other IDEs only create a build process as an afterthought.

This is huge. It means that the IDE actually takes care of the build process for you, as is just and proper. It also, however, allows you some extra options when things go wonky.

I do some weird things with my IDE. Using Scala is one of the more tame uses, but even that can start causing problems when you combine it with Antlr or JavaCC. And God help you if you want to add unit tests into this mix. I have managed to confuse and break every IDE I have used, to one degree or another. (To be fair, IntelliJ has generally handled more weird stuff than the others).

The beautiful thing about NetBeans is that when it stumbles, it can still function. For one project, NetBeans gave me hundreds of spurious errors, but the build process still worked.

NetBean's generated ant files include a number of hooks where you can add in your own ant tasks, a feature that I have found invaluable. Furthermore, if something in NetBean's ant files is horribly broken, you can replace it with your own; not something that I would recommend, but it can save you in extreme cases.

And so, despite NetBeans numerous quirks and limitations, I still list it as my favorite IDE. And while I believe the NetBeans team will address the product's current limitations sooner or later, I doubt that either the IntelliJ or Eclipse teams will ever fix what I see as a fundamentally broken architectural decision.