Reasoning Is Reusable

I have often wondered, “What marks intellectual maturity?” One thing is clear: the ability to reason, even when the “correct answer” is unknown, sets apart an adult from a child. How many times were you frustrated by an essay question in grade school because you didn’t know what the teacher wanted?

I now realize what I didn’t understand then: You can learn a lot through rote memorization. But when it comes to making dependable decisions, you’re going to need more than just that. Today, although I’m interested in other people’s opinions, I’m even more interested in their reasoning.

Why?

Reasoning is reusable.

My best example comes from my profession. My boss and I were once discussing our reporting feature, which I had implemented incorrectly. Whenever you wanted to modify the report (change the title, add a column, etc.), you had to save the report to file before viewing your changes. My boss, however, told me that doesn’t work–the user needs to be able modify reports and run them without saving.

That could have been the end of the conversation. But it wasn’t. Rather, he immediately had a business reason defending this. During a sales demonstration, users often ask, “Can this report show this piece of information?” When the salesperson adds the column, it’s quite distracting to save it, especially if you need to specify where and how it should be saved! The ease evokes an oh-wow-that’s-easy response. And it’s not limited to sales, either. When people modify reports, they frequently only want to tweak it slightly. Saving their report is only a distraction from their goal, which is analyzing information, not building reports. What could have simply have been a statement of opinion was instead an explanation of the reasoning. Rather than fixing this single inconvenience, I was now equipped to look for other problems that kept the user from his or her task.

It’s worth something to have a programmer read your mind during the interview, but there’s a lot to say about a programmer who solves a problem in a suboptimal way but is able to defend his decision. That he’s thought through the reasons is a good sign. That, I think, clearly marks intellectual maturity.

JavaScript Member Functions

A JavaScript Lint user recently pointed out that JavaScript Lint does not support the following code:

function window.onload() {
window.alert('Hello World');
}

Surprised, I pointed out that this is invalid JavaScript. However, it turns out that Internet Explorer supports this unusual syntax. Internet Explorer allows this on any object:

var foo = {};
function foo.bar() {
window.alert('Hello World');
}
foo.bar();

It also allows this:

function Foo() {
}
function Foo.prototype.bar() {
window.alert('Hello World');
}
var o = new Foo();
o.bar();

Just for fun, I tried this, which it refused:

function Foo() {
function this.bar() {
window.alert('Hello World');
}
}

It also refused this:

function foo['bar']() {
window.alert('Hello World');
}

Does anybody know where, if anywhere, this is documented?

rdesktop on the Mac

I used my notebook quite heavily for terminal services, so I was quick to download Microsoft’s Remote Desktop Connection Client for Mac when I got my MacBook. However, it was quite slow even at low color depths. One evening I tried using it to code, but it was very unproductive. After that, I used it mostly to check e-mail. I finally decided to see what it takes to install rdesktop.

Although it took a bit of time to set up, I was very glad I did. It’s very fast and very useable, and it certainly beats Microsoft’s client. I have documented, as best I could, the steps required to set up rdesktop. I apologize in advance for any mistakes. But let me tell you, it’s well worth it!

Getting It Installed

1. Find and insert your Tiger installation CD.

2. Using the Finder, locate the Xcode Tools package and install it.

3. Open the Terminal and run the following command to install X11:

   open /Volumes/Mac\ OS\ X\ Install\ Disc\ 1/System/Installation/Packages/X11User.pkg

4. Download the latest stable version of rdesktop (1.4.1 at the time of this post).

5. Assuming you downloaded the package to your desktop, run the following commands in the Terminal:

   cd ~/Desktop
tar xzf rdesktop-1.4.1.tar.gz
cd rdesktop-1.4.1
./configure && make && sudo make install

   Once that’s done, you can delete the extra files from your desktop.

6. You should now be able to open X11 from your finder and run rdesktop with the following command:

   /usr/bin/local/rdesktop 192.168.0.255

Fixing the Alt Key

When I first ran rdesktop, I found that the alt/option key did not map as I expected. The solution is simple:

1. Create a file called ~/.Xmodmap with the following contents:

   clear Mod1
keycode 66 = Alt_L
add Mod1 = Alt_L

2. Open X11 preferences (Cmd+, from X11) and disable “Use the system keyboard layout”.

Streamlining It Further

Although this allowed me to use rdesktop to connect to my computer, it was still too much work, so I decided to streamline the process a bit.

1. Create a file ~/rdesktop-mycomputer.sh with the following contents:

   #!/bin/sh
