chris clarke

GNUs Not U 2

Kill a command by name:

ps axc | grep httpd | awk '{ print $1; }' | xargs kill

Look for a command exclude your own grep:

ps auxwww | grep command | grep -v grep

Kill a command based on it’s arguments:

ps axwww | grep port=8889 | grep -v grep | awk '{ print $1; }' | xargs kill

Can this be simplified?:

ps axc | awk '/httpd/{ print $1 }' | xargs kill

ps axwww | awk '/port=8889/{ print $1 }' | xargs kill

But when using the command above we are trying to kill our own awk command!

ps axwww | awk '/port=8889/ && !/awk/ { print $1 }' | xargs kill

GNUs Not U

Highlight some expression using colour:

grep --color expression file

Go to a dir, execute a command and return to the current directory:

(cd dir && command)

A stopwatch:

time cat ^D

Download a url at 1 AM:

echo 'wget url' | at 01:00

Do some sums:

echo "monkeys=24; monkeys * 6 / 4" | bc

Convert a string to lowercase:

echo 'TeSt' | tr '[:upper:]' '[:lower:]'

List files that a process has open:

lsof -p 483

List processes that have the specified path open:

lsof ~

Display a webpage (MAC/BSD):

wget -qO - http://www.cheese.com > tmp.html && textutil -stdout -convert txt tmp.html

Look for a word case insensitively:

cat Names | grep -i demarco

Search and replace:

cat index.html | sed 's/Google/MSN/g'

Print lines 10 to 20:

cat index.html | sed -n '10,20p;20q'

Time how long it takes to calculate PI to 5000 decimal places:

time echo "scale=5000; 4*a(1)" | bc -l

Convert binary to decimal:

echo "obase=10; ibase=2; 01111111" | bc

Perform a calculation on some output:

ls -al *.html | awk '{sum+=$5} END{print sum}'

Fix typos in files but backup the original files:

perl -p -i.old -e 's/oldstring/newstring/g' *.txt

Execute a command on several computers:

perl -e 'for("B","C","D"){`scp command.pl $_:`; `ssh $_ command.pl`; }'

Look for a regular expression:

cat index.html | perl -ne 'print if /font-size:\s*\d+px/'

Print selected lines of a file:

cat buildOutput.txt | perl -ne 'print if 1..2'

Can you think of another way to print selected lines?

Comma-delimit:

ls -l | perl -wne 'BEGIN{$" = ","} @fields = split/\s+/; print "@fields\n";'

Find a file without the “permission denied” messages:

find . -name 'monkeys.txt' 2> /dev/null

Unit Tests In Javascript

Looking around for AJAX libraries to use for storyboard following a retrospective around the initial development, I stumbled across scriptaculous, one of the benefits being that it has it’s own unit test library.
An alternative may be to use jsUnit which has syntax much more familiar to anyone who’s ever used JUnit.

After I wrote the storyboard retrospective, I happened across Joe Walnes blog where I found Building testable AJAX apps (Does my button look big in this?). It was nice to see someone had a similar thoughts to myself as to why you would approach a Javascript project differently than you would any normal project; quoting Joe:
“What’s a bit annoying is that we know all this stuff already. And certainly we do this in any other type of GUI development, but when I came to first doing ajax I thought ‘oh. it’s just javascript, don’t really take it seriously, just wire up a little event in the html’ and it’s almost like we’ve regressed back to the VB days when you built a whole GUI by saying ‘Right, first I’m going to draw a button, then I’m going to put an onclick to the button then I’m going to write 10,000 lines of code on the onclick.’”

There were several other interesting things in Adam and Joes talk. They chose not to use Google Web Toolkit despite working for Google and in fact they did not appear to use any AJAX or Javascript libraries/frameworks apart from JsUnit. The best idea they had was to take a great approach to the application borrowing from ideas that you would use when developing a traditional GUI application (including Michael Feathers’ The Humble Dialog Box). They used a kind of Model View Controller to make the app more testable. In fact they were able to test some code in the controller without requiring a browser using Rhino Engine. The way they tested the view was most interesting: they did it manually - well almost - they had written a small bit of helper code that made all UI functions available to play around with in a sidebar. The sidebar also showed any Javascript events that had been fired (see image).

This seemed like a really logical way to test the UI controls and view of a GUI because often the only way to test usability is to use something. Also, making assertions on pixel widths and things just seems silly and static screen grabs are’nt the same thing as actualling using the app - so why not manually test it - especially nice if you can get some real users.

