Friday, March 23, 2007

Updating your Textmate Bundles (UTF-8) issue

Assuming you got your bundles from svn... (you did didn't you?) ... then you can update them in the following way.
cd /Library/Application\ Support/TextMate/Bundles
svn up *.tmbundle
Doing this I got an error though
subversion/libsvn_subr/utf.c:466: (apr_err=22)
svn: Can't convert string from 'UTF-8' to native encoding:
subversion/libsvn_subr/utf.c:464: (apr_err=22)
svn: Ruby.tmbundle/Preferences/Completion: ENV[?\226?\128?\166] variables.tmPreferences
This is to do with having a local set that doesn't allow UTF-8.
export LC_CTYPE="en_US.UTF-8"
export LANG="en_US.UTF-8"
will fix it. Add them to your ~/.bash_profile to make the change permanent.

Update Mysql Gem problem

I just tried to update gems and got a problem with mysql (on my macbook)
I got the following errors.

checking for mysql_query() in -lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... no
checking for mysql_query() in -lmysqlclient... no

Googling around I found a post with the answer..
$ sudo gem install mysql -- --with-mysql-config 
This worked great.

I have no idea what the error messages meant, or why this fixes it, so I thought I should share it or risk forgetting it :)

Anyone care to enlighten me?

Thursday, March 08, 2007

...you keep treating it like we are in maintenance mode! [All Development is Maintenance Development]

One of my team said recently "This is a new product. You keep treating it like we are in maintenance mode!". He was right.

Eventually every product gets released. Once it is released you need to be in maintenance mode. Agile development focuses on getting this feedback from running software as soon as possible in by releasing early and often.

As soon as the first release is being used by real people (typically within weeks of starting the project) you are in maintenance mode, whether you like it or not. So all development is done in maintenance mode.

Because of this... You have valuable data you need to migrate with each release. You have users that need to be informed of changes to UI or behavior. You will have to prioritize between bug fixes and new features. You also gain valuable feedback from real users about the usability of your solution.

Here are some rules I have found useful for maintenance development:-

Every developer has their own database instance.


This sandboxes your changes from everyone else's. You wouldn't share the same copy of the code on a shared drive for development, would you?

Every change to the schema is done through scripts.


This allows you to share your db changes with the rest of the team (allowing you to make them more frequently) and handle migration of existing data. Like code, other's don't get your changes until they choose to. You must test these scripts to ensure the data remains intact. I used to have copies of a few big customer databases which I used to verify this. [I'll be releasing a .Net tool to help with this process soon]

Every schema change should have a number.

Every database needs a 'sysinfo' table with one row in it that tells you which version the database is. Every script is numbered in the order they are to be run. Running a script updates the database version number. This makes working out what script to run next simple, allows you to skip steps that don't need running, and unlike scripts that check if a change is needed before doing it, run fast and allow you to put re-do changes you have undone in a previous version.

Stored Procedures are code and should be versioned along with the codebase.

Your process of getting latest should be 1/ get latest. 2/ run the database schema migration scripts on your personal db instance 3/ update any changed stored procedures

Every check in should be atomic.

In other words every check in should contain all code, stored procedure and schema changes to leave you in a state you could get latest, build from scratch, generate a database from the scripts, run all the tests and everything will work.

Have no more than one branch (the version in production) and a trunk (the version in development).

Branches mean duplicated effort. If you release every week, you don't need one at all.

If you work out a good way to seamlessly keep the user trained on the latest version, let me know. I have a feeling the correct solution will involve the app automatically training people on how to user it, which would work for new users too. See Basecamp for an example of this.

Thursday, March 01, 2007

Freelancing on Rails

As of next week I am finally taking the plunge and becoming a full-time 'Freelance Rails Developer'.

I have a couple of "warm leads" already so things are looking good.

I've been using Rails for the last couple of years, while commercially working with .Net web development. The frustration I was experiencing with being to achieve more in a weekend with rails than I could during the whole week with ASP.Net finally got too much.

I'll be blogging about my experiences as I go, so stay tuned as I find my feet with freelancing, dealing with clients, quoting on work, marketing my skills, and working from home.

So... as a plug: If you know of anyone that needs some web development done, please let me know! You can contact me though freelancing@nigelthorne.com

GitHub Projects