BarCamp Singapore Jan 2007

In: PHP|Ruby|Ruby on Rails|Web development

21 Jan 2007

I just got back from BarCamp Singapore a few hours ago. I was only vaguely familiar with the Rules of BarCamp prior to this, and actually only found out about the event from Choon Keat (of RssFwd fame – check it out if you haven’t already) 2 days ago.

Anyway, props to the organizers for putting this together (especially the free BarCamp t-shirts from Yahoo!). Personally, I felt the icebreaker game took up too much time that could have been used for the sharing sessions – the tech track of sessions were crammed up towards the end of BarCamp.

BarCamp Singapore logo

Notably, Harish Mallipeddi, who interned at Bezurk for a couple of months, shared with us an introduction to Django together with some working code on a site he is working on. I didn’t know a whole lot about Django before and was impressed that there is a “free” admin application for Django applications. We (Choon Keat, Harish, and I) had a small debate over Django’s templating system (briefly, Django has it’s own templating system for its views, whereas Rails ERB is basically Ruby code mixed in HTML). To this day I am still convinced that PHP is already a templating language despite my old Smarty card-carrying days. Relating back to the Django templating system, Choon Keat and I didn’t like the idea of having to learn to use a templating language when the base language itself (Ruby or Python) would suffice. Obviously Python syntax wasn’t suitable for web designer consumption so Django had to come up with its own templating language.

Michael from PetrolWatch showed us some flashy scriptaculous effects on his site and demoed the Ruby on Rails-inspired CakePHP. It’s a nice framework if you had to use PHP and performance is a concern (it’s true, Rails apps run more heavily than PHP scripts, and the difference in performance is very clear in servers with minimal resources). But the lack of a good testing framework was discouraging. Still, I must say I’d have used it (or a similiar framework) if Rails didn’t exist or if I was tied to using PHP for web development.

Choon Keat showed the non-believers the power of Rails’ script/console as well as the flexibility of Ruby in allowing developers to make their own extensions to existing classes (aka “who needs hooks from God?”). I probably should have stepped in and showed some basic Rails migrations stuff that would have impressed (hopefully) the Django and CakePHP fanbase (all 2 of them) – but my laptop was running out of battery (and I was shy).

Oh and I saw a good number of Macs there, and at least 3 laptops running a Linux distro of some sort. Cool.

9 Responses to BarCamp Singapore Jan 2007


Michael Cheng

January 21st, 2007 at 1am

I’m told that there’s a Unit Testing software out there for Cake PHP.

Here’s the link:


Michael Cheng



January 21st, 2007 at 9am

small typo: ;-)

Hmm… migrations would’ve been swell for PHP crowd, but I believe Python has a similar schema version control… part of SQLxxx can’t remember


Chin Yong

January 21st, 2007 at 4pm

I am currently using CakePhp on a websitel. The test suite mention by Micheal Cheng is created by one of the main developer of Cake.

I have no experience in that test suite as the testing portion is left to my colleague. Will feedback once I gather my hands on that info.

CakePhp is a great framework as far as I am concern. Anyway, I had taken a look at barcampsg and it sound really cool. How do I get onto the bandwagon?


Daniel Hofstetter

January 21st, 2007 at 5pm

As the official test suite of cakephp is rather limited I wrote my own test suite for cakephp 1.2 which is inspired by the rails test suite:


Chu Yeow

January 21st, 2007 at 9pm

Ahhh, thanks Michael and Daniel for the CakePHP testing links.

@Choon Keat: Fixed :P. Ahh… But Harish didn’t seem to realize that Rails had migrations :x


Harish Mallipeddi

January 22nd, 2007 at 7pm

@Chu Yeow

I knew Rails had Migrations but I didn’t realise that people actually use Schema Migrations to write the first version of the schema as pointed out by you at BarCamp (and definitely calling it ‘Migration’ doesn’t make sense for that use case!).

As far as Django is concerned, Rails-like Schema Migrations support is on its way. It was actually a Google Summer of Code project but the student who took up the project didn’t deliver. So someone else is rewriting the whole thing again because the previous codebase is apparently unusable. But the main purpose of this is only to help you to migrate the DB schema without writing SQL (atleast for simple CRUD tasks, the SQL required for which can be easily wrapped in helper Python functions). For complex migrations, there’s always an extremely easy way to run hand-written SQL in Django.


Harish Mallipeddi

January 22nd, 2007 at 8pm

Template systems :-

The beautiful thing about Django’s template system is it has been designed for designers in mind – the default template language features are kept at a bare minimum. Expecting a designer to write Python/Ruby/PHP code does not make sense.

There are only two basic constructs in the template system: {{ variables }} and {% block_tags %}. -> takes 15 mins to grasp whether you’re a programmer or not. But ask your designer to write Ruby and he’s certainly going to give you the look which you don’t wanna see :)

And the other thing is if you didn’t like the naming that they use, you can define your own block_tags in Python and then make the job easier for your designers.

But if you’re a developer/designer, I would imagine the idea of restricting you to a template language might sound like a move to cripple you.

A lot of it has to do with how these projects evolved. Django was developed inside the web division of a newspaper company. They typically would have a lot of designers in such teams, and a lot of computer-illiterate authors contributing the content – articles, news reports. The cool Admin system is also tailored to this scenario.


Harish Mallipeddi

January 22nd, 2007 at 8pm

@choon keat

Yes you’re right. SqlAlchemy has migrations support through a third-party library called Migrate ( But Django doesn’t use SQLAlchemy for ORM. It uses its own ORM layer.

And swapping SQLAlchemy in place of the Django ORM is not a trivial task. The speed gained through other means would be lost if you did. There’s a subversion branch to make this step easier.



January 23rd, 2007 at 8am

@harish: ah, yes. that’s the one

In any case, I’d recommend anyone not managing their data migration to reach for the nearest solution and just start doing it already!.

In Affle, where we have many platforms, we use our own python script instead of Rails Migrations. The important thing is, migration *is* managed.