Programming Languages

Practice…but not typing

A post by Karl Martino reminded me of Jeff Atwood’s We are typists first, programmers second. Atwood was responding, in hearty agreement, to a post by Steve Yegge, who wrote

I was trying to figure out which is the most important computer science course a CS student could ever take, and eventually realized it’s Typing 101.

The really great engineers I know, the ones who build great things, they can type.

As I wrote in Karl’s comments, saying that fast typing is what makes a great programmer is little different than saying what makes a good carpenter is how fast they swing their hammers.

Fast typing is a by-product of extensive creation, whether that creation is web page markup, a stylesheet, or code. The more we create code, web pages, and designs, the more efficient we get with all of the tools used, including but not limited to, typing.

In addition, times have changed. I have no doubts that today’s generation of kids are speed demons on the keyboard—whether it’s on their cellphone or attached to their computers. A typing class would most likely slow them down.

If anything, what we should be encouraging is more practice with problem solving—the ability to figure something out on one’s own, without having to Google an answer or ask friends on Twitter—not typing.

Programming Languages

Learning something new in PHP

Recovered from the Wayback Machine.

didn’t know the ?> closing tag was optional with PHP code only files, either. I did know about white space following the end tag. Probably every PHP developer knows about the white space following the end tag problem.

What header? What ******** header!?

Other useful stuff on PHP best practices at the Drupal site, with more detail on omitting the end tag.

Question to those who know Drupal: how is it on supporting XHTML? Both published and consumed via comments?

Graphics/CSS Programming Languages

Experiments in Color

I’ve written about this previously, but worth repeating. CSS can be dynamically created using a PHP application, as long as the content type is set to CSS:

<?php // declare the output of the file as CSS header('Content-type: text/css'); ?>

The style sheet can then be used directly or imported into another:

@import "photographs.php"; I use this feature to randomly assign a background image for my header and also to access the color of select pixels in the image in order to colorize the theme based on image. I based the points on the photographer’s “rule of thirds”, which puts the focus on the photo along an imaginary line, either along the top or bottom horizontal third, or the left or right horizontal third. I also pick a pixel directly in the middle of the image. I could test all pixels and find the most common colors used, but the amount of processing is prohibitive. I’ve haven’t seen this algorithm fail when it comes to creating a compatible color set, yet.
fishie.jpeg (JPEG Image, 818x195 pixels)

I use the built-in graphical GD functions in PHP to pick the color points, as well as find the size of my background image, and adjust the header accordingly. I could also have used IMagick, the PHP-based wrapper for ImageMagick, but GD is almost universally available on web hosts, while IMagick is not.

// create a working image 
$im = imagecreatefromjpeg($imgname);

// get image height and width
$height = imagesy($im);
$width = imagesx($im);

// sample five points in the image, based on rule of thirds and center
$rgb = array();

$topx = round($height / 3);
$bottomx = round(($height / 3) * 2);
$lefty = round($width / 3);
$righty = round(($width / 4) * 2);
$centerx = round($height / 2);
$centery = round($width / 2);

$rgb[1] = imagecolorat($im, $topx,$lefty);
$rgb[2] = imagecolorat($im, $topx, $righty);
$rgb[3] = imagecolorat($im, $bottomx, $lefty);
$rgb[4] = imagecolorat($im, $bottomx, $righty);
$rgb[5] = imagecolorat($im, $centerx, $centery);

// extract each value for r, g, b
$r = array();
$g = array();
$b = array();

