Smart & Gets Things Done: Ideas for the programmer

Smart & Gets Things Done by Joel Spolsky was one of the items on my Amazon.com Christmas wish list. Thanks to my wonderful mother, I happily received a copy Christmas morning and spent most of the day reading it. The whole thing. It was very interesting, and it changed what I look for in a potential employer.

While at present I may not yet be the top-notch software developer Joel describes (I’m still in college, which I suppose justifies that), the book at least gives me some ideas about (a) what I can do to become such a programmer, and (b) what I can expect if (when?) I do reach that level and look for a “real” job.

The top-notch developers who can “hit the high notes” (chapter 1) can afford to be picky about where they work, with whom, and in what conditions, simply because they’re just that good. For the companies that want to hire them, the game changes from one in which the company has something that the candidate desperately wants to one in which the candidate is the thing the company desperately wants.

At the peril of extrapolating Joel’s thoughts far beyond their originally intended scope, I offer some suggestions to myself (and any other budding programmer who wants to “hit the high notes”):

1. Be passionate about what you do. Work on projects you like doing, whether that’s hacking around with Perl or writing a FORTRAN compiler in assembly language. A skilled programmer with passion and aptitude (as Joel points out in chapter 6) is much more valuable to a development team than someone who merely has a skill set. (Parenthetically, Joel also mentions that one of his standard interview questions probes the candidate’s understanding of pointers and recursion. If you grok those important concepts, despite their seeming irrelevance in the face of “modern” languages, that’s a good sign.)
2. Be a good follower and a good leader. University computer science curricula don’t provide much in the way of sustained, team-based software development. But when you start working for a bone fide software company (or even doing in-house IT), you’ll almost always be on a team. For a team like that to be successful, it has to consist of developers who are flexible enough to follow (whether that’s each other or the project manager) but strong enough to lead (when there’s a better way of doing it that the manager doesn’t see). Learning those skills before you hit the workplace will be a tremendous boon.
3. Know what you want. Unless you’re really desperate, you can probably afford to be (more than) a little picky about where you work. Do some research about the company before you even apply, and when they call you in for an interview, take careful note of the experience you have. Is the boss friendly? Do the other programmers who interview you know what they’re talking about? Would you be able to work well with them? Is the office quiet and private enough to allow you to get in “the zone” while you’re programming? Are they going to give you good tools (and, perhaps, toys)? All these factors will contribute to your success and satisfaction in your job and (of primary concern to your employer) your productivity. If you’re happy and like what you do, you’ll be productive. Which is a win-win situation for everyone. So take note.
4. Stay on top of the ever-changing technology game. Java was the hip language years ago. And even though many college curricula still use it extensively, it’s not always the best tool for the job. C++, either. Learning Ruby or Python will benefit you–right now anyway. And a few years into your first job you’ll likely be learning something else. So that cool, innovative company you want to work for will value early adopters like you, because you’re cool and innovative, too. Staying on top of the technology game will give you a competitive advantage.

Well, those are my thoughts. There’s a lot that goes into becoming a great developer, but these are a few things to get you started. At any rate, Smart & Gets Things Done is an enlightening read for manager and (budding) programmer alike.

Static variable inheritance in PHP

In version 5.1 of PHP, classes can override static variables. But there are a few kinks.

To start off, here’s the code I used to make this work:

ParentClass.php

class ParentClass {
    static $something = “I’m in the parent class”;

    static function getSomething() {
        return self::$something;
    }
}

Child1.php

class Child1 extends ParentClass {
}

Child2.php

class Child2 extends ParentClass {
    static $something = “I’m in the child class”;
}

Child3.php

class Child3 extends ParentClass {
    static $something = “I’m in the child class”;

    static function getSomething() {
        return self::$something;
    }
}

test.php

require_once(‘ParentClass.php’);
require_once(‘Child1.php’);
require_once(‘Child2.php’);

echo “Parent class: “;
echo ParentClass::$something;

echo “<br />Child1 class (no overriding): “;
echo Child1::$something;

echo “<br />Child2 class (overrides static var): “;
echo Child2::$something;

echo “<br />Child3 class (overrides static var): “;
echo Child3::$something;

