Category Archives: Software Development

CSS for a complex web form

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Ammunition against ‘best practice’

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.
Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Steps to open source a project

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

What is my context?

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.

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

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

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)
Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Agile Database – Part 3: Features for a release system

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”)
Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Agile Database – Part 2: The release problem research

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

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather

Agile Database – Part 1: The release problem

To work in an Agile way, change should be expected and easy to manage. How does this look from a database perspective? Anything that you can “CREATE OR REPLACE” works fine – it can be stored in version control and the latest full version checked out to release to any environment. But what about those things that require migration? Like a table, or data.

A simple example could be an existing table with a ‘person_name’ column that contains first and last name separated by a space. You need to:

  1. create two new columns ‘first_name’ and ‘last_name’
  2. migrate the data from the ‘person_name’ column
  3. then remove the ‘person_name’ column.

A simple question right now would be (assuming I have the existing database and a new database with the changes applied): Is there any tool that could generate a difference script between the two database states to perform those actions? To date I have not found anything that could handle the “simple example”.

To further complicate the problem, not only is there is migration of objects over time, there are dependencies between objects at a point in time (eg foreign keys).

Some initial questions:

  • Do you put the original table creation script into source code control and keep it up to date? For what reason (it can never be used except to build a ‘blank’ database)?
  • Do you have a database “patch” script associated with a release? How will this work in a development environment with multiple developers adding to the script during development, and also wanting to only run the new changes to the script into their own development areas? How do you rollback a database patch? Or how do you complete a database patch that failed halfway through?
  • How to manage continuous integration, where each new change to the database patch should be applied as soon as it is checked in?
  • Are you interested in seeing the current state of a table creation script?
  • Are you interested in seeing the history of changes to a specific table?
  • How to ensure that the objects referenced by a foreign key exist before the foreign key creation?
  • How do you branch the database DDL code?

I plan to explore these issues in some further blog posts, ending with a possible solution. Keep reading 🙂

Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather