"Whoever built the Ant distro from Apple didn’t have all the optional JAR files to hand, so things like the ssh task wont work even if you add jsch.jar to ~/.ant/lib"
— SteveL (on the Ant dev team)

So that pretty much nailed it. Time to upgrade. For this you’re going to need:

• The latest version of ant. (1.8.2 as of this post)
• The Apache Commons Net jarfile. (2.2 as of this post)

First, make sure you even have Ant installed. The easiest way to do this is just to check the version:

$ ant -version
$ Apache Ant(TM) version 1.7.1 compiled on February 10 2010

Great! Keep track of which version you’re using now; we’ll compare version strings to verify our install once we’re done.

Now Ant is kind of buried in OS X; the $PATH variable points to a symlink which points to another symlink. To find out where ant really is, just follow the chain:

$ which ant
/usr/bin/ant
$ ls -la /usr/bin/ant
lrwxr-xr-x  1 root  wheel  22 Nov 11 18:04 /usr/bin/ant -> /usr/share/ant/bin/ant
$ ls -la /usr/share/ant
lrwxr-xr-x  1 root  wheel  14 Nov 11 18:04 /usr/share/ant -> java/ant-1.7.1
$ ls -la /usr/share/java/ant-1.7.1
total 40
drwxr-xr-x   8 root  wheel    272 Feb 27 12:32 .
drwxr-xr-x   8 root  wheel    272 Nov 11 18:04 ..
-rw-r--r--   1 root  wheel  15289 Feb 10  2010 LICENSE.txt
-rw-r--r--   1 root  wheel   1270 Feb 10  2010 NOTICE.txt
drwxr-xr-x   8 root  wheel    272 Feb 10  2010 bin
drwxr-xr-x   3 root  wheel    102 Feb 10  2010 docs
drwxr-xr-x  15 root  wheel    510 Feb 10  2010 etc
drwxr-xr-x  44 root  wheel   1496 Feb 27 12:09 lib

Gotcha! It looks like ant is hiding inside of the default Java directory, so blowing it away is probably a bad idea. Instead we’re going to throw the new version of ant into a common directory and update the symlink.

Copying the directory is easy:

$ cp -r ~/Downloads/apache-ant-1.8.2/ /Library/Ant-1.8.2

Now we need to break the existing symlink and recreate it, pointing to our new version of Ant. You’ll need to do this as root.

$ rm /usr/share/ant
$ sudo ln -s /Users/Shared/apache-ant-1.8.2  ant
$ Password: ********

And when we check our version string…

$ ant -version
$ Apache Ant(TM) version 1.8.2 compiled on December 20 2010

Excellent, the update’s done and we’re on the newer version. The next step is to get the FTP task working. This is just a matter of copying the Apache Commons Net library into Ant’s classpath. If you followed the previous steps, then your Ant classpath is /Users/Shared/apache-ant-1.8.2/lib.

$ cp ~/Downloads/commons-net-2.2/commons-net-2.2.jar /Users/Shared/apache-ant-1.8.2/lib/commons-net-2.2.jar

And that’s it! You should now be in automated deployment bliss. If you need to know how to actually use the FTP task, go check out the documentation.

You're all I ever wanted

I’ve been meaning to do this for a while. When I run into a problem I don’t know how to solve while working on a project, I like to create a new project to address just that problem. Doing so lets me focus on the new script without letting the larger project cloud my thought-process. It’s the equivalent of clearing off a workbench by swiping your arm across it.

But when you clear off a workbench, you want to clear it off fast! Anything else would detract from the problem-at-hand. When I wrote An agile-ready checklist I referred to this too: if you don’t have the ability to get something started and delivered quickly, then you have a process problem. In this case my wish list was pretty short: One script to:

• Create a named project in my shared project directory that includes…
• …my usual directory structure with default .css and .js files.
• …jQuery. Offline so I can work sans interwebz.
• …a unit testing framework, ready to go.
• …a pretty enough UI that I don’t get distracted trying to clean it up.

It’s really not that much when you think about it, and H5B delivers.

"delete-key friendly"

