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.

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.

The first reason we chose to release the product for download was differentiation. There are already a few hosted solutions that do a pretty good job, but none which you can set up on your own server. By allowing users to set up the application on their own server we’re allowing them to take full control of their content, they can add as much or as little as they like to the system. We’re also hoping that a community of developers will build up around the application and come up with add-ons/plug-ins and other creative adoptions of the system.

Another aspect is cost. If users are installing the application on their own servers they’re not using our resources, which means when you buy a license you’re paying for the product and don’t incur the added cost of hosting etc. Most people already have their own web hosting set up and I’m sure would rather not have to pay twice for his. We can also make the pricing strategy a one-off payment, saving time and hassle that would be brought about by issuing monthly invoices.

Then of course, there’s the issue of salability. Our main target market will undoubtedly be web designers and developers (the traditional early adoptors) and, naturally, they’ll want to be able to get right to the root of the application, creating add-ons and fully integrating it to suit their individual needs. This sort of customisation can’t be easily achieved with a hosted app.

Finally, there’s the benefit of Jamie running a hosting company, meaning we already have a captive market to sell licenses to. There’s also no restraints on who we can partner up with, we could for instance offer other hosting providers custom-branded versions of our software at a discounted rate for bulk orders.

One very successful self-hosted application on the market at the moment that we like a lot is Mint. It’s a beautiful application for keeping tracks of stat, the configuration process is the pinnacle of ease-of-use. We had Mint for this blog up and running in less than 2 minutes. There’s been a lot of speculation during it’s lifespan about whether or not Mint is worth the $30 price-tag. The main argument behind this is that the Peppers are what bring the most value to Mint, over rival hosted software, yet the Peppers themselves are free. I’m not going to speak on the price of Mint, but what I find most interesting is just how much value Peppers add to Mint. On the serious SEO orientated projects I handle, I tend to use about 7 peppers (Add-ons build using the Mint API) which far outweighs the amount of functionality built-in. There are a further 50 or so Peppers freely available, one of the strongest selling points of Mint.

This sort of developer-following wouldn’t be achievable with a hosted platform and so our aim with making the application available for download is to develop a strong community who will build add-ons, hacks and themes that will add much more value to the product than the retail price we put on it.

Although we obviously can’t say what the application will handle (or even it’s name, because that would give it all away), we can let you in on a few things:

• Our software will solve an age-old problem.
• It’s definitely got a purpose and a strong revenue model.
• Web Standards will be used bountifully and ease-of-use will be unprecidented.
• There’s already quite a few competitors.
• It’s got design from the nice lads at Chris Garrett Media and coding from the gents at Media72.

Stay tuned because we’ll be touching on such fine subjects as Information Architecture, Branding, MVC frameworks, usability and even a little on the mobile web.