This post goes into detail on our entire development stack from top to bottom.

At a glance:

• Source Control: Subversion
• Programming Language and OS: PHP on Ubuntu
• Framework: Zend
• Javascript Library: jQuery
• Programming IDE: Eclipse
• Build System: Phing
• Data Base Management System: PostgreSQL
• Backup and Restore: Backup Ninja and GPG

More detailed:

Source Control

There are many choices here and all are supported with very good arguments. based on our organizational structure and the decision to support linear development (which means minimal branching), the choice was for traditional source control tools (instead of distributed ones such as GIT/perforce). Because of extensive exposure to subversion and it’s general acceptance, we chose this.
Because we are a SaaS company and we generally prefer using services, we also have an on-line hosting package for it.

Programming Language and OS

This is a very open discussion and there is a nice chapter titled “So Many Platforms, So Many Options”,  from The Web Startup Sucess Guide, by Bob Walsh. We had decided before to use PHP on top of linux. Our distribution of choice is ubuntu, with which we are very familiar.

Framework

In PHP, the choices are really endless. We chose Zend Framework for the following reasons:

1. Familiarity: already used it in (smaller) projects in the past
2. Leverage as much or as little of it as we want
3. Supplementary tools available as we upscale, such as the rest of the Zend platform

The best element inside the Zend framework is that a software house can use as many features of it as they want, without getting into trouble. You can use the MVC, or you can just do it on your own with mod-rewrites. This goes all along the framework, which is good both in terms of being able to do custom development on what we needed different, as well as a smaller learning curve: when the project had to do some things urgently, the fastest approach was taken, and then when familiarity and exposure to the framework was better,  we re-implemented those features in the framework’s ontology.

Java Script Library

jQuery Simple, easy choice . Better supported, large user base, ease of use, number of plugins, nice and diverse community (eg. designers, coders, etc). We could not have thought of anything else, although we considered MooTools because of the Zend Framework integration.

Build System

Given the rest of the choices, the options available are limited, so we used Phing for build automation.

Programming IDE

There are many custom builds for Eclipse, our main one is the following: Eclipse for PHP Developers, which is tailored to our needs and has nice features such as code completion, subversion integration and many others.
We also use Komodo edit from Active state, which may be a good candidate for a future IDE. Both of those are cross platform. In each developer’s platform the following mini-IDEs/editors are utilized:

• Linux: geany and gEdit
• OS-X: TextMate
• Windows: Textpad

Data Base Management System

There is a very old post about that here. Many things have changed since then, but the choice remains the same: PostgreSQL. Now I have more arguments in favour of it:

• Cohesive and easy to find documentation
• Clear licensing – see what’s going on with MySQL/Sun/Oracle
• Feature Set

But most of all it is very dependable and stable. I know that it is not the most popular choice and that we have issues with software that runs on top of MySQL only, but we are very happy and confident for our choice and no company can take it away from us.

Backup and Restore

We chose Backup Ninja because it had a very small learning curve.
We might evaluate more options in the future, when we re-evaluate our backup strategy. Also
Gnu Privacy Guard is being use to encrypt the backups so that they can be transmitted and stored remotely.

In the Linux world there are many options, but considering our needs we had two choose between the two… usual suspects, PostgreSQL  and MySQL.
For those of you who just want the answer, we chose the one with the elephant logo, PostgreSQL .

Now, how we got there:
Initially we had an idea on what we wanted to store in our database system and what functionality we would like to use from them.
Both databases supported (or claimed they did, but we will discuss this later) all the required features, which made our choice more difficult since the capabilities are similar.
Then we roamed the Internet searching for comparison articles and researches as well as asking friends. A good informative link was the wikivs one:
http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL. One important factor on making a decision is the size as well as the requirements
of the application. This is an issue for us since we do not have an estimation of the data we will use since we are still in prototyping phase.

At the end of the day, it became a matter of personal preference, buzz as well as the history of those two projects.
History: MySQL has a history of having more features, while PostgreSQL has the fame of being more stable and rolling out features in a more conservative pace. Since both have the features we need, we preferred PostgreSQL.
Fear of the future: At the time of writing this blog post, Sun systems, that owns the company that owns MySQL is being merged with Oracle, which does not own now only Sun, but… Oracle. MySQL might be fragmented, since one of it’s founding members is rolling a new product. All these have been extensively reported in the news. Summarising all those, we have the fear of further fragmentation of the RDBMS or even it’s death (if Oracle’s boss says so). We are a very small company to cope with someone forcing us to change our RDBMS, or worse even people mocking us for not using the Microsoft stack.
Stored Procedures: PL/SQL, one of the languages that you can write stored procedures in PostgreSQL, is very similar to Oracle’s similar language. Accidentally both members of the Notion Learning team had some Oracle stored procedure experience. That is a plus we have already utilised, in some pair programming sessions.
Documentation: This is a quality versus quantity issue. Working with MySQL one can google up to thousands of pages with tutorials and help, generally of good quality, but some of not so good and many in total beginner level. On the PostgreSQL side, the situation is different: few resources but of very high quality. That has the immediate outcome that all the information is being stored into few locations, saving time to search for answers, something vital in a start-up. Eventually that was true: In the first month of using the language whichever question came up, the answer was at either the official manual, or at stackoverflow (http://stackoverflow.com/) or a few google clicks away. This reminds of the *BSD vs linux situation where many pro-BSD advocates argue that there are not so many tutorials and pages about BSD unices, mainly because the man-pages are of such high quality that people just read those.
Tools: Exactly the same landscape as documentation, few (and free) of high quality for PostgreSQL, more, of various levels for MySQL. Some commercial ones might be purchased in the future. The commercial ones existing add value to the product, instead of trying to clone MySQLs original but more expensive enterprise tool-chain.

This is a summary of our DBMS choosing. But there are some arguments in favour of MySQL worthwhile to mention:

MySQL is everywhere and there are many good bundles for every OS platform (eg. MAMP for Mac and WAMP for windows). It took us many hours to make a stack on an XP development machine. MySQL has more people around it so a larger pool of potential developers, who we won’t have to train after hiring them. Although it is not yet necessary, the ability to choose database engines seems very appealing.

Hope you found this posting informative, please drop us a line with your opinion.