$ct = 0; $val = 5000;
// process points
for ($i = 1; $i <= 5; $i++) {
   $r[$i] = ($rgb[$i] >> 16) & 0xFF;
   $g[$i] = ($rgb[$i] >> 8) & 0xFF;
   $b[$i] = $rgb[$i] & 0xFF;

   // find darkest color
   $tmp = $r[$i] + $g[$i] + $b[$i];
   if ($tmp < $val) {
       $val = $tmp;
       $ct = $i;


   printf(".color1 { fill: rgb($r[1],$g[1],$b[1]); stroke: rgb($r[4],$g[4],$b[4]); }\n");
   printf(".color2 { fill: rgb($r[2],$g[2],$b[2]); stroke: rgb($r[3],$g[3],$b[3]); }\n");
   printf(".color3 { fill: rgb($r[3],$g[3],$b[3]); stroke: rgb($r[2],$g[2],$b[2]); }\n");
   printf(".color4 { fill: rgb($r[4],$g[4],$b[4]); stroke: rgb($r[1],$g[1],$b[1]); }\n");
   printf(".color5 { fill: rgb($r[5],$g[5],$b[5]); }\n");

   printf("stop.begin { stop-color: rgb($r[1],$g[1],$b[1]); }\n");
   printf("stop.middle   { stop-color: rgb($r[5],$g[5],$b[5]); }\n");
   printf("stop.end { stop-color: rgb($r[4],$g[4],$b[4]); }\n");
   printf(".nameExpanded, .nameCollapsed { background-color: rgb($r[4],$g[4],$b[4]); } \n");
   printf(".column-post h2, .column-post h2 a, .firstpost, 
                .firstpost a { color: rgb($r[$ct],$g[$ct],$b[$ct]); } \n");

To ensure that the title and title bars contrast strongly enough to be viewable, I test the selected colors for the ‘darkest’, ie the less saturated of colors. Adding up the RGB separate values does the trick: a value of RGB(0,0,0) totals to 0, while one for RGB(255,255,255) totals to 765. Everything else falls in between.

Again, the reason for doing this type of adjustment is not only to add an interesting, and changing element, to the site interface, but also to demonstrate what can be done with both images and CSS. Neither is static, and none of the modifications requires scripting on the client, and many of the modifications aren’t impacted by browser type.

For more details on the processing, access the viewable copy of the PHP program.

Programming Languages SVG

Color sampling and SVG gradients

More fun with SVG.

I’m rather surprised there isn’t more general ‘design’ work using SVG. True, you really should have your pages as XHTML and not many people are ready to jump on that bandwagon. Still, once you’ve bit the bullet, you can have a lot of fun with your pages and incorporating SVG.

My newest experiment is actually combining PHP image functions with dynamically generated CSS entries, which also control the random photo header. All the SVG elements are dynamically created based on colors sampled in whatever is the current header image. I used the photographer’s ‘rule of thirds’ to pick four outer points and then sampled the middle. I use the sampled colors to generate CSS values used to style 4 small circles in the top of my sidebar and rounded-corner gradient-filled ‘caps’ to my individual comment entries.

I had to make some tweaks to make the gradient comments work. First, the SVG element had to have the display setting set to ‘block’ in CSS; otherwise, the browsers generated space following the object. I’m assuming that the SVG element is treated like the IMG element is in strict XHTML mode: treated as an inline element, and given a ‘text descender’ space. Second, just as with images, fixed widths work best for gradients, and the viewport for each SVG element has to be fixed to work with Safari 3.

The gradients don’t work with Firefox 2.x if you access the page using a page fragment, such as clicking on a specific comment. This is a bug that has been fixed in Firefox 3.x. It does work with the latest Opera and Safari 3. The page degrades nicely for non-SVG browsers.

I’m not sure if I’ll keep the SVG effects, or even take it further with creating entire page color schemes based on color sampling of the image. I may look at embedding additional data directly in the images to control both the CSS and the SVG.

I do want to implement ‘caching’ for the ‘blog pulse’ I created earlier. The best time to cache the pulse would be each time a new comment is saved, probably to a database table I’ll create for other uses. The color sampling, though, may not need caching. The gradient effect can be a little slow, but most of the ‘slowness’ is from the fact that the header image is quite large. Then there’s the random selector for the image–I imagine this can be improved through the use of caching.

Frankly, I don’t load my sidebar with dozens of widgets, hook into that abysmal google syndication service, nor do I embed dozens of YouTube videos in my posts. My little use of SVG is nothing compared to all of this, and, unlike the other services, doesn’t impact on the loading of the page contents.

Still playing. I’ll worry about performance when I’m finished playing.

For your own playing: SVG is in page, PHP dynamic modification code, import into your CSS file using: @import “photographs.php”;

The only drawback to all of these changes is Internet Explorer. None of this is going to work with IE. None of what I’m doing, though, impacts on the page layout, or the text or even the generated CSS style settings. The IE users won’t get some of the effects, but they’ll get the weblog content. I’m not going to try and use Silverlight or VML or a plug-in to work around these issues, either. I figured if the Microsoft people don’t care that their users are missing out on the fun pieces of the web that’s Microsoft’s problem, not mine. That browser has killed too much of my fun over the years–enough is enough.

Programming Languages

Perfect example

Recovered from the Wayback Machine.

Here’s a perfect example of how the computer field is broken:

In a post at Coding Horror, based on earlier posts at Imran on Tech and Raganwald, the author parrots what the others state, that programmers can’t program. With lots of exclamation points.

Why make such a breathtakingly grandiose claim? Because of what happens in interviews. It would seem that the originator of this newest fooflah created a series a tests given during the interview process and found:

After a fair bit of trial and error I’ve discovered that people who struggle to code don’t just struggle on big problems, or even smallish problems (i.e. write a implementation of a linked list). They struggle with tiny problems.

So I set out to develop questions that can identify this kind of developer and came up with a class of questions I call “FizzBuzz Questions” named after a game children often play (or are made to play) in schools in the UK. An example of a Fizz-Buzz question is the following:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

Most good programmers should be able to write out on paper a program which does this in a under a couple of minutes. Want to know something scary? The majority of comp sci graduates can’t. I’ve also seen self-proclaimed senior programmers take more than 10-15 minutes to write a solution.

Jeff Atwood of Coding Horror also goes on to quote others who run into the same problems: interviewees can’t seem to do even the simplest coding tasks during interviews. These gentlemen completely ignore the environment and focus on the grossest of generalities:

Programmers can’t program.

Here’s a clue for you: I don’t do well in programming tasks during interviews, and I’ve love someone to come into my comments and tell me I can’t program based on this event. No, I’ve only faked it while working for Nike, Intel, Boeing, John Hancock, Lawrence Livermore, and through 14 or so books–not to mention 6 years of online tech weblogging.

In fact, you’ll find a lot of people who don’t necessarily do well when it comes to programming tasks or other complex testing during job interviews. Why? Because the part of your brain that manages complex problem solving tasks is the first that’s more or less scrambled in high stress situations. The more stress, the more scrambled. The more stressed we are, the more our natural defensive mechanisms take over, and the less energy focused into higher cognitive processes.

Why do you think that NASA, the military, and other organizations training people for high risks jobs spend so much time in simulation? Because they want the tasks to be so ingrained that in a stress situation, the people’s responses are almost automatic.

If you add the potential for embarrassment on to the strong desire to do well, the need to get the job, toss in a panel of arrogant twats sitting around a table looking directly at you while you do your little tests, and you have the makings of an environment that almost guarantees the elimination of many fine candidates.

Who does well in these kinds of testing situations? Good testers, the supremely self-confident and equally, typically arrogant, and the people who don’t care: none of which is necessarily the best candidate.

The whole purpose of tests such as these are not to determine if a person has programming capability–how can one stupid test determine this? What these tests do, though, is add to the self-consequence of the person doing the interview.

“I can do this, but all these people can’t. Therefore, I’m so much better.”

It’s also a lazy interview technique, which shows that HR associated with the company doesn’t give a crap about the IT department.

Some justify such tests with, “We need people who can do well in stress situations.” Bilge water.

The stress one goes through when one is an outsider faced with a bank of insiders, is completely different than the stress an individual goes through when they’re part of a team trying to fix a problem or roll out a product. Comparing the two is ludicrous, and nothing more than a demonstration of completely two-dimensional thinking: one form of stress is completely the same as another. My god, no wonder we’ve had few tech innovations lately if this is demonstrative of leadership in IT.

Having candidates bring in samples of code and having the interviewer and interview team review such, and question why decisions were or weren’t made is an excellent way of getting insight into the person’s problem solving skills, without the trained dog and pony show. Asking a person what approach they would use in a situation is superior to doing a random memory test on keywords. Providing applications and having the person provide their own critique is an amazingly effective way of getting insight, not only into their problem solving skills, but also into their personality. If they point out errors but do so in a thoughtful manner, it’s a heck better than doing so in as scathing a manner as possible.

Looking at past applications or effort is another effective approach. New programmers with no job experience can provide pointers to open source applications; experienced people who have worked in an NDA situation can provide pointers for discussions and work online: heck, Google the person’s name–that will tell the interviewer much more about the person than a silly programming test.

That primitive techniques such as the abysmally stupid “FizzBuzz” approach are used shows that companies are still missing out on good people because they have idiots doing most of the interviews.

And making the leap between how people do on interviews into such grand claims that programmers can’t program demonstrates that idiocy travels up the food chain.

You know what’s especially humorous? All the people who solve the test questions in the comments. What possible reason would a person have to do such a thing? It’s completely irrelevant to the environment in which these so-called tests are given. This no more shows that these people can program, then it shows that the other people can’t.

The lack of logic in this whole thread is amazing.

What’s less funny, though, is the slavish adherence to Joel Spolky’s elitist crap. Joel runs a smallish computer company with limited products: what the hell makes him the definitive answer on these topics? Perhaps the people should spend less time making pronouncements, and more time developing independent thinking skills.

Many of the comments in the Coding Horror post do mention these concerns, and provide other effective approaches to interview. If the people who create these tests will actually read these responses, some good will have come from the discussion.

I have found, though, that people who write these kinds of tests aren’t always willing to considering other options. The other approaches just aren’t ‘clever’.