This was not ideal.

My next job was after I'd dropped out of school, up in Portland, OR.  It was a small web development agency and we had a dedicated development server in our office which we worked on, and then separate production servers colocated offsite.  This was much better, but still meant we (the developers) stepped on each others toes all the time.

Getting better…

Next came working for a university on some internal project, still in Portland, OR.  I was the sole coder, and while I had my full development environment on my local machine, the most striking difference wasn't that it was local (and therefore fast and easy to screw with), but that I didn't have to compete with other devs' changes.  This was a big boon, and my productivity demonstrated it.  But still no version control, if you can believe it.  I still don't understand why that isn't forced on students in CS 101 before the first code project.

Almost there…

My first "real" job was up in Bellingham, WA with a company which sold communications management software.  The whole app was ColdFusion and sold with a SaaS model (about the same time as Salesforce.com was conceived).  There we not only had a production cluster, we had a staging environment, a dev (bleeding edge) environment, and per-developer environments on our local workstations.  It was here that I learned about version control, saw that it was a Good Thing^(tm), and put on my tantrum face and forced everything to halt until we had it implemented.  We used CVS, and then upgrade to SVN just after it went 1.0 (after watching it get closer and closer with bated breath).

We've got it!

My next job was back in good old Portland, OR.  I had to create SVN infrastructure, but no worries.  I knew what we needed, especially with six developers.  Also had to create local-workstation development environments, but again a completely worthwhile investment.  The trick was learning to leverage all of this, which brings me to the point.

Every developer should be able to blindly and without regard for any consequences thrash their working codebase to see if random idea X works.

It has taken me a decade to really appreciate how important this simple idea is.

If you can't do this with your current development environment, you should invest some time in making it possible.   It means you need to be able to break any and every piece of code without affecting anyone else.  Including yourself if you need to fix some urgent bug all of a sudden.  It means you should be able to use version control if your idea takes 75 commits to test out, without affecting anyone else.  Including yourself as before.  It means that if your idea works, you shouldn't have to struggle to share your solution and get it into the next nightly.  Even if you're the only developer.

So what do you need?  You need (at least):

1. version control which supports concurrent editing, branching and merging
2. a completely isolated instance of your software project with it's own working directory
3. the ability to create n copies of #2
4. a habit of small atomic commits (commit early, commit often)
5. the confidence in your setup to trust that no matter how bad you screw things up, you can always get back to any previous state whether it was five minutes or five months ago

The first points is a no brainer, but is vitally important as it is the only way to get the remaining four items.  Points two and three are different sides of the same thing as #3 is really just #2 where you have two personalities (normal dev and crazy hacker dude).

Point four is a learned skill.  This isn't a piece of technology you adopt or something you do, it's a habit you consciously work to build because you want to be a better developer.  It's hard.  Everyone knows it's far easier to just take a pile of changes you've made and commit them with a message like "fixed stuff".  Suppress that urge.  Don't give in to the easy road.  Spend the time to fix one thing, ensure it works, ensure it's atomic, and commit it.  Then move on to the next thing.  If you're working on eight things at once, first go talk to your boss because they're clearly insane, and then think about point three and do each task in a separate working copy (perhaps even against a separate branch).  This might seem like pure hassle and no benefit, but it's the only way to make the investment you've made with points one to three actually pay off.  Version control repositories with non-atomic commits are certainly better than no version control at all, but the non-atomicity severely hamstrings their primary objective: the ability to act as a time machine.

Which brings me to the final point.  Confidence is a learned skill.  It comes partially from trying and succeeding, but it mostly comes from trying and failing and learning that your precautions keep you safe.  It's important to pick up random idea X and give it a whirl.  Really important.  And the only way to go about it is with the confidence you can recover from anything.  Anything.  If you don't have that confidence, you're going to go about it in a half-ass manner in case something unexpected comes up.  It's human nature; don't feel embarrassed.  What you have to realize is that because we are software developers, we have a distinct advantage.  We have a time machine.  We can go back in time, to any point in time, and start over fresh.  The lack of physical deliverables gives us this advantage, and we'd be fools to not take full advantage of it.

