Posted by: rpstulk | July 14, 2011

On My Way to Work

Found this in the parking lot outside of my building this morning

Posted by: rpstulk | August 11, 2010

Ideas for a Maritime Safety Course

A tweet by @gvwilson about what a real drowning victim looks like directed me to the article regarding heavy weather and rescue to be very interesting.  One excerpt that stuck with me was Mario’s take on one’s options while fighting a storm, to turn and run with the storm, or drop a sea anchor and ride it out:

… I should probably admit my bias here: I search for boats more than I sail them.  I’m not usually even on a boat unless it’s sinking, on fire, or upside down … What I can tell you from experience is that I have never had to rescue someone that was hove-to with a para-anchor, or pulling a drogue.  Like my state trooper friend who often quips, “I’ve never unbuckled a dead man”, I’m a big fan of what (apparently) works.

Now, I’m by no means an experienced heavy weather sailor, anything over 20 knots of breeze is very thrilling to me, so when I read this I thought, “My god, what is a para-anchor and how do I use one?”  A half hour of googling later, I found out what a para-anchor was, the varieties of sea anchor available, where to buy them, and a collection of youtube videos demonstrating how to set and retrieve one from various  types of boats.

This all got me thinking about other safety techniques that I would like to learn more about.  I’ve compiled the following list of things I’d like to try, or would like to see in a marine safety course.  The club I’m at now, Harborfront Centre Sailing and Powerboat Club, doesn’t have a dedicated safety course that goes into the amount of detail I’m proposing with this list.  Perhaps it is something that myself and the other members could organize.  Please review the list below and give me your feedback, it is very much appreciated.  If the idea gains traction, maybe we’ll dedicate a night a week during the fall to try some of this out.  Let’s get the man-overboard out of the way while the water is still warm!

Boat Safety

  • Equipment:
    • Flares
    • Crew Overboard Pole
    • Life ring
    • Recharge lifejacket
    • EPIRB
    • Fire Extinguishers
  • Dealing with a leak
  • Setting anchor under power and sail
  • Using the Jib as a sling
  • Bailing
  • Engine failure
  • Patching a sail
  • Steering using lead lines
  • Sea Anchors and Drogues
  • Setting and Sailing on Storm Sails

Human Safety

  • Man overboard, with a real man
  • Drowning/lifeguard
  • First aid
    • CPR
    • Stitching a wound
    • Sea Sickness
    • Heat stroke
    • Sunburn
    • Hypothermia
    • Broken Fingers and Toes
    • Concussion

I’ve indicated in bold those topics which I’d consider crucial, or at least that live in the intersection of important, could save your life and not exercised in a course I’ve taken.  I think that if this were something the members or administration of Harborfront Sailing could put together, it would be a great asset for the club, and we’d all be a lot safer.

Posted by: rpstulk | July 27, 2010

GWT Library Modules

After an internet search that took way too long, I came up with the following list of GWT modules that make up the GWT SDK 1.7

  • com.google.gwt.animation.Animation
  • com.google.gwt.benchmarks.Benchmarks
  • com.google.gwt.core.CompilerParameters
  • com.google.gwt.core.Core
  • com.google.gwt.debug.Debug
  • com.google.gwt.dom.DOM
  • com.google.gwt.emulation.Emulation
  • com.google.gwt.emulation.EmulationWithUserAgent
  • com.google.gwt.event.Event
  • com.google.gwt.event.EventBase
  • com.google.gwt.http.HTTP
  • com.google.gwt.il18n.IL18N
  • com.google.gwt.json.JSON
  • com.google.gwt.junit.JUnit
  • com.google.gwt.user.User – this one contains many others that have been omitted for brevity
  • com.google.com.gwt.user.theme.standard.Standard
  • com.google.com.gwt.user.theme.chrome.Chrome
  • com.google.com.gwt.user.theme.dark.Dark
  • com.google.com.gwt.xml.XML

In general, any classes which are in the package or sub-packages of the given module are accessed by your application by adding an <inherit name=”module”/> to your module descriptor (YourApp.gwt.xml).

The naming conventions used by Google here make managing your app’s libraries pretty simple, assuming you know this is how things are organized. Otherwise, good luck finding a ‘include this module to get this class’ lookup table anywhere in the GWT documentation.

I’m sure that someone has compiled a list like this already, and that I was unable to find it.  Maybe that someone will comment with a link …

Posted by: rpstulk | May 5, 2010

Unit Test History and Import/Export in Eclipse

Having spent several weeks working with a suite of integration tests that take an extremely long time to complete, few things can be as annoying as the following scenario:

  • Run a suite of tests, some of them fail
  • Double-click the failed test, to inspect the code
  • Modify the code in that test, rerun just that test
  • Test passes, now I want to go on to the next failing test, but oohhh, your list of failed tests are gone

I’d classify this as an Eclipse UI design failure, but there are several solutions to this sticky situation. The most nieve is to simply rerun all the tests, but I really don’t want to do that. The next best option is to, before digging into the failures, to copy the JUnit console output and stack traces into a text editor. Either manually or through some creative regular expressions, you can be left with just a list of the ClassName.MethodNames of the failing tests.



