Because sometimes I want to give my terminal tabs some sort of context indicator:

Stick that in .profile and there’s no more need to scan the output for clues as to what that terminal tab is responsible for.

1. “Right Click” the Frameworks group, select Add -> Existing Frameworks. Select the target framework, click Add.
2. “Right Click” the target in the Targets group and select Add -> New Build Phase -> New Copy Files Build Phase. Choose Destination: Frameworks and close window.
3. Drag the framework added in step one into the Copy Files build phase created in step two.

appengine-web.xml:

web.xml:

dispatcher-servlet.xml:

sitemesh.xml:

There have been a few times when it was helpful for me know the name of the currently running JUnit test method. In one particular case I was using a method in the test class to perform a series of routine assertions along with some debug level logging but the logging tools would only go so far as to print the name of this helper method, not the name of the test being executed.

Since JUnit 4.7 there has been some support for retrieving information about the current test using the @Rule annotation and the TestName class. Use it like so:

Note: The TestName variable must be public or you’ll get an initialization error. This is due to the restrictions on fields annotated with @Rule which, according to the JUnit documentation, must be public, not static, and a subtype of MethodRule.

Recently, after hours of life-threatening frustration and anger, I discovered a little-publicized limitation of Internet Explorer: you can only have 31 stylesheets.

Whether they be included via <link> tags or as separate <style> blocks, 31 is the maximum number of distinct style sections Internet Explorer will recognize; everything appearing afterwards is indiscriminately ignored.

Under normal circumstances this shouldn’t be an issue but at my job we use a CSS / Javascript packaging utility and organize the styles into smaller, more manageable files. In debug mode, the individual stylesheets and script files are included to facilitate error tracking and, consequently, to elicit all of IE’s inadequacies.

Here’s a little page I made to test my theory that the stylesheets were being limited:

Here’s what it should look like in a competent browser (left) and in IE (right):

This issue is nothing new, it goes back years but is something one typically encounters without warning, resulting in the unrecoverable loss of many hours that could have otherwise been spent on some productive endeavor.

To read more about this atrocity, visit Microsoft’s official documentation for the tech writing equivalent of smug shoulder shrug.

The NSTask class allows developers to run another program from within a Cocoa Application and monitor its execution without sharing memory space. By nature it is asynchronous but there are times when you may wish to run the task and halt the execution of your current application until the subprocess has finished. One example would be during the saving of a file.

When using the save file hooks provided by Cocoa, you write a file to a temporary location and return a boolean indicating the success of the write operation which tells the framework to move the file to its target location. If your write operation relies on the execution of an external program, a shell script for instance, then you will want to wait for the execution to complete before indicating the success of the write to the caller.

One way to accomplish this synchronous execution is to set up an NSPipe, a one-way communications channel between processes; one process writes data, the other reads it. Set the standard out and standard error of the NSTask to the pipe and, after launching the task, read from the pipe until the process ends.

This will allow you to both run the task synchronously and return the output to the caller for analysis.

YUI Compressor is a popular tool that allows web developers to easily and reliably minify / munge Javascript and CSS files. The one common complaint amongst users is that it doesn’t allow you to combine files into a consolidated package prior to minification. As I discussed a while back, JAWR takes care of this automatically for Java based web apps but automated solutions aren’t very efficient for small, script-based web apps. Hence, I wrote a small shell script that will combined a list of files into one and then run them through the yuicompressor.

Now, before you run the script, you either need to move the yuicompressor.jar to /usr/share/yui/yuicompressor.jar or just edit the first line of the script to point to the location of your yuicompressor jar file.

yuicompress.sh

# yuicompress
#
# combine files and then compress the result with yuicompressor
# note: yuicompressor jar must be at /usr/share/yui/yuicompressor.jar
#
# usage: yuicompress [-o outfile] [-t type] args

# check for yui compressor -----------------------------------------------------
yuipath="/usr/share/yui/yuicompressor.jar"
if ! test -f $yuipath
then
        echo "cannot find $yuipath"
        exit
fi

# get options ------------------------------------------------------------------
ofile="compressed.txt"
type="js"
preserveLicense=false
while getopts 'o:t:' OPTION
do
        case $OPTION in
        o)      ofile="$OPTARG"
                ;;
        t)      type="$OPTARG"
                ;;
        ?)      printf "Usage: %s: [-o outfile] [-t type] args\n" $(basename $0) >&2
                exit 2
                ;;
        esac
done
shift $(($OPTIND - 1))

