

How we seamlessly moved from PHP to Django over 22 months - weswinham
http://devblog.policystat.com/php-to-django-changing-the-engine-while-the-c

======
caillou
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?

~~~
variety
_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.

~~~
caillou
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, ...

------
bwooceli
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.

~~~
weswinham
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 :)

------
wvenable
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.

~~~
weswinham
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

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

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

~~~
weswinham
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.

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

~~~
weswinham
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 :)