The proper solution is to use the JUnit tab’s Test History menu to rerun or simply view old test runs.

The test history drop-down gives you the option to rerun the last 10 or so tests, but that’s not really what we want. If you explore the History dialog from this menu, you will have access to the results from previous JUnit test executions (default is configured to store the last 99 test runs).


This is great, but keep in mind that it is cleared every time eclipse shuts down. To address this, there is a handy XML Import/Export feature that allows you to your Test History to an XML file, and load that XML file back again at a later time. So, run your expensive test, and before hacking away at all those broken tests you could have sworn you fixed, export your test results for handy lookup!

Posted by: rpstulk | April 28, 2010

Ordering Your Conditional Expressions for Runtime Saftey

Ordering of clauses in conditional expressions is not a new trick; I believe I first read of using a nonstandard (ie. not variable == value) in my first pass through Code Complete when the author suggest you use the following:

if (value == variable)

The motivation here was to catch problems resulting from typing a single = instead of ==.  In C, if(expression = value) is a valid piece of code, as the assignment returns a void, however this probably isn’t what you want to be doing.  By switching the order of the assigned variable and value, the compiler will bark if you’ve forgotten one of your equal signs (assuming the value is a literal or expression, not just another variable name).

This issue has arisen recently in a technique employed on my team when doing object to constant comparisons in Java.  Take the following statement:

if (outer().inner().equals(CONST))

This is pretty standard, but has the possibility of throwing a NullPointerException if outer() or inner() return null.  The technique used is to refactor to this:

if (CONST.equals(outer().inner()))

This pattern will avoid at least one of the possible NullPointerExcepions – if inner() returns null, then we have CONST.equals(null), which evaluates to false instead of blowing up.  This can be viewed as a shortcut for the following:


if (outer().inner()!=null)
if (outer().inner().equals(CONST)

The two are pretty much equivalent, if you are expecting the possibility that inner() could be null.  If this isn’t a known possibility, it seems to me that the first option would silently consume the null, and might hide a potential bug that could be found earlier if this clause tossed an NPE.  Maybe I’m being paranoid or focusing too much on process. It could be that this is a standard Java practice, and I’ve just been living under a rock for too long. Either way, I’d appreciate feedback from the community.

Posted by: rpstulk | February 26, 2010

Writing with LaTeX and SVN

One of the best tricks I picked up during my master’s degree was writing/typesetting documents with LaTeX. As a Linux user, I was approaching my wit’s end looking for a decent word processing/office package. Open Office works, in principle, but is too buggy and bloated to be enjoyable to use. Everything else I’d seen was either feature starved or suffered from dramatic incompatibility issues. “Does the whole world just use Microsoft Office?” I found myself asking.

Anyway, enter LaTeX, a typesetting program that has been around for ages. LaTeX consists of a markup language and a compiler – you write your document in the markup, using any text editor you choose, and then compile it into one of many presentation formats, including DVI, PostScript, and PDF. Additionally, a hoard of devoted followers from around the globe have been contributing to the language in the form of a monstrous repository of plugins, templates, and tools, most of which are freely available.

When writing a LaTeX document, I personally find that the same neurons are firing as when writing code, and since I enjoy writing code, I also enjoy writing LaTeX documents.  This bit of mental stimulation, combined with outstanding support for complex mathematical formula creation, probably explains why TeX is so popular among academics.  The technical challenge of writing in LaTeX appeals to our particular neuroses.  Be warned though, LaTeX isn’t for the faint of heart.  You will spend time debugging your document.  You will run into problems with missing packages.  The first time you decide to change fonts, it may take you some time.  This is not a Microsoft Office work-alike.

One great aspect of writing your documents in plain ascii text is that it is easy to keep your LaTeX ‘source’ in a version control system, such as Subversion.  Starting an SVN repo on a remote server and using it to store your documents gives you powerful revision control (depending on how often you commit), and portability without having to be tied to an internet connection in the way Google Docs requires – you simply pull/push when you have the connection, then work on your client until the next pull/push.  Let us not overlook the collaboration possible when using a version control system, either.  Multiple users can edit the document simultaneously, and integrate their changes nearly automatically with the main branch of document development.

Anyway, I’ve been loving this recently, and thought I’d share it with the masses.

Posted by: rpstulk | February 26, 2010

Book Review: Overqualified by Joey Comeau

As I am currently undergoing the job-search process, I was given a copy of Overqualified by Joey Comeau as a gift. The book is a collection of cover letters written by Comeau when he was in a similar situation as myself.  Instead of the standard, cookie-cutter letters describing how me would be an asset to the target employer, Joey instead has created a collection of letters containing off-colour, often dark, humour and intimate personal details.  The letters purely hilarious in their absurdity, especially when one imagines the poor sap at General Electric/Goodyear/MIT who has the unfortunate task of reviewing his or her letter.

For the most part, many of the early items in this book are enjoyable little nonsenses, where the humour is derived primarily from the gross nonprofessional tone, the writer’s apparent incompetence, or vulgar content.  However, as the book progresses, the themes found become focused on some very intimate personal issues of the writer, including a fear of commitment, his relationship with his grandfather, and the loss of his brother; themes which occur in other of Comeau’s writings, so I assume them to be genuine.  While these letters can derive some of the same awkward enjoyment as the previous entries, they also share some insight on the author’s true self, making them somewhat profound.  Indeed, they can be seen almost as a plea for help, from someone who doesn’t quite know who to turn to, via the only means that a mind so twisted by a prolonged job search can remember: cover letters.

All in all, an entertaining light read.

Joey’s work can be seen at his webcomic A Softer World.

Posted by: rpstulk | February 7, 2010

Software Testing Techniques, an Empirical Approach

Proper software testing regimes are a cornerstone of effective software engineering. Progress has been made to teach students sound testing techniques, but improvement can still be made. My master’s research supervisor and I conducted a study designed to empirically determine the difference in ability between student and professional software testers, and elicit from the experts behaviours or techniques which may be used to enhance undergraduate curriculum.

Our experimental setup consisted of in-lab observational sessions where subjects wrote thorough suites of JUnit tests for sample software we’d created. Subjects were drawn from the University of Toronto’s undergraduate computer science student body and professional developers from the Greater Toronto Area. The test code and video logs created during these sessions were examined for trends present in the student and professional groups.

Our intuition going into the study was that professionals would find more defects with their test suites, an advantage stemming from some metric such as number of tests written, lines per test, code coverage per test, etc. Analysis of these metrics did not confirm these hypotheses, however. Students and professionals performed equally well in terms of number of bugs found. However, student code contained more defects and, more importantly, the types of bugs found differed strikingly between the two groups.

Bugs in the sample code were broken down into two categories: stateless and stateful. A stateless bug is uncovered by inputting invalid values into a method invocation, and the method returns invalid results or throws an exception. A stateful bug occurs when a method call corrupts the object’s state, and so subsequent calls perform incorrectly. Students found a mix of stateless and stateful bugs in the code, with a strong majority being stateless. The professionals sampled found strictly stateful defects. There are several possible explanations for this effect, although no evidence to support one over the others is immediately apparent.

The full text can be found here.

Posted by: rpstulk | February 1, 2010

Left-Fold for Bash

I’d like to share a recent bash programming experience I’ve had. It began while processing the reams of data generated in my M.Sc. research study. I was producing long lists of frequency data in text files, and had the need to sum up all the lines in these tables. This is of course a trivial problem in many languages, and I had a wide array of options available to me:

  • I could write another ant task to do the summing (this required more work that I was willing to invest, as ant isn’t really suited for computational tasks)
  • I could write a python script that took the contents of the specified file and returned the sum. I didn’t really like this approach because it involved yet another file in my build process, invoked from the ant task. I always sort of thought that if you were forced to use , you were performing a task beyond the scope of your tool.
  • I could skip the generation of the table and go straight to the sum. A few of the tables were created with XSLT, so this was a valid option. However, my XSLT programming ability is very much trial-and-error based, so I thought this might take some time. Also, some of the other tables, created with grep would not be affected.
  • Write it in shell. I liked this idea. I really liked the feel of being able to just pipe something to ‘sum’ and have the sum returned. So this is what I chose.

My first version looked like this:

#!/bin/bash

sum=0
while read line
do
sum=$(($sum + $line))
done

echo $sum
exit 0

It did the trick quite well. I had suggestions from office mates for the following alternatives:
Using python (courtesy Aran Donohue):


python -c “import sys;print sum(float(x) for x in sys.stdin.read().split())”

Using tr (courtesy Zak Kincaid):

cat numbers | tr ‘\n’ ‘+’|head –bytes=’-1’|bc
(Note that this version doesn’t quite work. bc throws a syntax error. not exactly sure why.)

Using my original design, I realized that if I abstracted out the operator, I could use this script to perform any 2-operand function I wished on the list, essentially creating a basic left fold:

#!/bin/bash
op=””
if [ “$1” == “” ]; then
op=”+”
else
op=$1
fi

sum=0
while read line
do
sum=$(($sum$op$line))
done

echo $sum
exit 0

I’ve done a little bit of error checking, to see if the parameter supplied is blank, and if so replace it with + by default.

I’ve only seen this work for ‘+’ and ‘-‘. If I use ‘*’, it breaks because it replaces the wildcard/multiplication character with the listing of the current directory.

Posted by: rpstulk | November 3, 2009

Unifying Visual theme

A discussion this morning over coffee has prompted me to again consider creating a personal web presence, more than just a facebook or twitter page. A public, hosted site with data about my work and research. Inevitably, whenever I begin to consider this, I always get hung up on the visual theme for said space. In a perfect world, I would create a site in which the visuals closely match my personality, in a cool-hip sort of way, be cleanly unified across all the pages, and indeed could even integrate well into my local operating system’s visuals (this doesn’t serve any particular pupose, the idea of total uniformity just seems sort of cool to me). Anyway, looking at hosting and gnome-look.org for inspiration right now. Probalby won’t lead me anywhere 😛

Older Posts »

Categories