Alan Gutierrez

I’ve resumed the Think New Orleans mailing list. I’ve sent two missives already.

I’ve postponed the mailing list for a while. It has always been very successful. People know me more through the mailing list than through the weblog or the Wiki.

My first mailing was last week. At the Bayou Boogaloo, people said, hey, I got your message. There were people who wrote me back, to tell me that they would have missed the Bayou Boogaloo if not for the missive.

Mass email is distasteful to a web developer like myself. It seems cheap.

In New Orleans however, the protocol that reigns supreme is not HTTP, but SMTP. People don’t want to Google. They already have so much information it hurts. They are not about to go searching for more. An inbox is an evil. It is however, quantifiable. There is a count. Moreover, it is evil that has your name on it. It has that much context. There is still no place that provides significant context for information about New Orleans or the recovery.

In order to resume the email list I created an Java project and called it emailer. It was dull programming. Simply, reading the Java Mail API references that I’d collected, and applying them. I have an objective to grow the list, and grow it quickly, advertising it’s circulation growth in each missive.

The first step was to develop a simple opt out form. Then I sent out a multipart alternative message, built from the plain text and HTML exports of a Writeboard. I set up a bounces address and generate a VERP address and send it according to the article Using Apache James and JavaMail to implement Variable Envelope Return Paths.

After the Bayou Boogaloo, and the kind words about the missive, a name for the project occurred to me, whilst walking across Washington toward Mid-City.

• Missive - a written communication.

I’m enjoying this project, now. Looking forward to what it can accomplish.

Yesterday, I sent out another missive using the same revision. The same except that I changed the project name.

This evening I added embedded images, where before I was linking to images on Flickr, so my next missive will be more readily compatible with GMail and others.

Too much learning programming can be too much to bear. It is less cumbersome to implement algorithms than to learn APIs.

Last Meal by Shannon.

I hate Ant. Ant takes a miserable task and makes orders of magnitude more difficult. It is a horrible piece of software. I am constantly amazed at the traction it has gained.

Ant is a dependency management system, or rather that’s the void that it fills. Make for Java. However, unlike Make, Ant cannot build a dependency tree of an entire project, mapping dependencies from one target to the next.

They defend themselves. It is explained that it is a declarative language, not an imperative language, and you need to think declaratively. That’s a behavior they’ve aped from the SQL community. However, SQL is a declarative language, based on years of database theory.

The SQL community tells you think declaratively, so that you might open your mind to the rich expressiveness of relational calculus. The Ant community tells you to think declaratively, because they don’t have an answer for your question. Don’t go off thinking declaratively, expecting that your problems with Ant will ever be solved.

Yes, SQL is declarative, think declarative in SQL. Lisp is functional, think functional in Lisp.

Ant is broken. A real build system is a dependency management system. It should manage your dependencies. It should not ask you to change your thinking. It has nothing more to say.

Who wants to change their thinking for the sake of a build? A build system should be cursory consideration, not mental discipline.

Eventually, you’re going to install one of many Ant tasks that implement a loop, or embed JavaScript, or generate your Ant scripts, or write a bash program that will actually get the job done.

Ant is not a dependency management system. What is it then?

It’s concept of dependencies are nothing more than procedure calls. An Ant target is a procedure with no logical branches. Ant dependencies are a series of subroutine calls that can only be invoked at the start of the subroutine.

They fire unconditionally, they perform no checking of dependencies. They will not be skipped because their dependent files are up to date.

This is because, unlike C where dependencies form a tree, Java can have cyclical dependencies. The Java compiler does it’s own dependency management. This led the developers to decide that system wide dependencies were unnecessary.

The result is that every task has to manage it’s own dependencies. Few of them do. The copy command does, the zip command does. That’s about it. Most of them are procedures with a myriad of named parameters.

