Timeless Songs

There are great songs, and then there are timeless songs. Songs that are appreciated generation after generation, and throughout the different stages on one's life.

I think part of the test of a timeless song is how an acoustic, or 'unplugged' version holds up. When you strip out all the energy and 'noise', do you still have something that you love?

I just saw an old ('75) acoustic performance of Thunder Road (thanks Merlin), and it reminded me of why the song is so great. When you strip it down to its core, it is still amazing.

This song and album are both available as MP3 downloads at Amazon (affiliate link).

MTV Unplugged popularized the idea of acoustic versions of rock (and other genres) songs. As a Bon Jovi fan, I've enjoyed a couple Unplugged versions of Living on a Prayer, but the classic one is the '89 MTV Awards:



Acoustic versions often give you a closer and more intimate connection with the lyrics. While this is generally true, and certainly true of the previous two songs, I don't find this Dylan Unplugged version of Like a Rolling Stone creates that closer connection. I think it is too 'busy'. To many instruments, too much noise. Take it as a contrast to the previous two. It is still a great song, but I much prefer the more distilled versions by Bruce and Jon.

Building Flex Applications with Gradle

In a recent post, I touched on my frustration with Maven and my interest in other build tools. Gradle looked interesting (Grovy DSL with Ant integration). I've been playing with building a Flex app, so I thought I would see if I could get Gradle to build it. Since Adobe provides custom Ant tasks as part of its SDK distribution, it should be easy. In fact, it is.

Assumptions:
  • You have downloaded the Adobe SDK (or Flex Developer)
  • You have a sample Flex (or Air) app to build.
  • You have Gradle downloaded and installed.
The first step is to create a Gradle build file (build.gradle) in your Flex application directory. To test your Gradle install, put a simple Hello World task:

task hello << {
println "Hello World"
}

You can then run gradle hello from your command prompt. It should echo back:

:hello
Hello World

Now you need to 'install' the Flex Ant Task Jar. This can be found in your Flex SDK Install under the ant directory (sdk_install/ant). There are a couple ways to install this. The easiest is to put it in the lib directory under your GRADLE_HOME directory. You can also specify the classpath in the taskdef command, but I'll leave that as an exercise for the reader...

Once you have the Flex Ant Tasks installed, you can create your Gradle build script. Here is a straight foward compile script:

ant.FLEX_HOME="c:/Program Files/Adobe/flex_sdk_3"

ant.taskdef(resource: "flexTasks.tasks")

task compile << {
ant.mxmlc(file: "src/Main.mxml") {
}
}

You will need to change the FLEX_HOME value and Main.mxml to your specific environment/app, but that is it. You can then execute gradle compile from your command prompt and compile the application.

If it is an Air app, you will need to add configname: "air" to the mxmlc task definition so it uses the Air configuration. Otherwise, you will likely see: Unable to locate specified base class 'mx.core.WindowedApplication'

To build the Air package for your application, you will also need to call the script file included with the SDK. You can find a sample of the ANT version of this here.

This example is more a sample of how easily Ant tasks can be used in Gradle than the overall power of Gradle. But it does demonstrate that Gradle can be used to build anything that has Ant tasks, and that is a great start.

Build Tools

I've said it before, I find Maven annoying. I've even explored other build tools like Simple-Build-Tool, which I like, but I'm not sure I love.

Now Steve Ebersole from Hibernate joins the ranks of the frustrated Maven users. He is frustrated with Maven's module setup, something I've seen first hand on my current project.

Based on the comments on his post, it seems that Gradle is becoming a popular alternative, I'll have to check it out.

Simple-Build-Tool is also mentioned, though I've only used it for Scala projects so far, I find it interesting but also a bit difficult to fully understand. It's flexibility and use of Scala is powerful, but has the common side-effect that it isn't obvious how to accomplish something, or what a configuration line really does. I like the fact that it leverages Maven's standard structure, allowing you to easily test Maven projects with SBT.

I think Ant could also be salvaged, if it adopted the Maven directory conventions and then allowed configuration from there, but I'm not sure that it the best approach. It may just be time to move on.

What do I really want? A tool that provides simple setup for 'standard' projects, but allows the flexibility and power for fine grained control when I want to devaite from the 'norm'.

Deceptive Marketing

There is a great post on 37 Signals about 'Little Green Lies'. I've looked at the exact same label ('98% naturally derived ingredients') and thought the same thing.

What does that even mean? EVERYTHING is 'derived' from something natural at some level. The sad part is that marketing like this works.

John Hughes

With John Hughes' passing yesterday, it is appropriate to pay tribute to his life and work.

For me, he was the writer and director of the movies that defined my adolescence. As a writer, he had an amazing string of hits from 83-87 with:
To write that many great movies every year for 5 years is amazing, especially since he directed over half of them himself. I've seen every one of these movies many times and enjoyed them all. Add other hits like The Great Outdoors (1988) Uncle Buck (1989), National Lampoon's Christmas Vacation (1989), and Home Alone (1990), and it is an amazing career.

Growing up in Chicago, John Hughes' movies always had a special appeal. They were often set in Chicago or its suburbs, and represented Midwestern suburban kids. Me.

Here is a great montage on YouTube set to a great song...


Mobile Web

Fred Wilson has an interesting post about the 'Mobile Web', and how it is different than the world wide web we know. In short, the mobile web is highly fragmented. Read the article.

This is an issue that has impacted my thought process recently. I've been considering getting a new mobile phone (PDA), and as a long time Palm user I'm interested in the Pre. The OS looks great, it has a physical keyboard, and the device is fairly open (you get root access with the developer SDK). However, in the fragmented mobile market, the iPhone is the king. The development effort and ecosystem around the iPhone is amazing. In a fragmented market, I'm not sure I want to bet on a niche player.

There are many reasons for this fragmentation, some technical, some institutional. I'd like to see more of the institutional ones removed (no exclusive carrier agreements, more 'open' devices), but on 'limited' devices, tailoring the experience to the hardware is important for usability. There is a reason that the iPhone SDK was the key to the devices explosion. Apps delivered in the iPhone browser are just not as compelling.

To achieve a mobile web as ubiquitous as the world wide web, we need to make the browser the default application delivery platform, just as it is on 'real' computers. I'm just not sure the devices and networks are there yet.