/usr/local/bin/rdesktop -f -a 16 192.168.0.255

2. Run the following command from the Terminal:

   chmod +x ~/rdesktop-mycomputer.sh

   You should now be able to run open-x11 ~/rdesktop-mycomputer.sh to open rdesktop in X11.

3. Unfortunately, xterm gets in the way when you want to use full-screen rdesktop. To keep it from launching, run the following command:

   cp /etc/X11/xinit/xinitrc ~/.xinitrc

   Then, using a text editor, open ~/.xinitrc and remove the line that reads “xterm &“.

4. Finally, open the Finder, Applications, AppleScript, Script Utility and create a new script with the following code:

   do shell script "open-x11 ~/rdesktop.sh &"

   Save the script in the “application” file format in a convenient location, such as your desktop.

5. You’re done! You should now be able to launch your rdesktop session with a single click!

Back to the Mac

I have now owned three Apple computers. I first bought an iBook about nine months ago, but finally sold it because it was too slow to do anything useful. (It took about 15 hours to compile Qt/Mac.) Then, six months ago I bought a Mac Mini, and I’ve used it periodically for some software development. But it’s been sittng in the corner and has received very little attention. That one’s leaving, too.

I’ve now got a MacBook, which I’m dual-booting, to replace my Dell Inspiron notebook. I’m writing this post in Kubuntu. Out-of-the-box hardly describes the installation of Kubuntu on the MacBook. With a little help, however, I got it done using the alternate Dapper CD for the base install. If I could only get the key mappings to work as they should and could get it to run a bit cooler, I’d be pleased. As it is, I’ll likely end up primarily using Tiger.

To all the Mac users, it’s good to be back.

JavaScript Variable Declarations

JavaScript Lint continues to surprise developers with warnings about variables. They do know that variables will be global if they forget to use the var keyword. For example:

function assign()
{
i = 10;
}
assign();
alert(typeof i); // shows "number"

But many of them don’t know what this does:

function assign()
{
i = 10;
var i;
}
assign();
alert(typeof i);

Is i a global variable (“number”) or a local variable (“undefined”)?

If assign would return i, what would this show?

function assign()
{
i = 10;
var i;
return i;
}
alert(assign());

If you don’t know the answers to these questions, find out for yourself. Was it what you expected?

Update: The inquisitive should read section 10.1.3 of the spec, which describes variable instantiation: Every execution context has a variable object, to which formal parameters, function declarations, and variable declarations are bound. These variables are bound upon entering the execution context. That’s why the i isn’t global.

jconsole.com

Through the benevolence of an unnamed sponsor, you can now access the JavaScript Shell at a new location: http://www.jconsole.com/

The point is not, of course, to take advantage of somebody else’s hard work. That page doesn’t link back to me, and I see no reason that it should. Rather, it prominently links to the original shell.

There are two reasons for giving this its own domain:

• It’s easy to remember.
• I can update it with fixes for things that don’t work. (For example, I can finally apply the patch that I submitted nearly a month ago to Jesse Ruderman to provide better auto-complete in Internet Explorer.)

The JavaScript Shell is a tool that I use a lot. If you haven’t yet, try it out.

JSLint considered harmful?

Dean Edwards pointed to a comment by Michael Geary regarding JSLint. Although I cannot speak on behalf of JSLint, I can speak on behalf of JavaScript Lint. I’d like to first respond to the specific situations, then to the larger question about whether lints–JavaScript Lint or JSLint–are helpful or harmful.

• Is eval evil? There’s one situation that JSLint correctly warns against. Sometimes I see code like this to retrieve property values: eval("myobj." + prop), when instead it could simply be myobj[prop]. The problem, of course, is that I use JSON in my code, and I need to use eval.

  JavaScript Lint does not warn against the use of eval.

• ==/!= vs. ===/!==

  JSLint also prohibits “== null” and “!= null”, but there is a perfectly good use of these notations – the common case where you really don’t care to distinguish between null and undefined, but do wish to distinguish those from other “false” values.

  To be honest, I implemented this warning in JavaScript Lint because JSLint had it. I tend to use strict warnings whenever possible, so I’ll either use if (x === 0) or if (!x), but rarely if (x != null). The argument against the warning is very a good one.

  This warning can be disabled in JavaScript Lint.

• Required curly braces on all block statements. When I e-mailed Douglas Crockford, proposing a patch that would make this optional, he responded that this is a very common error. For example:

  if (c)
  a;
  b;
  

  I disagree. I work on a 7000-line JavaScript codebase (still growing), and I’ve never encountered that problem. I’ve also worked with a developer who had no prior experience in the Java/C/C++ language family, and I recall no incident of this bug in that developer’s code.

  This is one of few warnings that are disabled by default in JavaScript Lint.

