One of the more important things I learned from my talk is that presentations should not have the same format as essays. I prepared my talk much like I used to prepare my university essays. This wouldn’t have been so bad except that in my introduction I outlined my forthcoming main arguments. With written essays, this is fine because the reader can immediately see how long the essay is and that these points will be discussed later. Not so with a presentation, where the viewer expects whatever is on the slide to be discussed then and there. After a few incantations of “I’ll get to that later” my mistake was fixed but it still generated some confusion and interrupted the flow of my talk.

In addition to touching on content management, HTML, search engines and marketing, my presentation also brought in aspects of usability and web design. I had previously planned to leave out those last two topics due to time constraints and “obviousness” but I’m glad that I chose to include them. Not only did my presentation last precisely one hour as intended, but I was able to pick out several key areas of the newspaper’s website which were lacking in usability or comprehensibility. Amazingly, there were a lot of pages where it wasn’t obvious what was being presented.

People were impressed, not only because of the content of my presentation but also because of how it looked. Keynote can take a lot of the credit for that as I only gave a passing thought to layout, which is how it should be. I even got compliments before I began, purely based on my title page. How many Powerpoint presenters can say that? Keynote made any layout changes outside of its standard templates quick, easy and intuitive. The only problem I had with Keynote is that it forces the presenter to click through old bullet points on a slide after launching a web page from that slide. Was that ever annoying, and something that I will have to work around for my next talk.

Will there be another talk? Who knows. I’ve been realising these past few years that I have accumulated bits and pieces of important knowledge from various domains that have become second-nature to me and yet which others seem to have failed to grasp. It’s not enough expertise to fill books, but digested in hour-long or half-hour long talks it’s bound to have some effect on someone. They just have to pay.

For me, one of the most difficult parts of a technical presentation is finding its starting point. I often forget how much I know and usually assume the same level of comprehension from the audience, overlooking why I am speaking in the first place. This time I am presenting a fairly technical topic to a non-technical group so I am finding myself starting from first principals then building up (or down) a point. Hopefully I can avoid getting bogged down with too much detail. My presentation right now looks like a crash course in content management, HTML, search engines with a dash of marketing thrown in for good measure.

My talk makes use of slides and, like anyone relatively new to presentations, I quickly found myself dumping as much information in as many bullet points as possible. Stepping back, I realised this would make for a dull talk as I knew I would just use the slides as a crutch. I then changed my tack and instead put as little information as possible on my slides. This will allow me more freedom to speak without being tied to my slides, which are now more punchy as a result.

It’s amazing how easy presenting appears compared with how difficult it actually is. It’s just talking, how hard could that be? People like Steve Jobs make presenting look as effortless as breathing. We as the audience don’t see the hours and hours of preparation, agonising and practice which go into those keynotes. Everyone thinks they can present well, but few actually can. I won’t be able to present like Steve Jobs, but at least I have his tools.

• Writing monolithic tests. More often than not, I see people writing one test method for each method they are testing with all their asserts contained within that test method. While not incorrect, this will impede testing as most test suites stop at the first failed assert. For example, if a test method has ten asserts and the first one fails, no conclusion can be immediately made regarding the remaining nine asserts. As a result, the first failure must be fixed before the remaining nine can be tested. This is particularly frustrating when tests are automated and run on a regular basis. Consider splitting your tests by requirement and including no more than the minimum asserts necessary inside a test method to test the associated requirement.
• Not running the tests on a regular basis or altering them as requirements change. Once tests are written and they pass, many developers do not run those tests again. Months later, changes in requirements and code lead to a drift between the tests and what they are testing. Should someone run the tests again, the tested code will appear to be incorrect and confusion will result. As such, it is important to run tests on a frequent basis, ideally automatically, and to keep tests in line with requirements.
• Improper description of what test cases are testing. Unit tests cannot exist in a vacuum. Mislabelled or undescribed tests only serve to confuse which requirements they are testing. Sometimes asserts are self-explanatory but more often they are not and require further output to describe failures. Consider naming your test methods to describe what they are testing (eg. testThatMethodFooResultsInCondition) and/or include a written explanation inside the assert statement to be printed alongside the failure.
• Noisy test output. Depending on the testing library you are using, your tests may already be generating needless output. Adding more output will only result in confusing test results. Positive test results should never output data to the test log. Negative test results should make use of the output facilities within the testing framework for uniform formatting.
• Improper use of the test case API. This is a small detail but deserves to be mentioned. I have seen many test cases which do not make good use of the testing framework under which they are running, leading to unhelpful output. For instance, in JUnit assertTrue(foo == 3) is not equivalent to assertEquals(3, foo). The former will output a generic failure message while the latter will explicitly output the expected and actual results. Pay careful attention to the test framework’s assert method signatures as order will often matter. For instance, in JUnit, assertEquals(3, foo) is not equivalent to assertEquals(foo, 3) and will result in two different failure messages.

Too often it would seem that project managers and developers forget the old maxim that “time is money.” Projects are often started without a proper plan including a time estimate, cost assessment and an analysis of whether the benefits outweigh those costs. This mismanagement of time results in changes of scope over the course of the project with creeping time overruns as “unforeseen” difficulties arise and features are tacked on.

Sadly, the Toronto Police eCOPS failure isn’t an anomaly in the software industry. The only news here is that it has been a colossal waste of public money.

It’s easy to see where the shipping company went wrong with their package tracking web application. They fell victim to one of the classic blunders of date manipulation: forgetting to include the timezone. If FedEx, the company which “Runs on Time” can make this mistake, then so can you.

If your application deals with dates and times, you should remember the following, among other things:

• If your application stores dates, either include the matching timezone or store all dates based on some fixed timezone, such as GMT or UTC. This way you can easily see how much time has passed between dates, regardless of timezone.
• If your application stores dates and/or times, be sure to include the full date even if you think you will not need it. It is a lot easier to include support for dates and/or times in your code later on than populating them in existing data. This should go without saying, but include every portion of the date that you can. A few years back I was integrating with a client which did not include the year in their stored dates, and it made their application confusing not to mention hampered our integration.
• If your application displays dates, make sure that it does so in a consistent and possibly configurable manner. Confusing your users with several different formats, none of which they can control, does not lead to proper usability. Doing so will also hamper any integration efforts which may occur in the future. I once integrated with an application which used no less than six different date formats in its output. Needless to say, the integration did not go well.

If you are using a colour-aware terminal, you can use control codes to change the text colour. By inserting these codes with a sed script, tail output can be colour-coded.

For example, supposing you wanted all lines labelled as containing severe errors to be displayed in bright red. This can be accomplished using the following line:

> tail -f mylog.log | sed -e "s/\(.*SEVERE.*\)/^[[1;31m\1^[[0m/g"

Note that ^[ represents the ESCAPE character, which can be typed in by pressing CTRL-[ or CTRL-V followed by ESC.

I wrote this brief tutorial because I could not find instructions specific to this topic by searching Google. No doubt a better method exists to accomplish this colour-coding, but I’m not that bright.