A target will always evaluate. They may not execute because of a condition attached to them, but that condition will have to be set by a task that executed prior. If you really do want to check dependencies, you are going to have a chain of targets. The noise that produces on the command line makes watching an Ant build akin to reading a core dump.

What does Ant give you that keeps people from running away? It doesn’t do repository management. We need Maven to cock that up.

I’ve abandoned the pointless XML files. I’m building in Groovy now, so I don’t have to pretend that Ant is teaching me how to think declaratively. I have real data structures and algorithms to make short work of what should be a short task.

I must still use AntBuilder and here’s what for. Ant wraps the Java compiler, and JUnit. Ant implements a form of file globbing. It has file system comfort functions, like conditional recursive copy and a recursive delete.

I Hate How Much I Hate Ant

Many drafts of this post. I wasted a morning looking for a photograph to accompany it. An important morning at that. I can’t find one. I don’t want to show ants, because they are ugly. I don’t want to show them eating poison, because they are ugly, even if they are going to die soon.

I hate Ant. I hate it because I spent a lot of time on it and in the end I did not use it. I spent months on the sort of non-trivial build. That sort that Ant will have you abandon your real project, and make Ant your project. I tried to generate Ant with with XSLT. I tried using the includes. I spent hours trying to push the limits of a this stupid batch file format.

I hate how much I hate something trivial. I hate how much I hate Ant. I can’t find a photograph, because it is such toxic process to do so. What conveys your hatred for a tool that makes a process even more labor-intensive? What conveys your hatred for an entire community that adheres to this childish weekend hack, this manifestation of a gross misunderstading of XML as a standard when it is so terribly easy to write a replacement?

Is it that Java is so permiated with bloatware marketing, that it has become part of the mindset of the open source Java community? Talking about a standard build tool, and that build tool is a hopeless joke, but if we talk right, it will correct itself, because it is a standard.

I am going to end this by saying, I don’t like bile. It is much easier to be creative than critical. It takes much less effort. It becomes almost effortless.

Revisiting my build system sucked me into the fear of getting sucked into build configuration and not shipping.

The approach has been toxic. It is here so I can revisit it.

A placeholder post, for notes on how to setup a web store lickity split.

For when I create the lesson plan for Photo Albums with Flickr, this map of the places where a person lived in the Midwest, created by placing notes on an elementary school globe.

Maybe I can just collect the photographs from Flickr for this Urban Scavenger Hunt.

From Instanley Great by Steve Levy, a story about the phrase coined by Steve Jobs, “Real Artists Ship”. The project mentioned in this article is the Macintosh.

Jobs’s speeches were punctuated by slogans. Perhaps the most telling epigram of all was a three-word koan that Jobs scrawled on an easel in January 1983, when the project was months overdue. REAL ARTISTS SHIP. It was an awesome encapsulation of the ground rules in the age of technological expression. The term “starving artist” was now an oxymoron. One’s creation, quite simply, did not exist as art if it was not out there, available for consumption, doing well. Was Engelbart an artist? A prima donna — he didn’t ship. What were the wizards of PARC? Haughty aristocrats — they didn’t ship. The final step of an artist — the single validating act — was geting his or her work into boxes, at which point the marketing guys take over. Once you get the computers into people’s homes, you have penetrated their minds. At that point all the clever design decisions you made, all the twists and turns of the interface, the subtle dance of mode and modeless, the menu bars and trash cans and mouse buttons and everything else inside and outside your creation, becomes part of people’s lives, transforms their working habits, permeates their approach to their labor, and ultimately, their lives.

But to do that, to make a difference in the world and a dent in the universe, you had to ship. You had to ship. You had to ship.

Real artists ship.

This is the definition of prudence for the knowledge worker.

I’ve created a sign up form for CHAT. This sign up form is based on software that I’ve developed, primarily Stencil, for those of you who want to look behind the sceens. For those of you who don’t, consider this a general purpose nonprofit or civic organization registration program. Please, help by suggesting features, and reporting programs in the comments of this post.