Great Spring and Maven tutorials Cameron McKenzie: “The Easiest Way to Get Started with Spring” – good toe-dip to the Spring container, dependency injection and inversion control. Will Iverson: “Building Web Applications with Maven 2” – great intro to Maven, building a small web-app, and running it with Jetty.

JavaWorld: John Ferguson Smart: “An introduction to Maven 2” – a bit more detailed then the previously mentioned Maven tutorial, but does not include Jetty unfortunately.

If I could find one tutorial that brings these elements together, with a little Eclipse IDE configuration and usage thrown in, it would be great.

On “finding truth in the world and about ourselves”

Is Programming more like ‘art’ then ‘science’? A debate that is continuous, but I know where Richard P. Gabriel stands. In 2003 he wrote the forward to “Successful Lisp: How to Understand and Use Common Lisp,” by David B. Lamkins titled “The Art of Lisp and Writing”. Recently it got shared at “Hacker News”.

I admit to knowing enough about Lisp to be intrigued (inspired by it even) but have never used it at work or in a personal project. His essay while touching on some differences between Java and Lisp (and he would know – he worked at Sun), talks more of the act of writing and creation and how programming is akin to that. It was a good read.

Taught that programming–or the worse “developing software”–is like a routine engineering activity, many find difficulty seeing writing as a model or even a metaphor for programming. Writing is creative, it is self-expression, it is art, which is to say it isn’t a science and unlike science and engineering, it isn’t a serious activity. Judgments like this, though, are easiest made by people who don’t seriously engage in making both science and art. Art, engineering, and science are–in that order–part of a continuum of finding truth in the world and about ourselves.

…The difference between Lisp and Java, as Paul Graham has pointed out, is that Lisp is for working with computational ideas and expression, whereas Java is for expressing completed programs. As James says, Java requires you to pin down decisions early on. And once pinned down, the system which is the set of type declarations, the compiler, and the runtime system make it as hard as it can for you to change those assumptions, on the assumption that all such changes are mistakes you’re inadvertently making.

There are, of course, many situations when making change more difficult is the best thing to do: Once a program is perfected, for example, or when it is put into light-maintenance mode. But when we are exploring what to create given a trigger or other impetus–when we are in flow–we need to change things frequently, even while we want the system to be robust in the face of such changes. In fact, most design problems we face in creating software can be resolved only through experimentation with a partially running system. Engineering is and always has been fundamentally such an enterprise, no matter how much we would like it to be more like science than like art. And the reason is that the requirements for a system come not only from the outside in the form of descriptions of behavior useful for the people using it, but also from within the system as it has been constructed, from the interactions of its parts and the interactions of its parts separately with the outside world. That is, requirements emerge from the constructed system which can affect how the system is put together and also what the system does. Furthermore, once a system is working and becomes observable, it becomes a trigger for subsequent improvement.

Read the whole piece.

Old classic essay on software artistry/craftmanship: “Hackers and Painters”, by Paul Graham

Paul Graham: Hackers and Painters:

When I finished grad school in computer science I went to art school to study painting. A lot of people seemed surprised that someone interested in computers would also be interested in painting. They seemed to think that hacking and painting were very different kinds of work– that hacking was cold, precise, and methodical, and that painting was the frenzied expression of some primal urge.

Both of these images are wrong. Hacking and painting have a lot in common. In fact, of all the different types of people I’ve known, hackers and painters are among the most alike.

What hackers and painters have in common is that they’re both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They’re not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.

I’ve never liked the term “computer science.” The main reason I don’t like it is that there’s no such thing.

…For a long time I felt bad about this, just as I once felt bad that I didn’t hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you’re writing them, just as writers and painters and architects do.

Realizing this has real implications for software design. It means that a programming language should, above all, be malleable. A programming language is for thinking of programs, not for expressing programs you’ve already thought of. It should be a pencil, not a pen. Static typing would be a fine idea if people actually did write programs the way they taught me to in college. But that’s not how any of the hackers I know write programs. We need a language that lets us scribble and smudge and smear, not a language where you have to sit with a teacup of types balanced on your knee and make polite conversation with a strict old aunt of a compiler.

Make sure to read the whole thing.

I’ve disagreed with Graham on a number of things over the years. In particular his assertion that “good hackers prefer Python to Java” (note that ‘hacker’ in this context refers to a software artisan, not the caricature you see on TV), but as I get older… well I’m appreciating Python more and more and my realize just how right he probably is.

Javascript links for September 8, 2009

Ian J Cottee: Rhino on OS X Leopard Server-Side JavaScript with Rhino and Jetty Programming Java With JavaScript

Steve Yegge: Code’s Worst Enemy

John Resig: Bringing the Browser to the Server (hmmm, jQuery on Rhino?)

YouTube: Google I/O 2008: Steve Yegge on Server Side JavaScript (transcript and slide links):

benne: On-the-fly JavaScript syntax checking in Emacs

Patrick Hunlock: Essential Javascript (nice tutorial)

Reading about Graphviz

While gearing up on a content management project, a few developers were wrangling with how to share solution diagrams between Visio and OmniGraffle. While there is a level of compatibility between the two, its not ideal. While researching, I went off into a related tangent, a cross platform tool that I can manipulate from a text editor or programming language, and ended up reading about Graphviz.

Graphviz – command line tool and DSL (dot) to define and render graphs and diagrams.

Doesn’t sounds like much, but check out this magic: Visualizing traceroute output with Ruby and Graphviz or how about Maven based dependency graphing?

I think prefuse (with the unbelievable looking flare) is an excellent related toolkit to look into next (interaction and animations!!!!!) .

O’Reilly: An Introduction to GraphViz and dot

O’Reilly: Graphviz – Why draw when you can code? org-exp-blocks.el: pre-process blocks in org-mode files in Emacs to generate diagrams – rocking!

Bernt Hansen’s fantastic Org Mode – Organize Your Life In Plain Text! is a working example of the above org-mode use case (and a great org-mode tutorial)

Forever for Now: UML Diagrams Using Graphviz Dot

Haven’t read or experimented with yet, but will… Create relationship diagrams with Graphviz

IBM developerWorks: Visualize function calls with Graphviz

Graphviz Resources – large list of viewers, navigators, language bindings, etc

WikiViz: A large list of related tools and libraries

ZGRViewer: a Java-based desktop GraphViz/DOT Viewer – Adds interactivity to viewing a dot defined graph.

Graphviz Eclipse plug-in




Very quick start with Scala on OS X

1. Download and extract directory

2. Move scala install directory under to /usr/local/.

3. Add SCALA_HOME variable to your .bashrc export SCALA_HOME=/usr/local/[SCALA INSTALL DIRECTORY]

4. Add $SCALA_HOME/bin to your path in .bashrc, example: export PATH=$PATH:/usr/local/bin:/usr/local/sbin:$SCALA_HOME/bin

5. Get Emacs set up, read Scala, Emacs, and Yasnippet and Stone Tools and Scala Development.

(even easier, check out Bill Venners of Artima’s tips for steps 1-4)

Play, experiment. Maybe write the equivalent of Code To Joy’s myTunes: Groovy and JFugue (“Crazy Train” as the new “Hello World”? Not exactly, but a fun exercise).

Read The busy Java developer’s guide to Scala: Functional programming for the object oriented