I like Makefiles.  This probably comes from my time as a server developer for CompuServe back in the 1990s, when I was actually writing a variety of back-end servers in C and C++.   Coffeescript, HAML, and Less are all compiled languages, but their compilation phases are usually quite quick.  I also like Fabric (Fabric is a deployment script manager written in Python, much like Capistrano for Ruby).   So for me, the lesson has become:

watch:
    while inotifywait src/*.less src/*.haml src/*.coffee ; do make all && fab deploy; done

This Makefile recipe watches my source tree, and whenever a source file changes it builds the executables and pushes them out to the server. Instant gratification just got more instant.

- Knowledge of SOA (REST, JSON, etc.)

Let’s start with the fundamentals. JSON is a protocol of data exchange. You can do data exchange in just about anything: XML, YAML, HTML, JSON, BSON, IDL, even some tragic home-grown mess that only your client and server understand. But that’s all it is: a way of marshaling data at one end of an exchange between two independent programs such that at the other end it will be parsed, understood, and acted on appropriately. These are all designed to be transmitted over some mediated electronic network such as the Internet, but carrier pigeon would work.

SOA and REST are architectural decisions about how to organize your client/server software project. More than that, they are opposite decisions: choosing one means you are choosing not to use the other.  SOA (“Service Oriented Architecture”) concentrates on the service delivered, on how data is handled, whereas REST is concerned about the data being handled.  One is verb-oriented, the other is noun-oriented.

If you think this is an academic distinction, you’re right.  But it’s an important one that people screw up all the time.  Consider this analogy: going to the movies.  In a noun-oriented word, you trade money for a ticket; you trade the ticket for access; you use the access to find a seat; you use the seat to watch a movie.  That what REST does: it trades coarse documents back and forth between the client and the server describing the various records that need to be kept to accomplish a goal, which ultimately results in the client and the server agreeing on what each needs.  In a verb-oriented world, you’re not writing software dealing with money, tickets, access, seats and movies: instead, you end up writing software about the kid selling tickets, the kid taking tickets, the kid who ushers you to your seat, and the projection of the movie.  That’s what SOA does: it describes the services with which you’re provided, not the actual products you intend on handling.

I can fairly be described as a REST partisan, but then my world is full of concrete items: gene sets, stories, to-do items, gardens, potlucks, cards, poems, games.  When I program, I care about what the client and the server exchange.   In every case, the software must validate and ensure the integrity of the exchange,  but in the case of REST the medium of exchange describes what is being exchanged, not how to exchange it, and for me that makes a big difference.  When you say you want “SOA using REST,” you’re telling me you don’t really understand either.

But magnetic poetry doesn’t have allocated portions of your refrigerator.  A magnetic poem is just a collection of tiles assembled in a deliberate and meaningful way.  So I decide to write my own equivalent.

Behold: HTML5 Magnets!

It resizes when you resize (proportionally, too!), it’s not Flash, it still allows you to send your poem as a Tweet (so long as it’ll fit), and it detects a poem by the deliberate placement of words(i.e. you moved them) into meaningful patterns (i.e. they’re touching).

There’s a lot of fun stuff in the code: HTML5 Audio, the separate axis theorem (used to determine collisions in game mechanics, here used to create the “is-a” poem graph), a desperate (and somewhat unsuccessful) attempt to marry some functional and OO designs, a ton of Coffeescript (I love Coffeescript, gods, please don’t ever ask me to write straight JS again), a little application of the “write-only DOM” theory, and a nifty chunk of proportionality that lets the zoom feature work its magic.  I wrote this for fun, and it is fun.

Bug reports, patches, and the like, are very welcome, as always.

As usual, the HTML5 Magnets source code is available at GitHub.  Enjoy!

The focus of the Anti-If folks seems to be Java: there’s a lot of talk in the Java community about whether or not the Anti-If people are nuts, or silly, or on to something, or just on something.  However, I’ve been focusing recently on my code and trying to “anti-if” it as much as possible, and here’s what I’ve discovered:

First, if statements and if expressions are two different beasts.  An if statement creates two possible code paths; an if expression returns one of two possible values based upon an evaluation, and if you’re a good programmer, the values will always be of the same type.  (Yes, I know, I work primarily in Javascript and Python, a pair of weakly typed languages.  This doesn’t mean you can ignore typing.  If anything, you should be paying more attention to it.)  You can argue that there are still two code paths, and I agree with you, but the important consideration here is that both code paths have the same type as the ultimate result, so the testing burden is down to “does this function return what we expect it to return under all circumstances?”  By narrowing the issue down to an if expression, you constrain your test to one value of one value type.

Secondly, the use of if expressions as guard conditions is good practice; it’s basically insuring that your function meets the needs of the caller before returning the anticipated value, which is just Programming by Contract 101, and if you’re a Haskell programmer you’ll recognize a great place to use the Maybe pattern in place of null values or exceptions as signals to the caller that the function failed in some way.

Third, lots of excellent self-documenting programming techniques exist that allow you to avoid massive ‘ifs’ trees in the first place.

Recently, I was using Backbone to create an editor for the gene sequence alignment DSL we use at Spiral.   We therefore had three possible code options: create a new Aligner, edit an existing Aligner, or run an existing Aligner.  Each of these has a concrete URL associated with it, so it was possible to have separate method calls for each url by building a route association.

Instead, I had an uncomfortable mash-up of routes, all going to a single PipelineView full of if statements about “is this a launch” and “is this a new Aligner” and whatever.  I spend two days refactoring, and came out with a rock-solid concrete collection of subclasses, each of which does one thing and does it well.   There are still if expressions in there, and even a few if statements– they’re all in the code that manipulates the DOM, making visual decisions, what Haskell calls the “side effects.”  But for the most part, the risky code is now gone, replaced with a dispatch table that up front tells exactly what the code will do, and what results you will get back.

The replacement of ‘if’ statements with modern language constructs such as filters, maps, dispatch tables, routing tables, and factory functions that deliver polymorphic subclasses makes a more rich, better-documented, smaller and more powerful code base.  Like my study of Haskell, this discipline has contributed to making me a better programmer.  I recommend you try it, if only for practice.

myfunc = (options) ->
    @foo = options.foo
    @bar = options.bar
    ...

And instead say this:

myfunc = ({@foo, @bar}) ->
    ...

In both cases, foo and bar will automagically be bound to the this operator and set to the corresponding values in the options object, if they exist.

A couple of weeks ago I posted Coffeescript is a gateway drug to Haskell, which showed how the quicksort algorithm as apparent in Haskell could almost completely be reproduced in Coffeescript. The Haskell function looked like this:

quicksort [] = []
quicksort (x:xs) =
       let smallerOrEqual = [a | a  x]
       in quicksort smallerOrEqual ++ [x] ++ quicksort larger

My function was a little uglier; I was disassembling the array into car and cdr components in the function, my comprehensions weren’t lazy, and the pattern had to be moved into the function as a guard condition.

Linus Thiel and I had a couple of go-rounds on this, and he taught me something fascinating, and at the end, this is what we had:

quicksort = ([x, xs...]) ->
    return [] unless x?
    smallerOrEqual = -> (a for a in xs when a <= x)
    larger = -> (a for a in xs when a > x)
    (quicksort smallerOrEqual()).concat(x).concat(quicksort larger())

The guard condition is still there, but it’s much more readable. I made the list comprehensions lazy. But Linus showed me how the deconstruction operator for Coffeescript can be used to achieve car:cdr effectively in Coffeescript, and that just blows my mind, because now it means that yet another common transformation is part of my toolkit.

Coffeescript continues to amaze me as it grows and matures into a full-fledged language.  The more I work with it, the more I realize I may not write in raw Javascript ever again if I can avoid it.

Fridgemagnets attempts (and mostly succeeds) at implementing a write-only DOM layer: once objects are on the board, I tried hard not to ask the DOM for positions or direction.  Only under certain circumstances, such as a drag/stop event, do I need to ask the DOM “Where did that land?”  Otherwise, I tell the DOM what I want it to know.  This was mostly done for learning; I’ve read several different responsive design blogs where querying the DOM is the biggest time-eater in an app.

That doesn’t mean this program is at all efficient.  There’s huge CPU wasteage in repeatedly querying and shuffling the lists of words and their bounding boxes in order to determine which ones are in proximity to other ones, which ones constitute “the poem,” and so forth.  I expect to be looking hard at the way these features are used, and fixing them as I can.  Coffeescript isn’t Haskell, and doesn’t have Haskell’s marvelous internal caching mechanisms.

One thing I am very proud of is my solution for the Separating Axes Theorem, which is a space-and-time efficient way of telling if an object is in collision with other objects.  I’d never written anything quite like that before, and it was a pleasure to stretch my brain around a seemingly arbitrary geometry where everything is in the 2D plane, but the axes of projection are abstracted and their distance to the measured objects irrelevant.  (It’s also annoying that game programmers use the word “axis” for what is generally just a “line.”)

I’m happy with the algorithmic description of “a poem,” but not with some of the underlying querying of the list of words and their bounding boxes to determine what is and is not part of the poem.  That’s gonna take some more think.  All in all, though, a very nice start.

First, some people have complained that the download is really hard to find, since I don’t recommend you use the copy off my site.  It’s here: Right Now on Github.  That’s guaranteed to be the latest, greatest, up-to-date reminder.

Secondly, the “Here’s how to use it” feature obscured the buttons on pages less that 1200pixels wide (so much for responsive design; this was a learning experience), so I’ve provided a control allowing you to delete the help panel.  It’s at the bottom of the panel.

And finally, it didn’t work under IE8.  Too many people still use IE for me to ignore it (18.86% of the world uses IE8 as of January 2012), and to make it work I had to replace Zepto with jQuery.  Zepto doesn’t provide some of the CSS read capabilities that I used.  That raises the post-UglifyJS size from 45K to 101K (approximately), which is still small, but doubling in size is just not attractive.

To test with IE8, I had to install a really old copy of Windows95 (which I had the CD for) into VirtualBox on my Gentoo Linux laptop, then upgrade it to XP SP2 (which, again, I had the CD for), then upgrade to IE8.  Oddly enough, this works really well.  For the longest time, I had an ancient box under my desk that I would turn on and VNC into whenever I wanted to do IE testing.  Now, I can do it anywhere, and can even fork and automate the process, and once I’ve got an establishement that I like I can snapshot it, and reset it should it ever become infested.  This is a major win, since IE testing is always a pain.

Right Now is meant for modern(ish) browsers; it obviously doesn’t push the envelope the way HTML5 Tones or the Arc Experiments did, but it is supposed to be useful for 95% of the world (those above IE6 and Firefox 3.6) and IE8 compatibility almost makes that happen.   If I were developing for a customer in the real world, I’d use Express.js and have both client-side and server-side rendering, as was possible, but this isn’t a server-based application, and it does its jobs well.

Right Now is also supposed to be a reminder tool.  It doesn’t need bells and whistles.  Someone suggested, and I understand the wish, that it had a search bar in it, so that instead of replacing ”The Google” as your home page, it only supplements it.  This is an admirable suggestion, but Right Now‘s purpose is to prevent you from immediately haring off on whatever idea distracted you in the first place.   It’s an anti-procrastination device, and adding procrastination-enhancing distractions to it would be contrary to its purpose.

For me, that page is the “New Tab” page on Chrome. It’s the page that comes up when you first start the browser, and every time you open a new tab with the Ctrl-T keystroke, or by clicking on the [HOME] button with the middle mouse button. I see that page every day, often many times in the day.

I decided I didn’t want the basic utility offered by Chrome, and replaced it with a static home page, a kind of memento mori. It’s based on an idea by Merlinn Mann, I think– it was a long time ago– and the idea is that every time you pull up that page it shows you a list of the things you ought to be concentrating on. It is emphatically not a to-do list; it’s more like a project list, and it has categories to let you describe different “realms” in which you have your projects. Mine looks like this:

Wouldn’t you rather be:

• Programming:
  • A better Facebook
  • The next Pinterest
• Writing:
  • The great American novel
  • The great Martian novel
• Playing:
  • With your kids
  • In your garden

The problem with this set-up is that it was static. Sure, I’m a fine HTML monkey myself, but I wanted something that I could change without having to pull up an editor and look at a ton of HTML every day. So I hacked together this:

Right Now!

Okay, it’s a blank page. But if you click on the “Wouldn’t you rather be” header on the right, you’ll get an opportunity to create a new category, and then under that add a list of projects.

Here’s the (somewhat) nifty part: Your data is entirely stored on your computer. I taught myself to use Zepto and Lawnchair, a micro-DOM framework and a toolkit that uses the new “local storage” engines. There’s no server. There’s no off-line storage. Nobody else can see your data. 

And it’s fast. You don’t even notice the post-download draw. There are still some tics, but on the whole, this is what I wanted to achieve: when I change or abandon a project, the next time I see it, I can make it go away. And when I start a new project, I can put it on the list.

Even better, since I used Zepto and Lawnchair, I was able to write it without using Backbone. As much as I love Backbone, this didn’t need it, and figuring that out necessitated a re-write. So although the tag is “v0.2″, it’s more like “v0.4″, but that’s git for ya.

Anyway, go ahead and enjoy it. The code isn’t gorgeous, but for 140K, it’s a nice, sweet hack. And it means that my project list is now updatable. I’m no longer looking at an outdated list.