Monthly Archives: April 2007

If you're so religous why did you choose that job?

Posted on by
Reply

Today the Metropolitan Airports Commission voted 11-0 in favor of penalties for cab drivers who refuse to transport drivers who are carrying alcohol and other legal merchandise that might be against Muslim religion. Now, if we could get the American Pharmaceutical Association to do the same for those religious zealots that refuse to hand out birth control and the day after pill we’ll be all set.

Seriously, if you’re such a religious zealot why on God’s/Allah’s green earth are you performing said job? I know that I, personally, would never take a job that might require me to ignore my own moral compass, so why did you?

What’s next? Jewish waiters refusing to serve me bacon?

I'm going to Thailand

Posted on by
2

Well, it’s all set in stone. I bought a ticket this morning whose final destination is Bangkok, Thailand. I’m planning on spending a few days in Bangkok and then taking a flight down to the Surat Thani Province for the Koh Phangan full moon beach party.

If anyone has any input on what gear I should take with me, any sites I should definitely see, etc. I’d love to hear about it. Post it in the comments for all to share.

Quote of the day

Posted on by
Reply

I was reading TrueHoop today regarding the Don Imus situation and read something that, with a little modification, makes a great quote.

Did you ever think we’d have a world without people acting like idiots? Ask any grade school teacher. There are always one or two.

The great thing about free speech is that it encourages those people to identify themselves …

My revised version of the above is as follows.

The great thing about free speech is that it encourages idiots to identify themselves.

Don't say I didn't say I told you so

Posted on by
Reply

I’ve had, shall we say, heated debates with a few of my friends about the stability of Ruby on Rails. After hearing about the way Ruby on Rails handles database interactions I was fairly convinced that it would make serious scaling a huge pain in the butt. Today, by way of an interview of a Twitter developer, comes the answer I’ve been expecting:

Running on Rails has forced us to deal with scaling issues – issues that any growing site eventually contends with – far sooner than I think we would on another framework.

…

All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.

…

It’s also worth mentioning that there shouldn’t be doubt in anybody’s mind at this point that Ruby itself is slow.

I knew ActiveRecord was a pile of crap from the minute I read in their documentation that it was “only” 50% slower than going straight to bare metal. Combine that with the fact that you can’t connect to more than one database server, force indexes or do other various MySQL-specific DB foo and you’ve got a recipe for disaster once you hit a certain amount of traffic.

Writing phpt files for PEAR and profit

Posted on by
Reply

I’ve been programming PHP now for, oh, almost a decade and I’ve been a contributor to PEAR for about four years now. It took me this long to finally get to the point that I think writing unit tests, in some form, is a good idea. I jumped on the OOP bandwagon about 6 years ago and drank the MVC koolaid about 4 years ago. As of a few weeks ago, I’ve jumped on the phpt bandwagon. I’m not going to cover the basics, because they’re well covered in a few different places around the web, but I am going to cover some of the nuances I’ve learned in the last few weeks.First off, you can run phpt files using the PEAR command line utility. I’ve been creating a tests directory and putting all of my phpt files in there. I normally name them 000-class-method.phpt and then increment the sequence number at the front for each test by 5 so I can do a decent job of predicting how tests run. Once you have a few tests you can run your tests in two different manners from the command line:

  1. pear run-tests
  2. pear run-tests 000-class-method.phpt

When you run your tests you’ll get results of which tests passed, which failed, if any of them were skipped and the reason why they were skipped, and files for debugging. If 000-class-method.phpt fails, there are a few files that will be of interest to you:

  • 000-class-method.php is the actual PHP file ran, which is found in the --FILE-- portion of your phpt file.
  • 000-class-method.outis what was actually output by the PHP file ran from the --FILE-- portion of your phpt file.
  • 000-class-method.exp is what the test expected the output of 000-class-method.php to be, which is found in the --EXPECT-- portion of your phpt file.

You pretty much have everything you need to debug why a test failed. I normally diff the exp and out files and then debug the test (or my code, which is usually the case) using the php file.

Another great thing about phpt files is that you can use a cgi PHP binary to debug actual GET requests (phpt supports spoofing $_GET, $_POST and $_COOKIE using the cgi binary). This lets you create tests like the following:

--TEST--
Test a GET request
--GET--
foo=bar&baz=foo
--FILE--
<?php
echo $_GET['bar'] . "\n";
echo $_GET['baz'] . "\n";
?>
--EXPECT--
bar
foo

This test should pass without incident. The only catch is that you need to specify your cgi binary path using the --cgi argument when you run the tests (e.g. pear run-tests --cgi=/path/to/php-cgi).

Overall, I’m pretty happy with my newfound testing experiences. My only complaint is that phpt files don’t support spoofing of $_SESSION natively. A small complaint to be sure.