I've just finished Edward Tufte's essay, "The Cognitive Style of PowerPoint." It is now on the Inner Drive Technology required reading list:
Explanations of these choices to follow shortly.
Yesterday at the gym's coat check, I got claim check 404.
The coat-check guy didn't find this nearly as funny as I did.
Even more funny—to a software nerd, anyway—was that when I gave him check #404 after working out, he found my coat.
One can imagine other possibilities. But 404 is the best, I think.
Read, understand, and then fix your compiler warnings.
Compiler warnings let you know that you've either done something wrong, or you've done something non-standard. Either way, ignorning compiler warnings shows a lack of discipline and skill; it's something like ignoring big red "warning" signs in real life.
I'm working on a .NET solution that, when last compiled, generated over 60 warning
messages. A couple of them I put in to let other developers know about problems
I found, but most warned about things that actually needed to get fixed.
For example, the following line of code:
if (comboBox.SelectedItem == "Do stuff")
generated the warning, "Possible unintended reference comparison; to get a value
comparison, cast the left hand side to type 'string.'"
In other words, the if statement was evaluating whether the object comboBox.SelectedItem
was the same object as the string "Do Stuff," which is an impossibility.
So the comparison would always fail, making it look like the feature was
failing. Yet the compiler warned the developer about the problem, and even said
how to fix it.
If you're wondering, the corrected line looks like this:
if ((string)comboBox.SelectedItem == "Do stuff")
Anne and I attended the taping last night of Wait Wait — Don't Tell Me!, the NPR News Quiz. It airs Saturday.
If you don't listen to the show, tune in, and find out how to get Aerosmith and Kenny G to play the same gig, among other things.
Note: You may have seen this post earlier. In a continuation (recurrence?) of earlier problems, Das Blog ate the post about an hour after it went up. Grr.
<Rant>
Any software project that has more than one developer working on it needs to have some way of ensuring that there is one and only one "official" version of the code. This is called source control, for which teams use tools like Microsoft SourceSafe and Rational ClearCase.
In the land of myth and legend, the code checked in to source control is ready to roll. Checking something in that doesn't work, or that prevents other parts of the software project from working, is called "breaking the build." On some teams breaking the build results in the offending developer working late, suffering humiliation from his peers, or having Vinny come by and break his knuckles.
Adhering to this discipline allows developers to join the team, get the latest copy of the code, and start working on it. Failing to adhere to this disicipline causes anguish, frustration, and despair.
That is all.
</Rant>
I just finished Garbage Land, leaving only about a dozen books on my reading stack right now. Highlights:
Why is this in the Software category? Because better wetware means better software.
It's important to read widely in order to write better, whether your language is English or C#. Read as much as you can, about anything that interests you. Limit your professional reading to 50% of your total no matter what (but shoot for 25%). The more you know about things outside your profession, the more you can bring to the profession, whether it's software or anything else.
Aha.
In ASP.NET 1.1, you need to have a folder called aspnet_client\system_web\{.NET version} under a Web application's root in order for Javascript to work.
In ASP.NET 2.0, you don't. And in fact, on a server (like mine) where both versions are running side by side, having that folder causes Javascript to fail in some browsers on the ASP.NET 1.1 sites (like this one).
This means comments are working now.
But I'm still going to install Community Server, though I probably will keep Das Blog now. (For the record, I always thought it was a configuration error, not Das Blog's fault.)
I finally
bit the bullet and downloaded the Visual Studio 2005 CD images from Microsoft, and installed the latest runtime on my Web server.
Only one site broke: Hired Wrist, my dad's site, which I just now fixed. That's not bad. Usually upgrading hoses everything.
Hired Wrist broke (gracefully, I should point out; only the graphic headers were affected) because the released version of ASP.NET 2.0 handles page names slightly differently, which caused my resource-based graphics handling to fail. Resources, apparently, are now case-sensitive. Oops.
I've just spent the past four and a half hours trying, and failing, to get Microsoft SharePoint installed and running.
I think the .NET 2.0 Beta runtime on my main server is screwing things up. I think this because, for example, other people have gotten SharePoint running without a problem, and my Das Blog difficulties only seem to affect this server. (I got Das Blog running on a laptop—which doesn't have .NET 2.0 on it—just fine.)
Why doesn't stuff just work?
I'm all ready to start testing two open-source prouducts that are built for .NET 2.0, which was released about two weeks ago. I can't yet because I don't have the final version of .NET 2.0 yet; I still have the final beta, and these open-source projects won't run on the beta.
My company subscribes to Microsoft Development Network, which gives us just about everything they sell, plus all the beta-test versions. They also have a site from which we can download anything we haven't received yet.
So today, when I finally have some time to play with the new stuff, their download site is down. And we haven't received the DVDs yet (they're due in about two weeks). So I can't do much of anything that I wanted to do today.
Fooey.