Author Archives: warren

How Unit Testing is changing my coding style

Leave a Reply

One of the books that I am reading at the moment is “First Things First”, it mentions a cultural difference (yes blatant generalisation) between east and west along the lines of:

  • West – if it ain’t broke, don’t fix it
  • East – kaizen (continuous improvement).

This idea probably encapsulates the biggest change unit tests have made to my approach. I will now design and code with confidence that I can improve the code at any time.

That idea allows me to start without (too much) future thought as to what will be required – great for someone who makes use of intuition to program. I have often spent considerable non-programming time proving to myself and others that an idea will work. What does having a unit test have to do with this? It provides a framework where change is expected – sometimes an intuitive idea just does not work. I can rely on tests to prove the idea, or not.
A schedule of work can be broken into smaller pieces, each of which I can focus on individually. The individual focus effect provides a
productivity gain. Instead of building the mental castle of an entire source code structure, I can concentrate on the unit in front of me. (If there is a side effect because of what I do, it will be reported when the tests are run – note that I include integration testing in my idea of a ‘unit’ test framework.)
Though I was always willing to make cosmetic code improvements to something that I had personally written, I would regularly reach a point where I would be hesitant. Now, things like cosmetic changes to provide better code understanding, and design changes to better suit the application are done (almost) without hesitation. It is possible to ensure that the code still works even when I make major structural changes.

The cost in using a unit test framework is of course in writing and maintaining the tests. However, the way I have always worked, is code a bit, test a bit, code a bit more, test a bit more, etc. So there has always been a testing cost in what I write, it is just that now the test has also become a deliverable. There could probably be a debate on which approach costs more – possibly over a project lifetime they may be the same? Plus I like the idea that I can code a bit, test that bit, code a bit more, test it all, code a bit more, test it all, etc.

CSS for a complex web form

1 Reply

I just spent some time styling a complex(?) web form with CSS. Some basic requirements:

  • Any number of input elements on each form line
  • The first label on each line to be a fixed width – like a column
  • Able to indicate required/optional/readonly fields
  • Able to move things around fairly easily – particularly after a few months of not touching the code (and in my opinion counting td/tr and cell spanning is not easy)
Complex Form Example

Steps to achieve this result:

  1. First enclose each form line with a div (class=row).
  2. Add an indicator to the first label element on each row (class=first).
  3. Enclose the relevant pairs – label and input/select/etc – with a span (class=optional/readonly/required).
  4. Add CSS to suit the requirements.

So, it took a bit longer than it should have…

The label element does not have a width property unless you float it.

When floating the ‘first’ label, the text changed vertical alignment relative to the other labels in the line. I could fix it by applying a margin to the ‘first’ label, but when I changed font-size (or the text size via the browser) the alignment was out again.

The problem seemed to be caused by floating the label for for a font-size smaller than height of the input box. The simple fix seems to be in adding a line-height to all labels.

You can see the result (HTML + CSS) of this excursion here.

Ammunition against ‘best practice’

Leave a Reply

I was asked this week for help in responding to a person who continually supported their approach by calling it ‘best practice’.

Best Practices: Who Says?

“The fact is that we really don’t have a mechanism to formally establish best practices in the software development community.”

“… I’ve begun restricting use of the term ‘best practice’ in articles that we publish in IEEE Software. In most cases, ‘good practise’ or ‘effective practice’ serve as acceptable substitutes.”

Best Practice

A completely fatuous concept based on two dangerous assumptions:-
a) someone else knows what’s best for you
b) you don’t have to think about your context.

No Best Practices

“Go ahead and follow your favorite practices. Just don’t preach that the rest of us must follow them, too. Keep your process standards to yourself. If you want to make a suggestion, make one that takes context into account.”

