Today, I had some time to spend on my new open source movie collection web application, MovDB2.
I did some thinking about infrastructure, and collected my decisions on the project wiki.

The thing is: Most of these decisions have been done more or less arbitrarily.
I’ll list my available options and my reasoning behind the choice.
The problem I want to highlight is: How do you actually choose the right infrastructure for a new project?

Programming language
In such a decision, one of the bigger advantages of some options is that they are well known.
I know a couple of languages that would be fitting for a web application, namely Java, Perl and Python.
Java, as were my thoughts, is too big for this. No need to get into this kind of heavy machinery for something this small.
Perl. That’s difficult. The previous movie database project, still working well, was a perl project. Nowadays it’s kinda non-maintainable, and I don’t really like Perl anymore for its mostlycomplicated syntax. Perl is still going strong on the Tiobe index and is well-supported everywhere.
Python, is the hip, new scripting language. I really like it and have never done anything bigger in it.

So, the choice was Python.
I didn’t really want to get into Perl again, and Python seemed like a really good choice.

I should mention I had a small thought of learning Ruby on Rails for this, but I wasn’t really keen on getting into something completely new and unknown for this.
In the end, MovDB2 will be an application that I really need, not something that will only be used if it’s good.

The main open source databases are probably PostgreSQL and MySQL. And maybe SQLite.

I’m a big fan of MySQL and have done many things using it, so I chose it.
That wasn’t a difficult decision.

Interface to the database
Not too complicated, there’s only one really popular interface, and it’s python-mysql.

Interface to the web
This one is more difficult.
There are whole frameworks that handle this kind of stuff, be it Rails for Ruby, or Django for Python.
Because I want to hone my skills in basic Python, I tried to stay mostly on the ground, and chose the default CGI interface of Python.

Template engine
What I learned from creating web applications in Perl is that you better have a good templating engine.
I said I wanted to stay on the ground, but writing a whole templating engine (as I have done in the past) wasn’t in my mind this time.
I chose, what seems to be pretty popular, the Cheetah engine.

Shouldn’t this already be sorted out?
There are many IDEs which can handle Python, there’s the default IDLE, there’s Eric, there’s the default Gnome editor (gedit), there’s Eclipse with PyDev, and hundreds of others.

In the end, I think gedit is pretty good, and enough for what I want to do, so this is what I chose.

HTML/CSS editor
The second IDE in the project.
Again, there are many.
You can edit the stuff with your favorite text editor, there’s Quanta, nvu, and so on and so on…

I chose Gnome’s kompoZer, which looks to be pretty nice.
This was a really difficult decision though.

Another one that shouldn’t be done lightly (but has been in this case ;P).
I can host all the stuff myself, install Trac and a repository… or I can use old, trusted SourceForge, or BerliOS, or maybe the newly rising Google Code?

Again, Google Code seemed like an interesting, and easy-to-use solution.

I seriously considered Launchpad, but there’s just too much stuff I have no idea how to use.

In the end…
… this is still a personal project.
So while some choices seem to have been done lightheartedly, and some were, it’s not so big a deal:
Personal projects are the perfect sandbox to check on technology before using them in bigger (and maybe company) projects.
Who can choose the perfect wiki software, the perfect bugtracker, the perfect framework, the perfect IDE, when there are so many good ones?

Many of my choices depended mostly on checking around on the web, seeing the first couple of Google hits, and then checking the website of some good-looking projects.

The idea is to try out stuff, to change choices even in the middle of the project if they are bad.
Personal projects are the places where it only costs time, but gives experience.
In company projects, the experience is too expensive to gain, usually.

Where do I go with this?
My question to you, the readers, is:
How do You choose your project infrastructure?
What are your favorites for a specialized web application, like this one? What would You have chosen?
What’s the best way to determine “the best tool/technology” out there?

About the omission of PHP:
I’ve never really felt that PHP was my cup of tea, sorry. :)
The language is just… not good. It feels like Perl, and I’ve already had that.

My new project: A GUI and Web service interface for Amazon EC2
The Perfect Job Interview Question

Are you interested in reading more from CodingClues?
Then subscribe to new postings via RSS or via E-Mail.

Viewing 5 Comments

    • ^
    • v

    Why would you name the project 'movdb2' and NOT USE DB2 as the database? Plus, there's a product named 'move for db2' so, after I recovered from confusion induced epileptic seizure, I wrote this comment.

    • ^
    • v

    Thanks for your comments, especially thanks to Rob!

    Some quite insightful answers. Indeed, not too much thought has been put into the requirements, I usually do more for full-fledged company-stuff... :-D

    Anyway, the "project database" thing sounds really interesting.
    Especially considering that what formed the "Function Point" method of calculating project cost was based on such research.
    It might be an interesting thing to do!

    • ^
    • v

    I think this is quite a common pathway to how project technologies are chosen... for better or for worse.

    The strongest influence seemed to be what you've used before, as long as was relatively successful (i.e., the MySQL decision -- it worked for you before, so you don't really consider the other choices). Perl is ruled out because you've had negative experiences with it in the past... but Python could result in just as negative an experience -- you simply don't know because your experience is limited. Java seems to be ruled out for being "heavy machinery", though I'd say it very much depends on the approach you take -- a Tomcat installation and a few JSPs is pretty lightweight; a full JBoss installation, EJBs, all the extras would be much more heavyweight.

    ...but I'm biased because I have more experience in Java than probably anything else. so I can get a simple Java site up and running very quickly.

    So I could have the exact same requirements, but come up with a completely different solution; though I've tinkered around a bit with Python/Django and RoR, so I might actually take one of those as a learning experience.

    The funny thing about all this is that the only actual "requirements" for the webapp that you considered were size and the fact that it's a personal project. Was there any other consideration of what the site actually needs to do, and how that might affect technologies chosen? Maybe not, if it's simple enough....

    I personally can imagine a huge database with detailed information on millions of projects that are embarked upon constantly -- with data on developer experience, technologies chosen, project complexity/size/scaling requirements, domain, project success & schedule, and developer & management comments... and before starting a project you could look up similar projects executed by similar developers and compare.

    Wouldn't that be wonderful? But in my experience this is hardly even done *within* companies -- let alone in the wide world. I can dream, though....

    PS: kompoZer isn't associated with Gnome, is it? It's just nVu with a few bugfixes.

    • ^
    • v

    Java is too big! No PHP!, why do ppl keeping saying this. i doubt your language experience

    • ^
    • v

    Why not Smalltalk? When you choose Smalltalk you no need to worry about IDE, WebFramework, Template Language and so. Also it's very powerful and simply language for development projects like this.

close Reblog this comment
blog comments powered by Disqus