If you can't do that today, I strongly encourage you to think about ways you can get closer.  Don't worry about trying to get there in one step, just get closer.  Do that repeatedly and you'll get there, and every step closer has tangible benefit to future development.  It is worth every ounce of energy it takes to get there.  It's also important to look at new projects with the same mindset; setting yourself (and your fellow developers) up for this from the get-go is simple if you have the forethought to do it.

I have confidence in my development environment.  It's not perfect, but I have no qualms about ripping the heart out of a 300,000 line subsystem and seeing if I can put it back together.  That confidence means I can act.  I don't have to worry about consequences until I can reasonably weigh their ROI.  No more "what ifs".  Interestingly, every Star Wars nerd's favorite line is exactly wrong when applied to software: "do or do not, there is no try" "try, there is no do or do not".

Ten years ago, being a web developer sucked.  Deployment was easy (rsync to production and done), but the tooling available to us was dismal.  And I mean crying-naked-in-a-snowstorm dismal.  Browsers were inconsistent, their built-in programming environment (read JavaScript) was reasonably functional but horridly slow, and hardware wasn't beefy enough to deal with scripting languages for hard-core number crunching.

But we had the Flash Player.  Flash provided an environment that beat all three of those problems, and beat them soundly.  It was consistent across browsers and operating systems, used a similar language to what we were used to (both JavaScript and ActionScript are ECMAScript implementations), and it let the developer compile the script into something a little lower level to run in a dedicated VM on the user's machine which meant it was faster.  Of course, Flash is an animation toolkit, but we figured out how to bastardize it with the single-frame movie with a include-and-stop script in it so we could build applications entirely with script (like we wanted), but leverage the Flash player to actually run them.  Not to mention the rich support for visual stuff.  All this led to the concept of a RIA (Rich Internet Application).  Something similar to what we had on the desktop, but deployed to the web with all the benefits (and some drawbacks) that has.

Then browsers got their act together.  We started seeing a unifying focus on application development with the browser as the environment.  People got serious about fast JavaScript runtimes.  Standards were written (e.g., CSS2/3, Canvas) and largely adhered to.  And hardware got faster.  JavaScript application frameworks (EXT, YUI, GWT, etc.) showed up to leverage all that, and now it was possible to build RIAs using standards supported by a wide array of vendors.

In order to compete with this, Adobe released Flex, which is an application development framework for deploying to Flash Player.  It was horridly expensive, difficult to work with, had all kinds of implementation problems, but was better than what you got with JavaScript.  For a while.  Unfortunately a single software company, even one of the largest in the world, couldn't hope to compete with the widespread interest and momentum around browser-native RIA development.  Flex died as a web application framework pretty much before it was released.  Which isn't to say it wasn't used (it was and still is), but the browser RIA juggernaut crushed it like a bug.

Then we saw the huge surge in mobile devices.  It started with smartphones and now includes tablets and e-readers of various form factors.  Fortunately for both consumers and manufacturers, the web wasn't new, so they were able to jump right on top of all the standards and browser capabilities which had been created for the desktop.  A huge market segment opened up for web application developers and browser-native was reasonable right out of the box.

Adobe again tried to compete by creating Mobile Flash Player, but the benefits of Flash Player are small on new mobile devices, especially considering that so much of a mobile device experience is through web-connected native applications, not traditional web applications.  And here we have Adobe's smartest move yet around Flash Player: killing it for the mobile market in favor of restructuring the ecosystem around using it as a development environment for native applications.

Unfortunately, I don't think it's going to matter because Flash is still really slow and heavy and it's not really that much better to develop with than the truly native dev kits.  Yes, it offers the promise of cross-platform deploy, but just as Java demonstrated 10-15 years ago, that isn't much of a selling point for a single application.  People expect not just native execution, they expect native idioms, which means you have to develop for a specific platform, even if you're using a cross-platform toolkit.