Useful Practice

  • BestPractice – someone else knows what’s best for you
  • UsefulPractices – you are stuck deciding what’s best for you. It’s your butt, after all.
  • BestPractice – you don’t have to think about your context.
  • UsefulPractices – you are the one in your context. So pick what works for you there.
  • BestPractice – you can have success by doing these things without understanding anything about them.
  • UsefulPractices – only through understanding of the practices and their principles do you stand a chance of succeeding.
  • BestPractice – is an exclusive practice. These are best. We know best. The work is in selecting out.
  • UsefulPractices – is an inclusive practice. These seemed to work. We have some ideas. The work is in selecting in.

How do you to-do?

Leave a Reply

Let’s start with a simple definition of a ‘to-do’, how about – a task that you cannot complete right now.

The issue is what you will do with that task. Basically, you want to forget about it now, but remember to start the task when you have the required time, resources and inclination. This implies that the being a reminder mechanism is the main objective of a to-do.

So, the basic to-do scenario might be:

  1. Open up your to-do list
  2. Add the task to it
  3. Return to whatever you were doing
  4. Sometime in the future start doing the task

An important concept was just introduced! Many to-do tasks make up a to-do list. Your to-do list may spread across many formats:

  • Memory
  • Physical prompt
  • Paper
  • Software
  • An assistant

Time to remember the primary objective – how to remember when to do something. Notice that all of the to-do list formats have a direct method of notification:

  • Memory – It’s Monday, back to work, I have to bring that book in
  • Physical prompt – I need that book at work, I’ll put it by the front door
  • Paper – I’ll add a note to my morning checklist to bring that book in
  • Software – I’ll email a reminder to my home email because I need that book tomorrow
  • An assistant – Hey slave, go to my house, pick up this book that I want at 2pm

All of them work, all of them have issues…

To-do List Advantages Problems
Memory Portable
No/low overhead ‘entering’ a new task		 Forgetfulness
Stress
Basically unreliable
Physical Prompt Effective set and forget method
Typically the prompt is what you need to complete the task		 Other people can interfere with the prompt
Probably not scalable
Creates clutter
Only for suitable tasks (eg does not work for “Take the car to the car wash”)
Paper Can represent any task
Well supported by to-do systems
Configurable in any way you want to change it
Relatively inexpensive
Portable		 Requires manual checking
Can involve significant management
Requires an organised personality
Must be carried around to be portable
If you lose it, it is gone forever
For complex systems, you must understand the system
Software Can represent any task
Well supported by to-do systems
Reminders can be automated
Much of to-do system theory can be built into the software
Can create backups to guard against information loss
Can be inexpensive
Portable (on a Mobile device)		 Mobile device must be carried around to be portable
May not support features that you want (difficult to add those features if you want them)
Can be expensive
Requires access to a compliant device for the reminders to work
An assistant Task management can be sub-contracted to other people Very Expensive

Note that we use a combination of most to-do list types – even when we attempt to use only one. Recognising this and working with it, rather than against it, can help you make peace with your personal to-do ‘system’. You can allow yourself to use the best to-do list for the situation rather than fit all situations into a prescribed to-do list.

One common problem with to-do lists is that few of them cope effectively with lots of tasks. As soon as a to-do list is filled wtih many tasks, it becomes more complex to manage. Strategies to cope with many tasks include:

  • grouping tasks into projects
  • giving tasks tags or context – typically location, priority and scheduled date/time.

What other things can you do with a to-do list?

As time is a limited resource, and we tend to have more to-do than available hours, you can use a list to prioritise what you will target for achievement.

What can you do with a to-do when you’re done?

You can report on what you have been doing (perhaps to your boss).

Basically, a done list provides you with a feedback loop. Just like recording money expenditure helps with budgeting, a completed to-do list can assist you in examining where your time is going. You can better balance your life activities.

The temptation though, is to track more with a to-do list than necessary, just to improve the quality of the feedback.

Actually, this function could better be called a task diary. Completed to-do items happen to be the main (probably only) input to the task diary for most of us. However, the value of the task diary is limited by how many done tasks are added to it. A better approach may be to consider more than just completed to-do items as input to your task diary (eg a direct automatic daily entry for making and eating breakfast).

Steps to open source a project

Leave a Reply

Recently I open sourced the MIGRATEdb project. Here are a few notes about the trip.