After speaking to someone in the pub about AJAX development, I was pointed towards two very useful looking tools. Prototype is a JavaScript Framework which provides some useful libraries and also some really useful extensions to the standard DOM. For example, using the extensions you can do cool stuff like this found at Sergio Pereiras site:

The $() operator is just a shortcut for document.getElementById(), and the $A() operator converts an element to an array, you can see how this function works based on the html below:

<select id="lstEmployees" size="10">
    <option value="5">Buchanan, Steven</option>
    <option value="8">Callahan, Laura</option>
    <option value="1">Davolio, Nancy</option>
</select>

The other useful tool is Crosscheck which is a cross-browser testing framework which doesn’t actually require any browsers. This seems like a very useful solution for cross-browser compatibility testing of storyboard.

Retrospective: Storyboard

In order to come up with some working practices for Storyboard 2 - I’m going to hold a quick retrospective of Storyboard 1 right here - a Blog-o-spective.

What went well?

• Easy to use
• Fun look and feel
• Easy to deploy
• Quick initial development
• Introduction of XML

What did we learn?

• Ajax apps are hard to test
• Having output not being logged or logged to different places is bad
• Integration tests between python and javascript are hard to write
• Tests between front and back-end are definitely needed
• Development is easiest when tests are easy to write and can drive features
• Too much client-side processing in javascript slows things down (duh?)
• Writing ajax stuff without a library is very fragile
• There’s plenty of libraries/frameworks for both Ajax and DHTML stuff.
• Storyboard without a zoom feature or different views is not useful because you can’t see all the cards easily.
• Building cross-browser compatibility from the start would have been much easier
• In fact a lot of things could have been much easier if they had been done from the start especially logging & integration tests

What should we do differently next time?

• Need a framework/way of writing tests quickly and easily e.g. Google Web Toolkit
• Make more use of ready-made libraries e.g. YUI
• Maybe use something other than python for back-end
• Have better test coverage - back, front and integration
• Prioritize features e.g. zoom feature should be high prioirity
• Have an agreed set of practices/prejudices from the start e.g. Log to one file

What still puzzles us?

• Why I did things differently than I would have done in a pure Java project e.g. no TDD from start
• Why CGI and Ajax stuff can just go wrong but not tell you why
• Why there aren’t more standard or popular libraries for JavaScript

Some Storyboard Working Practices

1. Progress will be measured in running tested features. Features will be documented via the test code. The progress will be displayed on a infinite burn-up chart.
2. All ideas & feature suggestions will be recorded and prioritized in a backlog.
3. No code shall be written without first searching for some code which does what is needed easily.
4. Any relevant output, logging or debugging information will be appended to one file: The Log.
5. Test driven development.
6. For a piece of code to be considered done done it will be Tested, Refactored & Integrated. (Refactored practices: No methods > 10 lines. No classes that break the scrolling rule (~40 lines in Eclipse).)

Iterations from Outer Space

“Smaller, more frequent steps drive a faster rate of learning, help us maintain focus, and give each of us an opportunity to see our latest work fly sooner.”, Jeff Bezos, owner of space travel company Blue Origin.

Storyboard Freeze

I’ve frozen storyboard development and no new features will be added to the old version.

I leave it in an unknown state and am currently rewriting it as you can see from my storyboard:

It shall hopefully emerge cross-browser compatible, with some of Walter Zorn’s fantastic looking DHTML libraries, lovely Enterprisey Xml, user-driven features and a bucketful of ultra-cool stuff. As my old nan used to say: you can’t beat a bit of pomopro.

Build-o-matic plugin screens

Latest screens from build-o-matic plugin for intellij:

Logging in:

After logging in:

(The black box saying ‘quick-cruise’ is the build-o-matic build being monitored : it goes red for last build failed, green for success and black if it can’t find the build-o-matic server (this is because I didn’t have a build-o-matic running when i took these screenshots))

(The two tiny icons are the pictures of the people who are currently logged in (me and no-one))

After I break the build:

A picture of our builds (Uh-oh - looks like the e2e build has crashed and the branch build is broken!):

Where can I get this plugin?

Coming soon - currently integrating with main build-o-matic source.

Is there an eclipse version?

Yes - but it’s no where near as good - only has the status bars.

Comments and feature-suggestions welcome