Blog of Leonid Mamchenkov

The conference day.  We woke up early to get in queue at registration which opened at 08:30.  When we got to the Olympia Conference Center, which was about 5 minutes walk from our hotel, it was full of people.   More than a hundred people already, and we were early.  Got our badges and notepads, grabbed a coffee, and started wondering around.  There were a few sponsor stands, so we had something to do.

Honestly, I thought there would be more stands, and from companies which are closer related to web development.  We got to O’Reilly to buy some books at 35% discount (I was the first customer of the day, beta-testing the receipt issuing procedure, hehe).  Looked at iBuildings stand briefly.  Looked at Sun MySQL something to do with reporting tool something.  It was crowded over there and I had a cup of coffee in my hands, so didn’t get too close.  Saw a few people playing with Wii and some more with MS Xbox 360.  Seemed like fun.

The conference itself featured a few talks, and it was a double track, so each attndee had to chose from one of the two concurrent speeches which to attend.  Here are the ones that I went to:

• Keynote talk: The future’s so bright, I gotta wear shades by Aral Balkan. It was a bit too lengthy for the points it made, but inspiration non-the-less.
• Sharding Architectures by David Soria Parra.  Very interesting discussion on scaling database across several servers. Sharding technique described can be applied to much more than just that.
• Of Lambda Functions, Closures and Traits by Sebastian Bergmann.  A look into some advanced features of PHP 5.3.  These will make writing PHP code a bit more fun, and result a bit more pleasant to look at.
• Living with Frameworks by Stuart Herbert.  Nice, balanced look at why frameworks are important.  It was a bit misplaced though, since it was more for people who don’t yet use frameworks, while most of the audience was from the frameworks camp.
• Myphp-busters: symfony framework by Stefan Koopmanschap.  An overview of Symfony framework, which made me love CakePHP even more.
• Security-Centered Design — exploring the impact of human behavior by Chris Shiflett. Interesting descussion (with cool examples) of social part in security approaches.

Sharding Architectures and Lambda Functions were two of my favourite talks for technical insight.  Security-Centered Design and Living with Frameworks were the two favourites for non-technical inspiration.

After the last talk there were a few free beers at the venue, and after that there was another beer session at Brook Green Hotel.  Quite a few people, quite a few pints, quite a few interesting conversations and contacts made, excellent buffett, and overall a time well spent.

A note to conference organizers: I know you guys worked hard to make this happen, and that you are a bunch of hobbyiests who are not getting paid to do this, so, first of all, thank you.  I really enjoyed the event.  Here are a few things that I think could be improved, just in case  you will have control over them the next time:

• WiFi coverage.  Yes, it was there and it was sort of working, but it was also slow and unstable.  At the beginning I thought that was just me for some reason, but then heard a few more people complain.
• Power sockets.  I remember seeing only 3.   Maybe I just didn’t find them, of course, but they are sort of important.
• Beer is the ultimate conversation maker.  Have it nearby from lunch on and more magic would happen.  (It doesn’t have to be free)
• Mechandize.  Stickers, t-shirts, badges, etc to help remember and promote the event.
• More stands.  I wanted to see people who do hosting, consulting, trainging, build tools, and more of the related.

As I said, I had an excellent time, learned a few new things, got inspired, met interesting people, etc.  An event was definitely a success and I’d gladly attend the future ones as well.  Oh, and I made a few pictures, which are available in my PHP UK Conference 2009 Flickr set.

During the last few month I’ve been explaining software engineering to management types quite a bit.  Most of the “bosses” that I talked to weren’t technical at all, so I was trying to stay away from famous concepts, examples, and terminology as much as I could.  Of course, that required some sort of substitute for concepts, examples, and terminology.  I’ve tried analogies from different unrelated areas, and was surprised as how good cooking was fitting the purpose.

Before I go any further, I have to say that I am not a cook and that I don’t know much about cooking.  But.  I know just about the same as any other average human being.  Which, sort of, moves me into the same category with my targets, or “bosses”, as I called them before.

Here are a few examples that worked well.

[Read more →]

I’m slowly catching up with the news stream and all the jokes of the last few weeks.  “If programming languages were religions” is a nice one.  Here is PHP, which I spent the most time with now:

PHP would be Cafeteria Christianity - Fights with Java for the web market. It draws a few concepts from C and Java, but only those that it really likes. Maybe it’s not as coherent as other languages, but at least it leaves you with much more freedom and ostensibly keeps the core idea of the whole thing. Also, the whole concept of “goto hell” was abandoned.

And here is Perl, which is my favourite programming language so far:

Perl would be Voodoo - An incomprehensible series of arcane incantations that involve the blood of goats and permanently corrupt your soul. Often used when your boss requires you to do an urgent task at 21:00 on friday night.

Check the rest of them for fun and profit.

I’ve mentioned quite a few times that I am a big fan of Perl programming languge.  However, most of my programming time these days is spent in PHP.  The languages are often similar, with PHP having its roots in Perl, and Perl being such a influence in the world of programming languages.  This similarity is often very helpful.  However there are a few difference, some of which are obvious and others are not.

One such difference that I came up recently (in someone else’s code though), was about variable scoping.  Consider an example in Perl:

#!/usr/bin/perl -w
use strict;
my @values = qw(foo bar hello world);
foreach my $value (@values) {
    print "Inside loop value = $value\n";
}
print "Outside loop value = $value\n";

The above script will generate a compilation error due to undefined variable $value.  The one outside the loop.

A very similar code in PHP though:

#!/usr/bin/php
<?php
$values = array('foo','bar','hello','world');
foreach ($values as $value) {
    print "Inside loop value = $value\n";
}
print "Outside loop value = $value\n";
?>

Will output the following:

Inside loop value = foo
Inside loop value = bar
Inside loop value = hello
Inside loop value = world
Outside loop value = world

In Perl, variable $value is scoped inside the loop.  Once the execution is out of the loop, there is no such thing as $value anymore, hence the compilation error (due to the use of strict and warnings).  In PHP, $value is in global scope, so the last value “world” is carried further down the road.  In case you reuse variable names in different places of your program, counting on scope to be different, you might get some really interesting and totally unexpected results.  And they won’t be too easy to track down too.  Be warned.

The software is checked very carefully in a bottom-up fashion. First, each new line of code is checked, then sections of code or modules with special functions are verified. The scope is increased step by step until the new changes are incorporated into a complete system and checked. This complete output is considered the final product, newly released. But completely independently there is an independent verification group, that takes an adversary attitude to the software development group, and tests and verifies the software as if it were a customer of the delivered product. There is additional verification in using the new programs in simulators, etc. A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future. Such unexpected errors have been found only about six times in all the programming and program changing (for new or altered payloads) that has been done. The principle that is followed is that all the verification is not an aspect of program safety, it is merely a test of that safety, in a non-catastrophic verification. Flight safety is to be judged solely on how well the programs do in the verification tests. A failure here generates considerable concern.

The above was written by R. P. Feynman, in Feynman’s Appendix to the Rogers Commission Report on the Space Shuttle Challenger Accident, 1986. More than 20 years ago. Much recommended reading.

Found via Richard Feynman, the Challenger Disaster, and Software Engineering.