A home for the project

To open source a project, first you need to choose where to locate your project. One way would be to self-host the project and source code, however there are a number of service providers out there who will manage your source code, Subversion/CVS repository, track issues, allow downloads, etc. I chose SourceForge. So I had to create a user account and then setup the SourceForge project.

Project Setup

When setting up the project there a few important things to consider – like the name of the project. Why MIGRATEdb, well the name provides some indication of the projects purpose and it conjured a couple of interesting visuals…a bee with suitcases (a migrated-B)…the ‘db’ part is vertically symmetrical.

To open source a project you must choose an open source license to use. There are many of them, to ease the brain strain they can be grouped into two main types: academic and reciprocal. Basically, an academic license allows anyone to use the project in any way they want, a reciprical license requires any derivatives, that are released and distributed, be provided under the same license. MIGRATEdb was open sourced under the BSD license an academic style license.

Project Registration with Host service

Next comes the actual registration process. For SourceForge there were a number of questions to answer (like how the software is classified, what is a short description of the software’s purpose, …), then someone will actually look at the project request and hopefully approve it.

Bring the project to life

These first steps were all performed with SourceForge tools:

  1. Upload the source code to the Subversion/CVS
  2. Create a release, for MIGRATEdb there are two release files – the full project and an ‘executable only’ distribution.
  3. Create some documentation – for MIGRATEdb this is a simple web page.

Promote the project

To raise interest in the project you can promote it to the targeted user community, blog about it, tell all your friends, etc.

What is my context?

Leave a Reply

Personal Context. It can be used to enhance software interaction with you. Time has been the big one so far. You tend to know when you are fairly cheaply. Time can be used in software fairly reliably – problems are mostly encountered when you personally travel or you communicate with someone in a different time zone.

What else could work as context about you?

  • Email address – identification and contact mechanism. It is distinct, regularly used as a login name, but suffers a little because it changes.
  • Biology (fingerprints, dna, eye scan, heart rate, blood pressure) – identification, state of health, what you are doing (eg brain waves indicating sleep/dreaming).
  • Written signature – identification.
  • GPS – answers the “where am I” question. Could this be the next big thing in Personal Context?

Software that knows where it is. How do I move from here to there? Navigation systems do it and have already been implemented all over the place. Sports watches already use GPS information to provide speed and distance for the runner/cyclist/sailor.

I have a personal interest in building a better to-do list (perhaps by creating some software). How about combining your pda/mobile phone, with GPS, with location and time aware to-do software? Now I can have software that automatically:

  • only shows tasks relevant to work when I am in the office
  • reminds me to buy bread when I walk near the grocery store
  • reminds me to buy a birthday present when it is a week to a friends birthday and I am near a shopping centre
  • reminds me of something that I want to tell a friend when I visit them

What about the actual mobile phone software – I want calls from work to only vibrate the phone when I am at home, but to ring when friends call.

GPS, with its growing and cheaper hardware base, looks very interesting in combination with software that can make use of my personal context.

The Spiderman Rule

Leave a Reply

Recently our 3 year old daughter was introduced to what I call…

“The Spiderman Rule” – with power comes responsibility*.

Basically, with the powers that we allow her to use, like playing in the front yard, comes responsibility, like staying in our yard (it does not have a fence at the front). Not living up to the responsibility means that the power cannot be used. Simple.

I like it because it is short, easy to say and involves a comic character that she likes.

* (Actually, in real life ;), Spiderman lives by the motto “with great power comes great responsibility”)

Agile Database – Part 4: MIGRATEdb (a solution to the release problem)

6 Replies

Go here for the other posts in this series.

MIGRATEdb will parse an XML file of database changes and load them to the targeted database if they are not already there.

A database change consists of a test to determine whether the change has already
been applied and a set of change actions.

The tool works from the command line and also as an Ant target. For a simple start we have an Ant script that includes targets for:

  • user.xml = create the application user (this will be executed by an existing ‘power’ user with the permissions to create a schema/user)
  • db.xml = all application creation SQL
  • drop.xml = drop (cascade) the application user (I expect this would only be used in my development sandbox)

