⇥ The violin-playing software designer

What is beautiful code? Ask ten people, and you will probably get ten different answers. Ask them what makes a programming language beautiful, and you’ve got yourself the beginnings of a holy war.

For example, I have grown very tired of people telling me that PHP is an ugly language that promotes poor coding practices. PHP is, in fact, a great language, and its perceived ugliness is precisely what makes it so beautiful.

To me, at a visceral level, code is art. Beautiful code doesn’t just work well, but is pleasant to look at, examine, explore and understand. Like a painting, coding starts with an empty canvas—your editor window. Your language provides you with the tools and a palette that you can use to sketch, draw and paint your work of art.

Like with a real painting, it’s your personal abilities that dictate the quality of the end result. Languages and development platforms only provide you with the ability to realize your vision—or not.

This is why the best language is one that comes with sharp edges. Imagine someone forcing Leonardo to draw the Mona Lisa with erasable markers because oil-based paint would stain the furniture, or Edvard Munch having to create The Scream with crayons (ok, that’s not that much of a stretch, but stay with me) because he had a habit of eating his brush.

A good language is a language that gives a programmer the ability to experiment while imposing as few constraints as possible. If someone came to you and said “I’ve got this great idea for a painting of a bride… it’s great! It’s even got a violin-playing goat!” You’d probably think they’re insane—but what if they were Marc Chagall? Not so crazy now, eh?

PHP is the ultimate development platform—with the appropriate amount of discipline, you can use it to great truly outstanding code that can adapt to almost any development methodology. Of course, you can write spectacularly bad code with it, too, but that’s part of the bargain. Python is like that, too—as demonstrated by its application to a range of problems as diverse as mathematical research and game development.

It could be argued that not everyone is Leonardo, Edvard Munch or Marc Chagall, and that the vast majority of developers are better served by the paint-by-numbers approach of RoR and the likes. I prefer to think, instead, that the vast majority of developers is best served by a language that gives them a chance to stretch their wings and learn from their mistakes.

This, incidentally, is why I am scared—really scared—of the fact that so many post-secondary institutions have started teaching com-sci using Java instead of C. We are essentially breeding a generation of developers who have no real idea of the underpinnings of low-level software programming. In the short term, this may be good for the industry, but not so good for the future.

⇥ Travel plans for the whole family

Father & Son Day at the Zoo

Package includes:

• One father
• One son
• One zoo

Price $30; duration: 2 hours.

Family of Four Day at the Zoo

Package includes:

• One father
• One mother
• One son
• One daughter
• One wagon
• One large duffel bag
• Two swimsuits
• Two large towels
• Sunscreen
• One bowl of strawberries
• One bowl of grapes
• Two pairs of sunglasses
• No less than two (2) arguments with $child who doesn’t want to move/stay still/eat/drink/sleep
• Complimentary seagull show at lunchtime, inclusive of “near misses”
• Guaranteed fitness session for the father (includes wagon pulling, child lifting and credit card swiping)

Cost: $150; duration 3 hours / 6 hours inclusive of travel, packing and unpacking.

⇥ Gambling the bill

My friend Peter was in town yesterday, so we made it a night out, as we do whenever we’re in the same place at the same time. An evening with Peter is always interesting, and last night was no exception—not the least because we got to introduce Arbi to a nice little game.

The game works like this: one of the people at the table gets the bill. Since we don’t exactly eat out at Mickey D’s, after the initial moment of desperation, the recipient of the bill then proceeds to propose that he and the other diners play a little game to decide who the lucky payer of the bill will be.

The game is simple, and extremely diabolic at the same time. One person—let’s call him or her the host—chooses a number between 1 and 1,000. The number is written down on the bill (so that the host can’t cheat his or her way out of “winning” the game), but in such a way that the others can’t see it.

At this point, all the people at the table take a turn, in rotation, trying not to guess the number. Each person chooses a number between the highest and lowest closest numbers until someone, the “lucky” winner, guesses the number the host chose, and has to pay up. When it’s the host’s turn, he or she must add one to the current low number, or subtract one from the current high number, instead of guessing a number (since the host knows the “winning” number). The host can do either, but once he picks one action (either add one to the low, or subtract one from the high) he must do the same thing every time.

For example, suppose the host picks 455, and there are three people at the table. The game could go like this:

• Player 1 chooses 233, which is low. The game’s numbers are now:

  233
  x
  1,000

• Player 2 chooses 768, which is high. The game’s numbers become:

  233
  x
  768

• The host must either add one to the lowest, or subtract one from the highest. She chooses 234:

  234
  x
  768

• Player 1 now chooses 451, which is low again:

  451
  x
  768

• Player 2 chooses 499, which is high again:

  451
  x
  499

• The host chooses 452:

  452
  x
  499

• Player 1 chooses 459:

  451
  x
  459

• Player 2 chooses, 456:

  451
  x
  456

• The host chooses 452:

  452
  x
  458

• Here, the game starts getting interesting, because the two players have an opportunity to bottle the host into “winning”—while at the same time having a 1:5 chance of losing themselves. Player 1 chooses 454, getting dangerously close to winning:

  453
  x
  458