So where does that leave us?  As consumers it leaves us in a great spot: there are lots of ways developers can deliver engaging applications to us, on all our devices.  As developers it leaves us in a weird spot: we're stuck with being either web or native developers, with Flash now trying to occupy a sort of middle ground (develop web-style, deploy native).  On the desktop I think Flash (via AIR) holds some promise, but ultimately I don't think it'll last.  The platform just isn't compelling enough to justify the dedication it requires to use it.  Java was designed for very much the same purpose as AIR, and virtually no one uses it.  Java moved almost entirely server side, something which Flash isn't likely to do.

Most interesting is the PhoneGap/Titanium/etc. movement which is very much paralleling the browser resurgence I talked about earlier.  Huge communities of people are working to take all the skills we have as web application developers and give us a build process to take web-ish apps and compile them into native applications, in much the same way Adobe has use AIR to compile Flash into native apps.  However, I think Flash is going to lose in exactly the same way, and for exactly the same reasons, as it lost in the browser.

Bottom line, if you use the web or a web-connected device (read: everybody) the world is going to be glorious in a couple years and only get better.  If you're a developer trying to work in that space, you need to learn browser technologies.  It's the way of the future.  Flash had it's run, but it's been on the way out for a long while.  It'll stick around, just like COBOL and Fortran have, but without an alternative path like Java ended up taking it isn't going to stay relevant to mainstream developers.

First, you need to enable the 'description' field in the subtask list.  Open up your '/WEB-INF/classes/jira-application.properties' file and find the 'jira.table.cols.subtasks' property.  Add 'description' to it (I put it after 'summary').  Similarly, find the 'jira.subtask.quickcreateform.fields' property and add 'description' to it also.  Then save and restart JIRA.

Second, load up this userscript (make sure to fix the server to match your JIRA installation) into Greasemonkey.  It does a few things, but primarily it moves the description into its own row and changes the summary to link to the edit form instead of the browse page.

Also note that if you want to reorder the subtasks more efficiently, you can very easily tweak the URLs for the up/down links to move more than one step at a time.  If you copy the URL of one of the links you'll see two numbers in it.  The first number is the current position of the issue and the second is the desired position.  They'll always be one apart, but you can change the second number to any valid position to jump the subtask to that position in the list.  Hardly an ideal interface, but it's faster than moving one step at a time if you have to move more than a couple spots.  Eventually I'll probably improve that in the userscript to some level, but not exactly sure how I want it to work so I'm leaving it as-is for now.

Update 2011-09-16: I've made a couple additional tweaks to the script and removed the inline version.  Completed subtasks are now greyed out and descriptions hidden so they're not as intrusive.

// ==UserScript==
// @name           Outlook Web App More Gooderer
// @namespace      owa.barneyb.com
// @include        https://*/owa/
// @include        http://*/owa/
// ==/UserScript==

(function() {
  var originalTitle = unsafeWindow.document.title
  var f = function() {
    var ss = unsafeWindow.document.getElementsByTagName('span')
    for (var i = 0, l = ss.length; i < l; i++) {
      if (ss[i].getAttribute('fldrnm') == 'Inbox') { // 'Unread Mail' is also reasonable
        var children = ss[i].parentNode.childNodes
        var count = 0
        if (children.length == 2) {
          count = children[1].childNodes[1].innerHTML
        }
        unsafeWindow.document.title = 'Outlook ' + (count == 0 ? '' : '(' + count + ')')
          + ' - ' + originalTitle.split('-')[0]
        break
      }
    }
  }
  setInterval(f, 15 * 1000)
  f()
})()

