Homepage

Integrated Feedback

November 9th, 2006

Jamie | Choices | 2 comments

Version Control on OS X

October 19th, 2006

Version control is essential for application development when more than one person will be involved with the project if you want to avoid the nightmare of over writing each others files, and just plain useful even if you are developing on your own. Subversion is one of the best version control systems around right now. The great thing about it is that you can both work on the same file at the same time and integrate your changes when you commit them, unlike other version control systems that lock a file when someone is working on it which can be a total pain if someone forgets to check in a file and is not available.

I’ve been using subversion for some time now as coding takes up a large portion of my time, where as Chris, being primarily a designer, has had little experience with it. I wanted to find the best GUI for using subversion so that I could introduce Chris to the wonders of subversion. Both Chris and I run Apple computers so that narrows down the search some what. Here is a quick round up of subversion GUI’s I have tested (or tried to test):

• svnX - This is the software I have been using for the last few months. Its been relatively stable and provides a good feature set with a nice looking GUI. My only real complaints are that some of the more advanced functions are not that easy to work out how to do without reading the help files and there are too many windows.
• RapidSVN - Many people use this GUI, personally I find it a little slow on osx as its not a native application, I also find the interface a little clunky. In terms of how this works I have not come across any real issues.
• ZigVersion - The new kid on the block, its a little unstable at times and lacks support for some of the more advanced features but its early days yet. Looks very promising and could very well become the best GUI if all goes well for this app.
• SCPlugin - An OS X clone of TortoiseSVN, the website for this hasn’t been updated since 2004 so it looks like development of this has ceased. When I used it I found that it slowed down the finder to an annoying level so eventually had to remove it.
• Subcommander - This program might be good but I couldn’t test it as it crashed every time I issued a subversion command!
• eSVN - This program requires you to install additional software to enable it to run, once installed the window management on this application is so bad it makes it unusable. I gave up without even being able to add a repository!
• TextMate - Not a subversion GUI as such, but this has built in subversion support that works pretty well, it lacks support for some of the more advanced commands and I wish they had a menu for executing subversion commands. For quick commits while working on files this is great.

We are going to stick with svnX as its the easiest to use, fast, and there is a 1.0 update coming at some point which looks like it will be rather good. A word or warning though, if you upgrade to subversion 1.4 you will find that svnX is no longer able to work with your repositories. The 1.4 update has made quite a few changes to that way in which subversion stores it files, thes changes are not backwards compatible with 1.3 repositories. Subversion 1.3 and 1.4 server/clients will talk to each other just fine though.

Maybe Chris will post his thoughts subversion as a newcomer once he has had a chance to get to grips with it.

Jamie | Code, Choices | 1 comment

Post Production

October 16th, 2006

One of the first considerations for the application is what language to use and which platforms we should support. As this is going to be a “download and install on your own website” application rather than a hosted service, platform support is a key issue. Some of these choices were very easy, others decisions were a lot more diffucult.

Lighting the LAMP

LAMP (Linux, Apache, MySQL, PHP) was the obvious choice for us, firstly because I have the most experience with this set-up, secondly because there is a huge user base which will provide us with the most potential customers for the application. We are going to focus on Apache, MySQL and PHP, with the aim of supporting Linux primarily plus as many other operating systems as possible without compromising any features or having to write overly complex code. IIS will not be supported due to the lack of support for .htaccess which is one of our requirements for clean urls.

To PHP or not to er, PHP?

One of the decisions that had me hung up for quite some time was if we should go with PHP4 or PHP5. In the end PHP5 won this bloody battle mainly because I ran into a few issues while trying to use PHP4 which PHP5 solves very nicely. At first I wanted to use PHP4 so that the application would be compatible with as many servers as possible. I really didn’t want to restrict our application to people who have upgraded to PHP5. A quick poll of some of the top web hosts revealed that the PHP4/5 split was about 50/50. So basically by using PHP5 we cut out about half of our potential customers, not something we wanted to do for no reason. After many days of schizophrenic struggling with myself I eventually decided to go with PHP5. The programmer in me was saying PHP5 while the marketeer was pulling me towards PHP4. In the end the deciding factor was just a single character, “&”.

In developing the framework to run this application I wanted to be able to pass objects around between classes. One of the major changes in PHP5 is the way in which object references are handled. When you assign a variable in PHP4 the default is to make a copy of the object, in PHP5 the variable is a reference to the original object. If you want to read more about this see here, they explain this far better than I can. So this is where the “&” comes in, if you stick and “&” character in-front of your variable in PHP4 it will pass a reference to the original object instead of a copy. Great, no problem, apart from when you forget to add this little sucker and spend ages trying to find where the problem is. After doing this twice while working late at night I decided that PHP5 was the road for me, no more dirty little &’s littered around my code causing head aches.

PHP5 also has a number of other nice features that are going to help the coding process. By the time we release our application I’m sure PHP5 will have gained even more popularity so the user base will be less of an issue. Onwards and upwards…

The Framework

There are a vast number of existing frameworks available and after having tried a number of them I found myself wanting to write my own that worked exactly how I wanted it to. I’ve played around with a numerous frameworks on different projects recently including the “holy grail” of frameworks, Ruby on Rails. I do like certain many aspects of RoR a great deal, it just doesn’t lend itself to creating a web application intended for installing on your own server. RoR is not supported widely enough by web hosts at the moment, although this is changing pretty quickly. Even so, the number of hosts supporting RoR when we release our application and more importantly, the number of people who have experience with using it will still be relatively low, this rules out the Ruby language along with the rails framework. There are a number of PHP frameworks available, some of which look very promising. The problem is they just don’t feel “right” to me when I use them, some of them are overly complicated when compared to RoR. The best of the bunch, in my opinion, is the Zend framework which is currently in beta. It’s not a good idea to base and application on a beta framework that could be liable to changes outside if our control which rules out the Zend framework.

It has to be said I am very fussy when it comes to programming and using other peoples code. I generally prefer to write my own code rather than integrate someone else’s code into an application. I started tinkering a several weeks ago with writing my own framework, getting the basics hammered out was easier than I was expecting and I soon had a basic system working loosely based around the MVC framework model. I say loosely as I have dropped the traditional model style from the system in favour or putting all logic and validation in controllers. I’ve been tweaking, working, and extending the framework in spare time between projects and its coming along nicely. I’ll be posting more about the framework as it develops along with the application.

Jamie | Details, Code, Planning, Choices | No comments