It delivers so well in fact, that it over-delivers. There’s a reason Paul Irish coined the phrase “delete-key friendly” within the list of H5B’s “awesome-er” features; this thing was meant to cover everything from inspiration to deployment, and comes with a bunch of server configuration templates, placeholders for developing jQuery plugins, styles for mobile devices… all of this had to go. In the heat of the moment, I’d rather not be tripping over any more cruft than I have to.

Although I did leave in a few things for later, hidden behind commented code, like the hooks for Google Analytics. No it’s not going to do me any good in a development environment, but I’ve been meaning to throw a few projects behind ninjascript.com, just for the hell of it. Keeping GA commented in there just means I’m more likely to remember to turn it on at some point when it could be useful.

Changing things up

Just because I like to tinker, and if I didn’t do it now then I’d just waste time later, I also made a few additions of my own. The low-hanging fruit just meant upgrading jQuery and writing some custom CSS so that my new projects weren’t completely bare. The more interesting things came in the form of a build script.

H5B does come with its own shell script for creating new projects, but it’s very utilitarian: Create a project directory and copy files over to it. One of my own criteria was that the script create new projects in my shared project directory. I was going to have to change that script anyway, but I wanted to give my new projects some identity too, so in the .html, .css and .js files I added some tokens. The whole thing is ridiculously simple:

$> ant
$> ...Give it a name:
$> ...What's it about?:

And bam! you’re done. The build script reads in a few properties so that I can configure my project path and the token values:

author.name=Scott Grogan
author.site=http://ninjascript.com
dest.dir=/Users/scottgrogan/Projects

Next steps

If the links haven’t given it away, I chucked this project onto GitHub: ninjascribble/SquareOne. Check it out, send feedback, etc… I’ll be updating it as I go. Next up: H5B’s build.xml feels ridiculously cluttered. I like keeping things simple: clean, test, compile, deploy.

I have a technical background, and I know I’m not the only one who suffers this grind month after month. It’s time that bill payment systems see a user-experience overhaul, and I’ve got a few ideas:

Adopt a pay-by-phone-like process

While navigating a phone tree does come with its own set of frustrations, I find the process much easier to deal with. For starters, when I pay by phone I usually need only three identifying pieces of information:

• My account number
• zip code
• and sometimes the last four digits of my social security number

No passwords or security questions, and with good reason: The automated phone system doesn’t allow me to do anything but pay my bill!

Take, for example, the sign in page for Comcast. Along with fields for a username and password, I’m presented with this:

Comcast offers some great features, and if I’m going to use them at all then I expect to have to sign in first. But none of these things have anything to do with paying my bill, and shouldn’t get in the way of my ability to do so.

Let me use my email address as my username

If a company must put their bill-pay feature behind authentication, then making password recovery as painless as possible should be a priority. If I’m only going to use the site once per month, then it’s reasonable to expect that I won’t remember the credentials I signed up with.

Companies can save their customers a lot of frustration by just allowing them to use an email address as their username. Every customer already has a unique one, they’re incredibly easy to remember, and if a customer forgets their password then a reset link can be sent directly to that email address.

Let me decide how secure my password will be

I’ll admit it. I use the same password for everything, with slight variations for sites I’d prefer to be a bit more secure. Nothing frustrates me more than when a company tries to impose a set of arcane rules upon my password creating process. Those rules only serve to ensure that I will forget my password the next time I try to log in. Keep it simple and let your customers use their own judgment.

Security questions based on facts, not opinions

Forming a set of security questions has become a pretty common practice for password recovery. I tend to like the ones that have a preformed list of questions from which to choose, but the quality of these questions are often, well… questionable. My favorite band changes weekly, as does my favorite color and even the memory of which of my many childhood pets was the first. None of these are “facts” in the sense of immutable identifying information that can be readily recalled.

Now I understand that forming security questions and keeping the answers on file can be tricky business. Customers get leery when asked for their mother’s maiden name, or any other information that might be used to identify them on a federal form. But the high school I graduated from, the degree I earned, and the color of my first bike are objective facts and impossible to change.

Making online payments can be a wonderful thing for both customers and the companies they’re paying, but —as with everything interactive on the web— user experience should always be of paramount concern.

“Agile” is a bit of a buzzword these days, and one of the chief complaints I hear from developers working towards an agile methodology is the push to be immediately more productive while the infrastructure lags behind. Maybe the development and pre-prod environments are unstable, the process for deploying to production is slow or costly, or there isn’t an accepted standard for driving automated unit and acceptance tests. Whatever it is that’s slowing you down, fix it! The longer it waits, the worse it gets. Here’s my own checklist for deciding whether or not a project is ready to be called “agile.”

Development and pre-prod environments are up and stable

You would think this would be obvious, but I’ve worked on more than a few projects where the team and product owners were too excited to think about where it would live until they were ready to take it live. Depending on the size and structure of your organization, getting a production environment can be a lengthy process. I’ve seen production set-ups delayed for weeks because the request was given to IT during a maintenance period. Oops.

An automated deployment task is in place

Ideally deployment to production should happen at the press of a button. At my company we use AnthillPro, but there are plenty of other deployment tools out there. The point? Make the process of shipping code as fast and painless as possible, so you don’t ever have an excuse not to go live.

Automated testing is also in place

Automated deployment and automated testing go hand-in-hand. Your unit and acceptance tests are your primary line of defense against production bugs, and just like deployment you want this process to be repeatable and as painless as it can be.

Please don’t misunderstand — I’m not saying that you must have 100% code coverage before you go live for the first time. But having a system in place makes writing them that much easier. Most Java projects incorporate JUnit test suite, which is incredibly easy to integrate with ANT. Acceptance testing can be trickier if you aren’t already familiar with it. If your project sits behind authentication, then you may need to write a custom framework to bypass it.

Happy, productive developers

With the infrastructure taken care of up front, developers can spend more time focusing on the next big feature and less time worrying about the development tools. When working code gets released, everyone feels good — that should be all the reason you ever need to want to do it as often as possible.

Jawr is a tunable packaging solution for Javascript and CSS which allows for rapid development of resources in separate module files. Developers can work with a large set of split javascript files in development mode, then Jawr bundles all together into one or several files in a configurable way.

Jawr allows you to keep your Javascript and CSS files separated and organized within a project, while still taking advantage of resource minification, concatenation, compression and caching (ie. bundling).

But why should I bundle my resources anyway?

Because for every shiny presentation effect there’s an HTTP request, and sometimes those requests are BIG. I’ve been recently working on a project that pulls in a number of Javascript data visualization libraries, none of which come cheap. The project is behind authentication and not exactly intended for public consumption, but here are some screenshots I pulled from Firebug’s net tab.

First the CSS:

5 resources weighing in at 40k. Not terrible, but that’s a lot of requests for just the CSS. Every single one adds overhead that stands between the report and its intended viewer. Since this is a screenshot from my development environment, the timeline may be a bit misleading, but in this case loading these resources probably won’t take up enough time to be any real concern.

The Javascript on the other hand…

6 resources and 340k! Even on a fast connection this is going to take a few seconds to come down the wire. These requests are intentionally made after the rest of the page has loaded, but a good chunk of the functionality relies on these scripts; until they load the visitor is going to be staring at a sweet-looking UI without any real way to interact with it. Worse still, as the project grows so grows the resources; bundling just became important.

Jawr to the rescue

There are plenty of ways to manage the size of your resources:

• Concatenation, or smooshing all of your resources into a single massive file.
• Minification, aka “hope you weren’t planning to make any changes to that script”.
• Compression, which often means run-time decompression. I’m talking Packer, not GZip (which is awesome).

For the most part these are fantastic in a production environment, but while I don’t have the benefit of your own experience to draw upon, in my experience the only kind of project that isn’t constantly being reworked and redeployed is a dead one. While Jawr is one of many ways to achieve the best of both worlds &mdash& a clean development environment and compact production resources — I really appreciate how simple it is to configure and maintain.

Configuring the servlets