# get files --------------------------------------------------------------------
if (( $# < 1 ))
then
        echo "no files specified"
        exit
fi
files=$*

# combine files ----------------------------------------------------------------
cat $files > $ofile

# compress results -------------------------------------------------------------
java -jar $yuipath --type $type -o $ofile $ofile

The usage is illustrated in the script itself but here are a few examples just to get you started:

./yuicompress -o lib.js lib/js/*.js
./yuicompress -o all.css -t css css/*.css
./yuicompress -o some.css -t css css/main.css css/misc.css

Downloaded the latest version of Maven and don’t know what to do with all of those files? Run this shell script (with sudo for the appropriate privileges) on the directory containing all of the maven files (usually called apache-maven-[version#]):

mvnupdate.sh

#check for directory argument --------------------------------------------------
if [ $# -lt 1 ]
then
        echo "no directory name specified"
        exit
fi
#check directory exists --------------------------------------------------------
if ! test -d $1
then
        echo "$1 is not a directory"
        exit
fi
#move previous version ---------------------------------------------------------
MVN="/usr/share/maven"
oldMVN=$MVN`date +"%Y%m%d%H%M%S"`
if test -d $MVN
then
        sudo mv $MVN $oldMVN
fi
#move new version --------------------------------------------------------------
sudo cp -r $1 $MVN

You know those ugly outlines that Firefox puts around links and buttons when you click on them? Yeah, I don’t get it either. From a developer’s standpoint, IE is by far the worst browser to support but Firefox also has its share of baffling behaviors and deviations from the standards.

So, how do you remove those ugly outlines from your site? Add this to your style sheet and it should do the trick.

*, *:hover, *:active, *:link { outline: none; }

It might be overkill but it takes care of most situations involving links. Unfortunately there’s no easy way to get rid of the outlines around buttons that are styled with images but this at least minimizes the number of visual abominations.

Recently I gave a presentation to colleagues on Jawr and the general merits of Javascript/CSS minification. Most of the material was pilfered from the official Jawr site but it may be easier to digest for those of us with shorter attention spans.

So, first an introduction:

Jawr

“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.”

And why should we care about any of this? Before answering this question, let's step back for a moment and discuss an important concept in web application development:

Minification

Minification (n), also called minimization, or minimisation (for those who speake the Queen's English): the process of removing all unnecessary characters from code without altering its functionality. This typically includes all non-critical whitespace and newlines that are not included in string literals and most comments.

Verb form: minify.

Why minify (and bundle)?

• Improves load times for the client

• Less data being transmitted by the server

How?

• Minification reduces the size of HTTP responses.

Why should we be sending unnecessary data? The spaces, tabs, and newlines are valuable only in development so we should keep them to ourselves.

• Bundling reduces the number of HTTP requests.

The HTTP protocol is fairly inefficient when it comes to retrieving lots of files. First a TCP connection must be established. This requires a three-way handshake. The client sends a connection request, the server responds, and then the client acknowledges the response.

Now the client sends the HTTP request itself. HTTP, Hypertext Transfer Protocol, is, as the name indicates, a text based protocol with all information being sent as human readable text. This means that the speed, small size, and efficiency of a rigid bit and byte based based protocol are sacrificed in favor of versatility and comprehensibility.

I'm not going to get into the details of the TCP/IP stack and talk about maximum transmission units or fragmentation but, for those of you unfamiliar with the specifics, I'll just stress that there's even more overhead in the transmission of these bloated requests and responses in addition to the initial handshake and large, text -based headers.

The response, with a larger set of headers, comes back from the server and, if this is an HTML document, the client begins sending requests for the other documents referenced therein. This includes scripts, style sheets, and pictures. All browsers have a limit on the number of concurrent connections allowed to a single domain per page and for a while this was a whopping 2 (this is still effectively the case for IE). Additionally, unless the Keep Alive flag is set, each request requires a new TCP connection to be negotiated.

Multiple script files, which halt the execution of the page due to the assumed requirement that they be loaded and executed in order, will make initial page load times uncomfortably long unless the files are cached. Therefore, reducing the number of files that need to be downloaded means fewer HTTP requests resulting in faster load times.

And why should we care about load times?

• Web applications and the culture of instant gratification

If we, as web application developers, truly want to compete with desktop applications then we strive to match their responsiveness. This is why the whole AJAX paradigm has become such a phenomenon (and poorly misused buzzword) over these past four years. When we perform an action within the context of a web page, we don't want to wait ages while the screen reloads. Even in cases where a full page transition is necessary, slow load times can mean the death of a project where alternatives are available.

• Mobile browsers

My iPhone is faster and has more storage space than the iMac I bought back in 1999 and a much better downstream than the 56K modem bundled within. It weighs as much as my wallet and enables me to check my email from places where laptops are socially forbidden. Mobile browsing is becoming ever more prevalent and it would be a serious mistake on the part of any web application developer to neglect making optimizations for their sake.

• Some people still use dial-up

…and some people still use AOL… and a lot of people still use IE. Strange, I know, particularly the last point, but whatever the reason for the circumstances may be, they may not have a choice but we certainly do have the choice to optimize.

So why don't we just use one big script file and one big style file?

• Development is much more efficient when using multiple, logically separated files and good organization is integral to good programming.

Editing or debugging large script files is a nightmare. Editing or debugging large, minified script files is impossible.

• Some components need to be included on every page whereas other components or groups of components need to be included in particular sections of the site.

Optimization doesn't mean simply getting rid of meaningless text, it also means excluding useless code. If I have an admin section of a site and a client section of a site, there is no need whatsoever for scripts specific to the admin to be sent to the client and vice-versa. In the case of styles, there could be CSS conflicts between these two sections so we certainly wouldn't want to bundle section specific stylesheets together.

Other options

• YUI compressor (no grouping) (http://developer.yahoo.com/yui/compressor/) Java app, minify and compress.
• Minify (PHP) http://code.google.com/p/minify/

Jawr

• Minifies
• Munges
• Bundles
• Compresses
• Enforces Caching
• Does all this on demand
• Has debug and production modes
• Built in JSP tag library for including the scripts and styles

Additionally

• Free and open source
• Easy to set up
• Easy to configure
• Plays nice with others (Spring MVC, JSF/Facelets, Grails, pure HTML)

Setup (web.xml)

Setup (jawr.properties)

Setup (JSP)

Result (debug)

Result (production)

File Sizes

	 16532 autocomplete.js
	  1176 binder.js
	   367 console-noop.js
	  1617 effects-ext.js
	 38986 effects.js
	  1543 form-highlighter.js
	 11809 global.js
	   822 modalbox-ext.js
	 22778 modalbox.js
	  2625 prototype-ext.js
	124000 prototype.js

	All files
		244 KB

	core.js (minified and bundled)
		156 KB

	core.js (minified, bundled, and gzipped)
		40 KB

Load times (in debug mode)

Load times (in production mode)

Load times (with caching)