Just drop that into a new user script, ensure the @include directives will match your OWA endpoint, and reload.  Now when the app loads it'll tweak your titlebar to put the useful info (unread message count) in there over to the left and move the useless information (your own name) over to the right.  Much better.  It'll also redo the same check every 15 seconds, so your title bar stays up to date while the window is minimized.  YAY!

Is this the most elegant solution to this problem?  No. Is it even an elegant solution?  Probably not.  Does it work and remain unintrusive?  Absolutely.  If you want to help with the first consideration, drop me a line.  In particular, some sort of event-driven approach would be far better so you don't have to wait for the 15 seconds to elapse before changes are reflected in the title bar.  If you're like me, you probably don't care enough to dig into it to that level, but if you have the time/knowledge/desire, please drop me a line.

The basic idea is that your HTML includes a reference to "agg_standard.js", which is an alias for whatever JS files you need for your standard user (as opposed to a mobile user, for example).  That request comes to your server and if the file exists, gets served back like any other JS file.  If it doesn't exist, however, mod_rewrite will forward it to a CFM page to generate it:

RewriteCond     %{REQUEST_FILENAME}     !-s
RewriteRule     (/my_app)/static/(agg_.*)\.js$ $1/aggregator.cfm?name=$2.js

In our example, the request passed to aggregator.cfm would have "agg_standard.js" as the 'name' attribute, which is how we'll figure out what we need to aggregate together:

switch (url.name) {
case "agg_standard.js":
  files = [
    "jquery/jquery" & (request.isProduction ? ".min" : ""),
    "jquery/jquery.ui" & (request.isProduction ? ".min" : ""),
    "yui/yahoo-min",
    "yui/event-min",
    "yui/history-min",
    "util",
    "jscalendar/calendar",
    "jscalendar/lang/calendar-en",
    "jscalendar/calendar-setup",
    "dracula/raphael-min",
    "dracula/graffle",
    "dracula/graph"
  ];
  break;
case "agg_iphone.js":
  files = [
    "jquery/jquery" & (request.isProduction ? ".min" : ""),
    "yui/yahoo-min",
    "yui/event-min",
    "yui/history-min",
    "util"
  ];
  break;
}

The important bits, of course, is the Groovy script that actually does the aggregation and compression.  It uses YUI Compressor, so you'll need to have the yiucompressor-x.y.z.jar file on your classpath (probably in /WEB-INF/lib).  Here it is:

import com.yahoo.platform.yui.compressor.*

sw = new StringWriter()
variables.files.each {
  def f = new File(variables.STATIC_DIR + it + '.js')
  sw.append('/* ').append(f.name).append(' */\n')
  if (! it.endsWith(".min") && ! it.endsWith("-min")) {
    def compressor = new JavaScriptCompressor(f.newReader(), null)
    compressor.compress(sw, -1, false, false, false, false)
  } else {
    sw.append(f.text.trim())
  }
  sw.append('\n')
}
variables.buffer = sw.toString()

Pretty straightforward: it just loops over the files, using a StringWriter to build up the aggregated buffer.  Each file is either compressed into the Writer or simply appended based on whether the file has already been minified (based on ".min" or "-min" in the filename).  Each file also gets a comment label in the Writer above it's contents so that the aggregated file is a little easier to parse (at the expense of a few extra bytes).  Once done, the Writer's contents are stored in the 'buffer' variable caching on the filesystem:

<cfset fileWrite(STATIC_DIR & url.name, buffer) />
<cflocation url="#url.name#" addtoken="false" />

You'll notice that I'm not streaming the buffer back out to the user, but instead 302-ing back to the same URL.  This is important.  The reason is that Apache does a whole bunch of stuff to optimize static assets, and if I serve the content back with CFCONTENT, I'll miss out on all of that.  Yes, the 302 has a little bit of overhead on the initial page load, but it reduces the total transfer size by several hundred KB (because of the GZIPping), and avoids a rerequest on the next page load (because of the cache headers).  So it's completely worth it, the moreso because this is an application likely to generate extended usage rather than a content-centric site that is likely to see single-page "bounce" visits from search engines.

