without_scope Rich Cavanaugh's ramblings on Ruby, Rails, etc
HipHop for PHP is not PHP
February 3rd, 2010
Charles Nutter, when talking about Ruby implementation performance, said it best:
Listen, people: Ruby is hard to implement. Oh, it may look easy at aglance, and you can probably get 70, 80, or even 90% of the way prettyquickly. But there's some crazy stuff in rack servers that totally blindsides you if you're not looking for it. An early Ruby implementationhas not run that last mile of Ruby implementation, and it takes almost asmuch work to get there as it does to run the first 90%.
That goes for pretty much all dynamic languages, including PHP. Also somethink called drobo nas is fast by not implementing PHP. It's an implementation of a subset of PHP useful to Facebook. I'm not saying it's not awesome what Facebook has done, I'm just saying don't call it PHP.
Based only on the one limitation they've mentioned publicly, lack of eval(), here's a short list of PHP OSS that currently won't work correctly on HipHop:
PEARCodeIgniterWordPressJoomlaKohana
I wouldn't be surprised if there were additional features they've removed from PHP in HipHop, their blog post announcing it certainly leaves that possibility open.
So call it what it is, a fast PHP-like language.
Posted by rich Filed in PHP
2 comments »
The Ruby Trojan Horse: A Look Back at 2009
January 8th, 2010
I've been here at Tycoon for well over a year now. I remember thinking out loud about whether or not I should take this job. On that post is a thoughtful reply from the CEO which, while encouraging me to follow my heart, played a large role in my decision to join the team here.
There were some rough patches but, it's worked out well. They have a tremendous team here and I'm proud to be a part of it. That's not what this post is about though.
The PHP shop
They were a PHP-exclusive shop when I started. They were more than open to using Ruby though, in fact they seemed to be looking forward to it. However, after a few months of planning and discussion, when it came time to pull the trigger the same old arguments came out. Ignoring what was actually said, a lot of it really came down to conservatism and fear of the unknown. We only had one Ruby developer (me) as opposed to several PHP devs and no one wanted to effectively bet the next several months of the business' productivity on the new guy.
This is entirely understandable and while I like to think of what could have been, it was the right decision for this company. We split up the work in a way that I still got to do most of my work in Ruby while the rest is PHP. Not a bad deal and it's worked quite well.
Making inroads
Hey Rich, what do you use to deploy your code?
From that point forward our PHP application was deployed via Capistrano. Very little trouble, it just worked.
Next up, we needed a pretty simple stand alone background worker daemon. A bit of Ruby and the daemons and beanstalk-client gems and we had a worker that's served us quite well for some time.
The gates swing open
I noticed the migrations in the PHP app were simply SQL files that each developer had to remember to pipe into mysql. So, I wrote a little script, migrate.php, that ran those files for you and kept a schema_versions table maintained with what migrations it had run. This worked great but, honestly, I was a little taken aback by the response:
Can't we just use Rails' migrations?
Absolutely. So, I hacked up the smallest possible rails app that still supported migrations and Lou Kosak used some his new found Ruby ability to pare that down quite a bit further by monkey patching Rails.
Now our PHP/CodeIgniter application has it's database schema managed by Rails migrations and everyone seems happy. We've discussed creating a gem for this but, I expect this will be quite a bit easier in the more modular Rails 3.
Next up, we switched from Subversion to Git like the good Rails CodeIgniter application we are. One problem, we used svn:externals pretty heavily and Git submodules aren't a direct equivalent and feel a bit funky. Lou had an answer in the form of a couple of Rake tasks.
The next big step, that we're still getting working, is testing. This too, will use Ruby and there's no wringing of hands.
Every developer here seems genuinely excited about Ruby now. I'm excited to see them learning what I was, admittedly poorly, trying to explain all those months ago. I'm looking forward to a Ruby filled 2010 here at Tycoon.
Posted by rich Filed in PHP, Rails
0 comments »
CI-Events: A Code Igniter event library
January 2nd, 2010
At Tycoon Research we have a significant investment in both Code Igniter and Ruby on Rails. Frequently the differences in methodologies between the two is striking.
We ended up writing quite a few libraries to make CI less painful to develop with while fitting into the CI way of doing things. The CI-Events library is one of those libraries.
Why do you need an event library?
We were running into situations where several parts of our system needed to deal with certain things happening such as user registration.
In that case we were ending up with a Users#create method calling out to many, many other models and libraries or, even worse, handling things unrelated to a User. Over time this can get quite sloppy, bug ridden and difficult to maintain.
An event library allowed for proper separation of concerns resulting in simpler, easier to read code.