• Repeated “var” declarations.

  JSLint’s prohibition against repeated “var” declarations can lead to fragile code:

  function foo() {
  for( var i = 0; i < a.length; i++ ) {
  }
  // and later in the function:
  for( i = 0; i < b.length; i++ ) {
  }
  }

  If you later refactor that code, it would be easy to forget to put the “var” back in.

  This warning can be disabled in JavaScript Lint.

  Both lints, if they are enabled to detect undeclared variables, should warn you if you refactor code and forget to put it back in. The “declaration warning” could reasonably be suppressed if you immediately assign a value at the second declaration. The concern, I think, is that you forget that this variable may have been previously assigned.

• JSLint disallows i++ and i– for no good reason. Rather than warning against all uses of the ++/–, JavaScript Lint only warns when it’s used as part of another statement, such as x = --i or if (i--). It’s not that prefix/postfix increments/decrements are inherently wrong. It’s just that they’re hard to get right when they’re used within an expression.

  This warning can be disabled in JavaScript Lint.

Are lints useful or harmful?

To be useful, the lint must adapt to your code, rather than your code adapting to the lint. I believe that’s the most significant difference between JavaScript Lint and JSLint. Speaking of the curly-brace-blocks setting, Douglas Crockford told me, “Laxity defeats the whole point of a lint program.” To some degree, he’s right. But lint programs must also be very pragmatic.

JavaScript Lint is loaded with configuration options. In fact, every warning mentioned here (besides the eval warning, which JavaScript Lint doesn’t have) can be disabled in JavaScript Lint. Yes, this makes JavaScript Lint more difficult to configure, but these settings are also what allow JavaScript Lint to be run on large codebases.

I don’t use JavaScript Lint as the final sign-off for correct code. I simply use it to find the most common typos, syntax errors, and dumb goofs before I test my page in the browser. I validate my code in three ways:

• JavaScript Lint, for initial checking. (I also run JSLint during a nightly build process, but I prefer JavaScript Lint when I’m coding because it’s so much faster.)
• Unit tests, for core reuseable components.
• Manual tests for integration testing, cross-browser quirks, and such.

Lints can be very useful if they’re used right. But if they’re not, Michael Geary is quite right in calling them harmful.

JavaScript Lint

I think this is good news:

JavaScript Lint now has its own SourceForge project with discussion forums, bug/feature trackers, and a publicly-available Subversion repository.

Programming Is Hard

Jakob Nielsen’s recent essay on Variability in User Performance examines various tasks and compares the most productive users with the least productive. Of the tasks he examines, programming has the most variance in performance.

This table shows why the number one guideline for managing software development is to hire the best developers: Good developers are three times faster than slow ones and offer companies tremendous gain — even when they require higher salaries.

He also states:

The difference between the very best and very worst developers is typically about a factor twenty.

That’s a big difference!

Interestingly, the runner-up is using web sites, which means bad news for web developers. Managers can go out and pick more productive developers, but web developers can’t go out and pick more productive users. Their users may be quite skilled or only somewhat skilled, so they need to find a way to cater to both without frustrating either.

SUSE 10.1 (with wifi that works)

Today I upgraded to SUSE 10.1 on my notebook, mostly for its improved wireless network support. Aside from the hassle of reinstalling my wireless network driver after upgrade, I was not dissapointed. KNetworkManager is everything that KInternet and KWifiManager were not. Before I resorted to committing the network keys to my memory. Now I can now save them in a KDE Wallet. Switching between networks is very easy, and it’s something that I do lot. Wireless networking was the single most bothersome feature in SUSE.

Just for fun, I also downloaded Intel graphics drivers for my notebook so I could get 3D acceleration for Xgl and Compiz. Unfortunately, it’s way too slow to use, but the UI metaphors are very effective.

• The cube effect is a nice, intuitive way of switching between desktops. It gives you visual feedback on what’s happening.
• The Apple-like window switching is cool (see exposé), although I think a hover effect would make it more effective.
• The scrollwheel-controlled transparency on Windows could be a very convenient way to quickly check information in other windows without the total loss of context from alt-tab. This is especially useful on notebooks since they have limited screen space.

I’ve reverted back to the two-dimensional world to write this post because, oddly, I prefer being able to get things done over seeing cool effects. But I can’t wait until I can do both.