echo “<hr /><br />Parent class: “;
echo ParentClass::getSomething();

echo “<br />Using the method (Child1): “;
echo Child1::getSomething();

echo “<br />Using the method (Child2): “;
echo Child2::getSomething();

echo “<br />Using the method (Child3): “;
echo Child3::getSomething();

Now here’s the output when you run it:

Parent class: I’m in the parent class
Child1 class (no overriding): I’m in the parent class
Child2 class (overrides static var): I’m in the child class
Child3 class (overrides static var): I’m in the child class

---

Parent class: I’m in the parent class
Using the method (Child1): I’m in the parent class
Using the method (Child2): I’m in the parent class
Using the method (Child3): I’m in the child class

Let’s analyze what’s going on here. The ParentClass implements a static variable called $something and assigns it a value. Child1 doesn’t override that but simply inherits it. Child2 and Child3 both override it to give it a different value. When we retrieve the value of that static variable directly from each class, we can see that it worked.

The tricky behavior is in the method. The ParentClass implements the static method that outputs $something. We call that method respectively from each class. What you’d expect is that it would output the value of the static variable as far down the inheritance line as the class from which it was called. But from the output it’s apparent that the value of self::$something depends only on the class where the method was actually implemented, not the class from which it was called.

Foreign keys in MySQL: InnoDB and MyISAM

To create a foreign key in a MySQL database, there are a few things to keep in mind:

• Any tables using the foreign keys must use the InnoDB engine (MyISAM, the default database engine, doesn’t support them)
• The foreign key field must be indexed

Jim Epler posted a great tutorial (including screencasts) explaining the process of adding foreign keys.

As far as the differences between InnoDB and MyISAM go, here are my findings:

• MyISAM is based on a proven, reliable code base
• MyISAM is very fast and efficient for normal operations, such as selecting and inserting
• If you need relational design (esp. foreign keys), you’ll need InnoDB
• InnoDB also supports transactions and row-level locking (as opposed to the table locking of MyISAM
• InnoDB has better crash recovery, especially on large data sets

See Mike Bernat’s post and this page on INetU. The MySQL developer documentation also provieds a detailed comparison of all the supported database engines.

Twitter has become my new blog

The last few weeks I’ve been more inclined to micro-blog on Twitter than to sit down and write well thought-out pieces on here. (Oh, the life of a college student at the end of a semester.)

Hence the present paucity of postings.

But I am saying a lot of interesting things on Twitter. So follow me there (@snay2) if you don’t already.

And hopefully if (when) I make it through the madness I’ll start writing interesting (or maybe just useless) stuff here again.

Setting up a passwordless login over SSH

Here’s how you can set up a public key to allow you to login to a remote server over SSH without a password. (I draw mainly on the instructions here.)

First, open a terminal on your machine. We’ll call it mybox. We’re going to create a public key.

[me@mybox ~]$ ssh-keygen -t rsa

This will ask you first where you want to save the public key you’re creating. (The default location ~/.ssh/id_rsa is fine.) It will then ask you for a passphrase. You can just press enter twice at those prompts to skip the passphrase (I always have).

Now make sure there is a .ssh directory in the home folder on the server where you want to log in (we’ll call it myserver):

[me@mybox ~]$ ssh me@myserver mkdir -p .ssh

Next we’ll append the public key from mybox to the authorized_keys list on myserver:

[me@mybox ~]$ cat .ssh/id_rsa.pub | ssh me@myserver ‘cat >> .ssh/authorized_keys’

That’s it. You can test it with any command that uses an ssh tunnel (ssh or even svn or git, for example). Also note that you can use this same public key to set up passwordless login on any machine you like.

Now another handy thing is adding preconfigured setups to your ssh config file. It’s located in ~/.ssh/config. Here’s an example setup:

host server
    Hostname myserver
    User me

(See this reference for explanation on all the possible parameters you can use.)

Now you can type ssh server on the command line and get logged right in–no need to specify your username or enter a password.

Now mind you, this could potentially be a dangerous setup. Only use this on a well-secured computer where you are the only person with access to your terminal. Any hacker that gets in to your machine can now log in as you to myserver without having to know your username or password. Convenience comes at a price.