Agile Database – Part 3: Features for a release system

Leave a Reply

Possible features for an Agile Database Release System:

  • Allows construction of a database at a particular version
  • Allows migration from an existing database to a later version
  • Allows migration from an existing database to an earlier version
  • Human readable format for releases
  • Release ‘action’ available on multiple environments (ie various operating systems) allowing development on a different platform than production
  • Provides a complete history of changes for each database object
  • Provides a current creation script for each database object
  • The source code can be branched and merged
  • Allows multiple developers to work with/on the same database source code, at the same time
  • Supports an ‘automated build’ / ‘continuous integration’ enviroment
  • Automatically records database changes by the developer in their development area
  • Supports use of parameters to configure variable parts of the release (eg the password part of “CREATE USER warren IDENTIFIED BY xyzzy”)

Agile Database – Part 2: The release problem research

3 Replies

There are a lot of people who want an Agile Database Release Solution. I’ve listed a few links and occasional interesting bits from them, but the common solution seems to be a master script of all database changes.

General Overview

‘Agile Database Techniques’ A book by Scott Ambler – Describes three types of log files: “Database change log : contains the DDL source code that implements all database schema changes”, “Update Log: source code for future changes to the database schema that are to be run after the deprecation period for database changes”, and “Data migration Log”.

Agility and the Database – A detailed discussion of the problem and high level solution.

Applying Agile SCM to Databases – “Databases come with state.” A short paper on the problems.

Version control of database objects – a long and interesting dicussion talking about a big change log solution. An initial set of considerations: “Track the end state of the object or modifications?”, “Support for automatic builds”, and “Support for branching and merging”. One of the comments describes and interesting approach, to comment out the previous DDL in the source file, so it is still there, but only the new migration command will be executed. The concept of being able to generate whatever artifacts you may be interested in is also mentioned (for example, if you want a clean table creation script for a table, or history of changes for one table, go generate it – don’t repeat yourself in the version control system).

SCM for Databases? – A short overview of some issues. One comment points out the problem with ‘difference’ tools is that they only catch certain changes – not all.

Solution Descriptions

Our Database/SQL version control process – all DML and DDL changes are logged, but this one does not sound like it was automated.

The Database Patch Runner – all alterations for a “conceptual change” are written in one patch file and the patch files documented in a separate txt file. The patch file is actually a PL/SQL procedure that will be executed by a “patch runner”. The patch runner ensures that no patch is ever run into one database more than once, I am guessing that the patch runner knows because it keeps a log file, or an install log within the target database. “In response to the single script with history for each table. Until you’d mentioned it I hadn’t noticed that it wasn’t there, so no…I suppose we don’t miss it.”

Bugzilla Approach – “one great big ‘create-database.sh’ script…Whenever someone wants to make a change to a schema, they add it to the bottom of the script, along with a test to see if the change has already been applied.”

Version Control of Database Data – uses DROP table first then and number of scripts to recreate new table and reference data. Does not seem to address what happens to production data.

XP and Databases – “act as if the database is easy to change”. This article describes databases as Gold (production), Silver (migrated Gold ie test) and Bronze (migrated Silver – ie development).

Database scripts and version control short solution comment that I didn’t really follow.

Other Links

“Sorry, we made database changes so there is no going back” Software releases and database changes suggests that for every change script there should be an equal and opposite rollback script. I prefer the idea that in development, you are able to rebuild everything, and in production it should happen so rarely that the effort involved in dealing with a rollback would be (much) less than the effort involved in providing a repeatable solution.

A comment in The Database Patch Runner – Rollbacks mentions the Oracle “FLASHBACK DATABASE” to rollback the entire database – perhaps this is something that could be turned on before a production release?

The Database Patch Runner: Dealing with code contains an interesting comment about retirement of code. How do you stop using a package? “We produce a patch to drop the objects we no longer need and then remove the objects from version control….Obviously you need version control software that deals with this properly (earlier tagged versions should still contain the removed scripts)”.