How we seamlessly moved from PHP to Django over 22 months | Hacker News Reader

How we seamlessly moved from PHP to Django over 22 months

devblog.policystat.com

41 pointsweswinham13 comments

There are two things that strike me as odd in this report:

1) Why would you go through the process of switching the language. There are perfectly suitable frameworks in PHP, e.g. Symfony, that have the exact same approaches than Django and ROR. MVC, ORM and configuration over Convention over Configuration. Once you have a team that is good at a Language, you'll loose a lot in switching... and this leads me to the second question:

2) How can it take 22 month to rewrite this kind of application? A bit of CRUD and workflow should not take so much time.

WDYT?

1) When evaluating the options (mid 2007), Django and Ruby on Rails were the two projects with the most community momentum, and I personally put a lot of weight on that. I had used and was a fan of CakePHP, but the reality was that porting the mess that we had to either CakePHP or Symfony (the two we look most closely at) would have taken a significant amount of work. Since we knew that it wasn't possible to place development on hold, the main requirement was that whatever we did would need to live side by side with the existing code, and it was only a little bit more difficult to do that with another language and framework than another framework written in PHP.

I don't at all mean to say CakePHP or Sympfony would have been bad choices, but our technical team was such that switching languages wasn't a hurdle. I think the number of startups that have chosen Django or RoR as their platform of choice since mid 2007 in part validates our decision, but that doesn't mean other choices would have been bad.

2) It took 22 months to eliminate the last bit of PHP, but that was by no means the focus of development. During that time we made very large changes to the application based on things we learned from our customers. The reality is that no matter what technology we would have chosen, basically every single line of code would have been rewritten over the next two years. There was a little bit of us embracing technical debt in spreading the full port over 22 months: http://www.startuplessonslearned.com/2009/07/embrace-technic...

Thanks for the questions -wes

Why would you go through the process of switching the language?

Well, if you want to know the truth of it:

If that language just so happens to be PHP, then they might have a whole bunch of reasons. A lot of people just don't like PHP; don't consider it to be a very fun or interesting language to program in, and in particular, don't consider it long-term viable for large, multi-faceted projects.

I've heard a lot of that. Yet, mostly from people who've never or hardly ever used the language.

By reputation, PHP is a bit like JavaScript. JavaScript was this language nobody liked. It wasn't even considered a real language by most programmers. Some of it's design errors made it a language with low barrier to entry. Hence a lot of mediocre programmers made it unpopular with code that does not deserved to be called code.

This changed with people like Crockford and his 'JavaScript the good parts'...

It's pretty much the same with PHP. It gets the job done very easily... And once you know what you do, you can rely on it for large projects too. Especially with the changes that were introduced in the latest release: Namespaces, Closures, ...

On the one hand, kudos to a team for taking on a big project and getting it done without interrupting service. But on the other, the article does nothing to explain the why-behind-the-why. Why did this change need to happen? What benefits are they now realizing? What aspects of Django attracted them in the first place? I want the sequel to this post.

You're definitely correct that this post was light on the motivation for Django versus continuing with custom PHP. Perhaps it would be worth a follow-on post, as long as I can figure out how to not turn it in to a framework flamewar :)

In short though, we wanted to realize the obvious benefits of web frameworks over our poorly-constructed prototype raw PHP application (DRY, code re-use, reusable applications, MVC organization, testing tools etc.). We're now seeing basically all of those. Our code is clean and well-constructed because we were able to lean on the wisdom of the Django community. We use fully 24 different reusable Django applications, along with a couple dozen python libraries. Whenever we face a challenge, more often than not we can find a great blog post from the community that addresses a very similar issue and sometimes we can contribute back a little bit. When we hire new people, we can point them to Django's great documentation if they're new to Django, or they can jump straight in to our project and feel at home because it looks like basically every other Django project.

We're very very happy with Django and what it's given us over our own raw PHP. Other frameworks, like RoR would have given most if not all and more of these benefits, but the important thing in my opinion is that if you're doing a web application, you find a web framework that meets your needs. Honestly, when it came down to evaluating frameworks, it was RoR versus Django because that's where the community was. For me, it was Django because I like python's "one obvious way" versus ruby's many ways, which is a purely aesthetic judgement that plenty of people much more qualified than me make in the other direction. Once I realized that both of them would do a great job solving the problems our business was facing, I just made a decision and started writing code :)

That is very much a good way to do it. However for 22 months, I was expecting a larger project than one with 45 php files.

We definitely could have ported the entire thing in under 22 months if that was our goal. The goal was actually just to make product improvements and gather customer feedback as fast as possible in the time we had, and the porting from PHP to Django just kind of naturally fell out of that. For example, the only PHP left for quite a while were the index and login pages. Until we actually needed to touch that code again for other reasons (a bit of a UI refresh), it didn't make sense to port that piece. It was working just fine and we had (and still have) a lot of other things that are important to work on instead.

Also, for about 2/3 of those 22 months, the development, operations and support team were the same guy, so that does have some impact :P

What is the performance difference (page load, processor load, memory load) after switching?

Nice hack on the session sharing. "2. Build a Django Session Engine using phpserialize to speak PHP's serialization format"

That was definitely the eureka moment that made us realize that it was possible. I'm pretty sure someone on the django users mailing list actually pointed me to the phpserialize library, which was the key to the whole thing.

I would very much like to see his Apache vhost.conf file!

Sure thing. I'm going to try and get together a follow-up post with some of the php session engine details and the apache configuration we went with. Hopefully you'll find it interesting :)

Reply on news.ycombinator.com