• Player 2 chooses 455, “winning” the game and saving the host from paying the bill.

This is a silly little game, but it has a few powerful characteristics that make it an excellent business tool.

First of all, it’s played for money—and all players must be merciless. There’s nothing like the possibility of getting stuck with a $200 bill to make an otherwise dull night exciting—it’s not Montecarlo, but it will be memorable for all people involved. Second, the loser won’t easily forget how he or she lost the money (as a side note, if you play this game long enough, whoever takes your expense refunds is likely to start asking questions about why they’re full of numbers… so be prepared to offer a creative answer), and will want to exact revenge; similarly, the winners will think they got a great deal out of it, and will want to play again—making for a great excuse to schedule a meal with you in the future. Heck, for once you may manage to stick it to a client all the while making him happy for footing the bill!

⇥ Challenge #4 is here!

As promised, I have a new challenge ready for my readers… I hope you won’t hold the fact that it’s been almost two whole months since the last one against me! My only defense is that I’ve been too busy.

I am changing the rules slightly for this round due to some complaints I received stating that the first three challenges were too “timezone-sensitive,” meaning that those folks who happen to be awake when I am have an inherent advantage in terms of additional time to solve the puzzles compared to those who aren’t. I just hope that this isn’t the beginning of one of those “you’ve got to make it fairer” trends that one of these days are going to cause the Universe to collapse onto itself…

Thus, in the interest of fairness, from now on I will select the winner using this method:

• If one or more correct solutions are received within the first 24 hours of the posting time of the challenge, the winner will be selected at random among those correct solutions.
• If no correct answers are received within the first 24 hours, then the first one to send in a correct solution wins.

Without further ado, here is this month’s challenge:

245 431 356 237 33 29 467 123

This challenge, like the previous two, is completely self-contained. I’ve given you a key, and if you can’t see it… you’re just not looking hard enough! Perhaps it’s time to give this site another look, or use a bit of good humour.

And the rules, as always:

• If one or more correct solutions are received within the first 24 hours of the posting time of the challenge, the winner will be selected at random among those correct solutions.
• If no correct answers are received within the first 24 hours, then the first one to send in a correct solution wins.
• Solutions must be sent to me via e-mail. I am not responsible for e-mail messages that get lost in any way, and the timestamp on my end is the final judge of who gets here “when.” If you win, you agree to allow me to post your name (and URL if you like) here—just so that everyone else knows I’m not making the winners’ names up.
• The riddle does have a solution—but it is, of course, possible that I have made a mistake in calculating it. In that case, I will void the contest and post a correct one.
• The winner will receive a $50 gift certificate that can be spent at the php|architect online store on any product, without any limitation, so long as the entire $50 is spent on a single order (sorry, that’s the way our store works). The coupon will expire after one year from the date of issue.
• The contest closes on August 31, 2008, at which point I will post the correct solution if no-one has sent it to me yet.

⇥ Yeah, yeah, I’m still alive…

… I’ve just had a couple of really nasty months!

Whereas summers are usually a sleepy time at MTA, this year we ended up making several major releases in the span of forty-five days—and that has made for a very, very busy time.

As some of you may have noticed, we recently released a completely revised training program. Training has been a major source of revenue for us, but the fact that it wasn’t a properly-organized business had been bothering me for a while. While we had a great set of training courses and two killer trainers, we lacked a cohesive program that could help people from all levels of PHP knowledge increase their skill in a logical progression.

Imagine walking into a school and being confronted with Math 101 alongside advanced algebra—it’s perhaps great if you’re either a complete newbie, or if you are looking for a challenge, but, if you’re somewhere in between… you’re in trouble.

This is the kind of problem that we aimed to fix with our new program, and it took us a considerable amount of research and development to get there—Paul started discussing the possibility of coming up with a new training program sometimes in February.

I have to say I am rather proud of the end result. We now have a complete set of training courses that feed into each other in a nice and logical manner—progressive from an introductory PHP course all the way to advanced topics, including what I believe is one of the only courses dedicated to learning Adobe Flex from a PHP developer’s perspective in the world (which I will be teaching!).

Coupled with a completely new backend system that finally allows students to manage their own training directly without the intervention of our customer support folks, I think that our new training program will be a great addition to the PHP world.

We even have a completely revamped training system, written entirely from scratch to provide support for a host of new features (Project #2 for yours truly). The new system expands on our previous training technology to include several features that were sorely missing—things as simple as seeking through recordings (which is much more complicated to implement than one would imagine), but also elements like integration with S3 for security and scalability, which will help us relaunch our webcast series shortly.

Rewriting the training system (or, as I prefer to call it, the “straining” system) was a huge challenge, partly because I kept butting against some of the arbitrary limitations built into the Flash and Flex frameworks by Adobe (although they are getting better at making their products more open to everyone), and this time I wanted to resolve those conflicts intelligently rather than just hacking around them like I did the first time (which, come to think of it, was three years ago!). I’m quite happy with the end result, and look forward to deploying it in the real world.

In any case, it seems that a new challenge is much overdue, so I’ll get thinking. In the meantime, PHP 4 is dead… I’m going to the wake.