The last piece of the puzzle is handling versioning of your assets.  When you change your JS file, you necessarily have to invalidate your cache (by deleting the files) so the aggregated version can be rebuilt with the new JS.  The easiest way to do that is to use psuedo-versioning of your assets.  You'll see a lot of sites will add a timestamp or a version number to their files (e.g., "arc/yui/reset_2.6.5.css" from Yahoo.com) so that when the update the file it gets a new filename, and is therefore redownloaded by everyone (because it doesn't exist in their cache).  That's great, but it means you have to rename your files all the time which is kind of a pain.  But you can fake it:

<cfset STATIC_ASSET_VERSION = 15 />
<script type="text/javascript" src="static/agg_standard_#STATIC_ASSET_VERSION#.js"></script>

That'll generate a request to "agg_standard_15.js", as you might imagine, which isn't going to work so well.  But we can just change the 'switch' line from the first snippet to this:

switch (REReplace(url.name, "^(agg_.*?)(_[0-9]+)?\.js$", "\1.js")) {

Now it'll strip out that "fake" number string and switch on just "agg_standard.js", which is what we want.  But that 'fileWrite' call later will still use the full filename (with the number embedded).  That way subsequents will get the filesystem cacheing, the headers and GZIPping from Apache, and all the other love.  And when you rev your files, you need only increment the STATIC_ASSET_VERSION variable and you'll have a brand new set of virtual URLs for all your assets, no fuss, no muss.

Oh, and just in case you're wondering, the aggregation and compression is fast.  If you've ever used the command line or Ant task, you might fear that it's slow, but most of the time you see there is from the JVM spinning up, not the actual compression.  Since this is all in-JVM, you don't pay any of that cost.  It's certainly not fast enough to have it run in production on every request (hence the file caching), but it's totally reasonable to do on your production box as part of deploying a new version of the app.  It's also probably fast enough to have running every request on your internal test/staging boxes, though that'll depend on how much you're aggregating/compressing among other things.

If your CFML engine does not provide a location function, FB3Lite will ensure one is available for you (simply wrapping CFLOCATION).  This has been the behaviour since the beginning.  Now, if your CFML engine does provide a location function, FB3Lite will still provide one in the variables scope (in case you're doing dynamic evaluation of it), but the engine-provided one will be used for static references (the typical case).

In general, this shouldn't matter to anyone; it's still just download and go.  The issue I alluded to above has to do with the optional parameters that CF9 provides (addToken and statusCode).  Since static invocations will use the built-in function, those optional params will be available on CF9, but will not on platforms that rely on FB3Lite's version.  Eventually I'd expect all CFML engines to provide a location function in which case there will no longer be a discrepancy, but for the meantime, if you're using multiple platforms, you'll need to ensure you're not using the optional parameters with the location function.

And before you say it, adding the parameters to the FB3Lite-provided function isn't an option, because CFLOCATION doesn't support statusCode until ColdFusion 8, which means you'd get compiler errors on CF7.

As always, the source is available, or you can check the project page for the latest info and updates.

<cfset appSearchPath = "../../../myApp" />
<cfinclude template="../com/barneyb/fb3lite/index.cfm" />

But now with mappings, you can simplify things, even if you're just using the webroot:

<cfset appSearchPath = "/myApp" />
<cfinclude template="/com/barneyb/fb3lite/index.cfm" />

This is exactly the same functionality I added to do/include.  The difference is that the top-level fuseaction is invoked via an internal call to do() which is based on appSearchPath instead of a circuit prefix.  But now both are equivalent again.

As always, source is available, along with the project page with current information and downloads.

The new feature is the ability to dereference directories with webroot/mapping relative paths (e.g., /mapping/dir/file.cfm).  Until now, only relative paths (to the current circuit) were allowed, as they were always prefixed with the current circuit's path.  But now if you start a do/include path with a slash, it'll be assumed a webroot/mapping relative path and be used as-is.

As you'd expect, there is a corresponding 'allowMappedCircuits' settings variable that can be used to disable this behaviour if your application requires the old-style behaviour (of leading slashes being ignored).

The newest version is available here, or look to the project page for links to the demo app, a history of revisions, and any new info that might come up.

I needed this sort of functionality in CFML, so after playing with a few different syntaxes and parsers for them, I decided that a direct port of the WordPress shortcodes implementation was the best choice.  The code is pretty small (the grammar is context free and the parser is RegEx-based), and the port (including unit tests) took perhaps an hour and a half.  I had to roll my own REReplaceCallback UDF to match one of the PHP builtins, as well as change the callback API slightly to deal with CFML idoms, but it's a pretty direct port.

So what can you do with shortcodes?  Here's a little demo, both of the front side (the content) and the backside (the handlers and processing).  There is also a link to the source, of course.  And like all my projects, there is a project page where current project information will always be available.

The key to all of this is the Expires header: you want to set an expiration way in future so the client (the browser) will cache the asset forever.  With Apache it's really simple:

LoadModule expires_module modules/mod_expires.so
ExpiresByType   application/x-javascript    "now plus 10 year"

That tells Apache to set an expiration on all JS files that is 10 years in the future.  In web time, that's pretty much forever.  Really simple, really effective.  You also want to use mod_headers to set Cache-Control and Pragma headers and remove the ETag and Last-Modified headers, as well as ensure we don't use file ETags:

LoadModule headers_module modules/mod_headers.so
Header  set     Cache-Control    "public"
Header  set     Pragma           ""
Header  unset   Last-Modified
Header  unset   ETag
FileETag        None

The problem is that if you ever change one of those JS files, clients who already have the old version will never know about it.  The solution is to never modify files, only create and delete files.  So if you have 'script.js' and you need to make an update, instead of pushing a new version of that file, you'd instead push 'script_2.js' (or whatever).  That way you're guaranteed that every client will download it afresh (with the long Expires header) because no one has ever seen the file before.  Next time you need to make changes, you'd push 'script_3.js'.

This quickly becomes a bit of a problem, because not only do you have to change the filename, you have to change all the references to the filename as well.  So a little JS tweak suddenly becomes a change to all your SCRIPT tags and republishing all your content.  Not too fun.  This is the problem I can help solve, and it'll be using our friend mod_rewrite (of course!).

Check this innocuous little condition/rule:

RewriteCond    %{REQUEST_FILENAME}    !-s
RewriteRule    (.*)_[0-9]+\.(js|css)$    $1.$2

That says any time you find a JS file that ends with an underscore followed by one or more digits, if it doesn't exist, remove the underscore and digits.  I.e. when 'script_2.js' gets requested, if that file doesn't exist, just serve back 'script.js' instead.  Now that's handy, because now we can use an arbitrary version number and they all hit the same file.  This is not a perfect solution, but it is ideal for the vast majority of cases, since you can just modify 'script.js' in place without a care in the world, and then reference your incrementing scripts to ensure cache refreshes.  Because HTTP caching operates on HTTP URIs, the fact that requests for 'script.js' and 'script_2.js' both hit the same file on disk is irrelevant; they're separate URIs, so they'll be cached separately.

That's not a solution in and of itself, however, because we still have to update all the SCRIPT tags to use a new filename (even though it'll end up hitting the same file on disk).  But now that the URI is divorced from the file itself, we don't have to keep anything in sync.

The last piece is to set up a global variable to use in your script suffixes:

<cfset application.scriptVersion = 2 />
...
<script type="text/javascript" src="/path/to/script_#application.scriptVersion#.js"></script>

Then any time you increment that scriptVersion variable, all your JS will suddenly become uncached and everyone will refresh.  So you can just hack away on script.js until you're happy, bump the variable up, and you're done.  No new files, no changing SCRIPT tags, super simple.