Every CSS and Javascript request needs to go through Jawr in order to take advantage of bundling. When a request is made, Jawr will decide (with help from your config file) whether to respond directly with the resource, or to perform an operation on it first.

  JavascriptServlet
  net.jawr.web.servlet.JawrServlet
  
    configLocation
    /jawr.properties
  
  1

 

  CSSServlet
  net.jawr.web.servlet.JawrServlet
  
    configLocation
    /jawr.properties
  
  
    type
    css
  
  1

 

  JavascriptServlet
  *.js

 

  CSSServlet
  *.css

Configuring jawr.properties

You can set up as many bundles as you need here, eg. a core bundle that is used throughout your project and a few context-specific bundles if you need them. Jawr lets you make considerations for which resources should be bundled in which order and which resources should be spared the compression algoritm. Depending on how complicated your bundles are, this file can get pretty hairy. For clarity, the following shows only the configuration for my project’s core Javascript bundle. There’s plenty of documentation to follow at http://jawr.java.net/docs/custom_bundles.html.

One thing to note is that every request for a bundle will be routed here. When debugging in your development environment, it’s best to flip the jawr.debug.on property to true. Jawr will then serve up all of the uncompressed resources that would have appeared in the bundle.

# Common properties
jawr.debug.on = false
jawr.gzip.on = true
jawr.gzip.ie6.on = false
jawr.charset.name = UTF-8

# This is the root dir for all our javascript resources.
jawr.js.bundle.basedir = /js

# Define the core set of scripts for use across the platform.
jawr.js.bundle.core.id = /bundles/core.js
jawr.js.bundle.core.composite = true
jawr.js.bundle.core.global = true
jawr.js.bundle.core.child.names = jquery,dependencies

# No need to compress pre-compressed scripts, just add them to the bundle.
jawr.js.bundle.jquery.mappings = /js/libs/jquery-1.4.4.min.js,\
                   /js/libs/jquery-ui-1.8.9.custom.min.js
jawr.js.bundle.jquery.bundlepostprocessors = none

# These guys are part of the core bundle too...
jawr.js.bundle.dependencies.mappings = /js/libs/OpenAjaxManagedHub-core.js,\
                   /js/libs/IntelReports/IntelReports.js

Adding Jawr to the JSPs

Jawr comes with a small taglib for use inside of an application’s JSP files. The jwr:script and jwr:style tags will interpret Expression Language natively, and simply refer to a bundle definition within jawr.properties before handling the request.

<@ taglib uri="http://jawr.net/tags" prefix="jwr" %>

The payoff!

With bundling enabled, the application sees a dramatic benefit.

CSS Just under 6k! It wasn’t huge before, but it’s certainly not causing any trouble now. In fact this same project is using sprites that come in larger than the CSS that drives them. Maybe something to investigate another time!

And the Javascript?

60k is certainly a reasonable size for some pretty large libraries, and represents an incredible more than 80% savings over the uncompressed example. Jawr does allow you to specify which minification method to use, and it’s certainly worthwhile to play around and see which options work best for your project. These figures came from a quick default integration, and I couldn’t be happier with the way things turned out.

Edward Tufte would be quick to point out that neither the visualization nor its corresponding blog post contain two bits of concrete information: The actual national average tweet-rate, and how it compares to previous years. Without these vital metrics, the conclusion (“…Twitter will be an especially important tool if you are trying to grow your business…”) is a bit suspect, though the $150M (projected) they made in 2010 tells me they’re doing OK.

That minor quibble notwithstanding, the map does call out a few surprising conclusions (Massachusetts is one of the top three? Really?). I’d really love a time-series of these maps over the last four years, just to see how much things have grown and changed.

Speaking of Twitter, it dawned on me today that my own decline in Twitter usage links directly back to the acquisition of my iPad. Lets look at the crucial facts:

* App-switching was non-existent for a good while post-launch.
* The iPad features a terrible, awful, horrible (sorry…) keyboard.

Don’t get me wrong, I’m sure there are thousands of happy iPad tweeters in the world, but I’m not one of them. Sadly though, because the Flipboard app integrates with Twitter I *do* still post retweets and article links pretty regularly. Unwittingly I am a cog in the information proliferation machine.