(If you don’t get the joke, here’s a little explanation.)

Moore’s Law isn’t dead; it just ended up taking on a new form. Named after Intel co-founder Gordon Moore, it refers to the observation that for the same amount of money, the number of transistors that can be place on a chip would double every 18 months. Moore described this trend in 1965 and expected it would continue for at least a decade; it’s held true for almost 50 years.

For a while, this doubling of transistors translated into a doubling of processor speed. We entered the 1990s with 286 processors running at about 10 MHz and left the decade with chips closing in on the 1 Ghz mark. But we didn’t get that hundredfold speed increase in the following decade; those extra transistors became multiple cores, so instead of speed, we got parallel processing engines.

To take advantage of these cores and get the speed increases that we’d grown accustomed to, it’s going to take parallel programming. It’s tricky to get right, and I have personally ruined some good programs with some bad threads, and you might have too. That’s what Parallelism Techdays (no relation to the TechDays conferences we’re putting on across Canada) are all about.

Parallelism Techdays is a FREE one-day course taught by Microsoft and Intel where you’ll learn about parallelism and threading. This is your chance to learn about threading your applications for multi-core platforms.

This course is aimed specifically at Windows C++ programmers using Visual Studio. You don’t need to be familiar with threads, but it’ll help. If you’ve got beginning to intermediate experience with threads in C++, this course is for you!

Here’s the agenda for the day:

• Thinking in Parallel
  • Why go parallel?
  • Types of parallelism
  • Task-based parallelism vs. traditional methods
• Getting Started with Parallelism
  • Approaches to converting serial code to parallel
  • Approaches to creating parallel code from scratch
  • Intel Parallel Advisor with test application
• Implementing Parallelism
  • Choosing a parallelism environment
  • Reasons we will focus on Intel TBB/Microsoft PPL in this class
  • Overview of TBB/PPL
• Debugging and Correctness (Introduction)
  • Overview of special bugs and parallel programs (deadlocks, data races)
  • Debugging a parallel program (demos of Microsoft Visual Studio 2010)
  • Correction of data races (demo of Intel Parallel Inspector)
  • General guidelines for parallel processing
• Tuning
  • Understanding parallel performance
  • Performance tuning process
  • Demos: Intel Parallel Amplifier, Microsoft Visual Studio 2010
  • General strategies for solving parallel performance issues

The course starts at 9:00am and concludes at 4:00pm, with 6 hours of instructional time, plus breaks and lunch. Register now – the Montreal event is happening soon!

This article also appears in Canadian Developer Connection.

The Week-Long Discussion

Andrew Stellman, co-author of O’Reilly’s excellent and easy-to-read C# intro, Head First C#, is holding a week-long “Inner Circle” discussion on C# and .NET 4.0 in the forums for O’Reilly’s “Head First” book series. In this discussion, he plans to cover a wide range of topics, including:

• Why use C# instead of any other language?
• C# best practices
• Becoming a better C# developer
• Dealing with objects
• Productivity hints
• The best of C#

If you want to follow the discussion, simply point your browser at the Head First Labs Forums’ “Head First C#” section and look for topics started by Andrew Stellman. You don’t have to log in to just read, but you’ll have to register for the forum if you want to join in the discussion and comment back.

The Challenge

In his first discussion topic, Andrew issues a challenge: build an old-school, text-mode game in C#! In the 1980s, the computing world was seen through the command line in an 80-character by 24-line grid (40 characters if you were on an Apple ][, Commodore 64 or Atari 400/800, even fewer if you were on a VIC-20), and that’s how we played a lot of games, whether they were commercial or typed in from source code in magazine or books like the ones scanned into the Atari Archives.

If you’ve never written a text-mode game before (or in my case, if it’s been a long, long time), he’s written an article to help out — Understanding C#: Use System.Console to Build Text-Mode Games.

Your efforts in building an old-school text-mode game will not go unrewarded. Submit a text-mode game and you can win a prize! He’ll judge them on the following criteria:

• Game play
• Fun
• Technical coolness
• General awesomeness
• “Retro nostalgia” for extra point

The winner will receive five O’Reilly eBooks of his or her choice. He’ll also choose runners-up who will get a free O’Reilly eBook.

If you’re looking for ideas for an old-school text-mode game, check out these books at Atari Archives, with source code written in old-school line-numbered BASIC. Some of these take me back to my high school days:

• Creating Adventure Games on Your Computer
• BASIC Computer Games
• More BASIC Computer Games
• Big Computer Games
• BASIC Computer Adventures

Video Q&A: Stellman on C#

As a prelude to the discussion, Andrew recorded videos of his answers to questions about the C# programming language and the second edition of Head First C#…

Why should developers learn C#?

What kind of applications can you build with C#?

How hard is C# to pick up?

What’s the toughest thing to learn in C#?

What’s new in the second edition of Head First C#?

This article also appears in Canadian Developer Connection.

For today only (that’s Sunday, August 15th), Manning is offering the pair of their books, C# in Depth, Second Edition and Azure in Action for the price of one! Just use the discount code dotd0815 in the Promotional Code box when you check out. You can order the final book in either dead-tree or PDF format.

Both these books are MEAP books – that’s short for Manning Early Access Program, a chance for you to get in-progress and final editions of books currently being written.

This article also appears in Canadian Developer Connection.

Want to learn C# or brush up on it? From Wednesday, August 18th through Tuesday, August 24th, you can join Head First C# co-author Andrew Stellman and other techies in a week-long exchange about C# in an O’Reilly “Inner Circle” discussion, where he’ll talk about C#, .NET 4.0 and Visual Studio 2010.

(If you’re a new programmer just getting started, Head First C# is a great book that will keep you engaged, even in those parts where the going gets a little tricky. If you’re an experienced programmer who’s new to C# – or like me, hadn’t used it in ages – it’s still a great read; just skip the basic parts and enjoy the “Head First” style in which it’s written. And yes, if you want to developer for Windows Phone 7, you’re going to need to know C#. Want to get Head First C# at a discounted price? See below for details.)

The discussion will span a wide range of topics, including:

• Why use C# instead of any other language?
• C# best practices
• Becoming a better C# developer
• Dealing with objects
• Productivity hints
• The best of C#

If you want to join in (I’ll be participating), register for the Andrew Stellman on C# discussion at O’Reilly. See you there!

Save Big Bucks on Head First C#!

O’Reilly have a deal on Head First C#, Second Edition (published this May, and it covers C# 4.0 and Visual Studio 2010): use the discount code BKCBD when ordering online from O’Reilly and save 40% off the dead-tree edition and 50% off the ebook!

This article also appears in Canadian Developer Connection.

Until now, taking advantage of the UI improvements in Windows 7 (and even some features in Vista) took a fair bit of work – there was a lot of stuff that wasn’t available through the .NET Framework. You’d have to either switch to C++ or resort to hacks in order to access these goodies.

That’s all changed with the newly-released Windows API Code Pack for Microsoft .NET Framework. Written in C# – with some DirectX stuff written in C++ – this library acts as a wrapper that gives managed code access to features including:

• Windows 7 Taskbar Jump Lists, Icon Overlay, Progress Bar, Tabbed Thumbnails, and Thumbnail Toolbars.
• Windows 7 Libraries, Known Folders, non-file system containers.
• Windows Shell Search API support, a hierarchy of Shell Namespace entities, and Drag and Drop functionality for Shell Objects.
• Explorer Browser Control.
• Shell property system.
• Windows Vista and Windows 7 Common File Dialogs, including custom controls.
• Windows Vista and Windows 7 Task Dialogs.
• Direct3D 11.0, Direct3D 10.1/10.0, DXGI 1.0/1.1, Direct2D 1.0, DirectWrite, Windows Imaging Component (WIC) APIs. (DirectWrite and WIC have partial support)
• Sensor Platform APIs
• Extended Linguistic Services APIs
• Power Management APIs
• Application Restart and Recovery APIs
• Network List Manager APIs
• Command Link control and System defined Shell icons
• Shell search API support
• Drag and drop functionality for Shell objects
• Support for Direct2D/Direct3D interoperability
• Support for typography and font enumeration DirectWrite APIs

The system requirements are:

• .NET Framework 3.5 SP1 or later
• Windows 7 RTM (although many features will work on prior versions)
• DirectX features require Windows SDK for Windows 7 RTM
• Some Direct3D samples require the March 2009 release of the DirectX SDK

We’ll cover the Windows API Code Pack for Microsoft .NET Framework over the next little while in a couple of places – certainly on this blog, as well as at the TechDays 2009 cross-Canada conference in the Optimizing Your Apps for the Windows 7 Experience session.

Download Windows API Code Pack for Microsoft .NET Framework (v1.0)

This article also appears in Canadian Developer Connection.

No tech workshop is complete without a little goofing around on an accordion, and I certainly didn’t want the MeshU day of workshops (which preceded the Mesh Conference) to be incomplete. I did a quick interview with Anita Kuno in which I performed a classic computer programmer song parody and promoted The Empire, which you can see in the video below:

Round Trip

Back when I was working for OpenCola (from January 2000 through January 2002), the start-up cofounded by Cory Doctorow, I was doing a lot of work using beta versions of C# to build prototype peer-to-peer applications that got demoed to some large companies, including Microsoft, who were kind enough to provide us with betas of Visual Studio .NET and Windows XP.

I graduated to the 1.0 version when it came out. Even during the year after I left OpenCola (or more accurately, got the boot), I continued to write applications in C#, from things like a sales app for people who were selling practice certification tests to a trivia game for a company that was pitching it to Maxim. I do manage to land some interesting jobs from time to time.

That changed on Bastille Day 2003, my first day as Tucows’ Technical Evangelist, or as the title originally read, “Technical Community Development Coordinator”. Tucows’ client base were people who wanted to resell things like domain names and email, and as such were largely hosting companies. This in turn meant that they were using languages that you might consider “webbier”: open source dynamically-typed languages like Perl, PHP, Python and Ruby. I did what I could to stay away from Perl, I’d coded in PHP and Python for work before, and I picked up Ruby along the way.

Feeling a bit restless, I left Tucows in late 2007 to do Ruby on Rails development at what turned out to be Toronto’s worst-run startup, possibly ever. After that, it was project management at b5media, where I used Ruby to implement some “housekeeping” scripts. Although I hit up Microsoft Evangelist David Crow for a copy of Visual Studio so I could try out XNA, I really didn’t pay too much attention to C#. I installed it on my machine, wrote a lazy “Hello, World” app – a single WinForm with a button that displayed a MessageBox with the word “poop” when you clicked it – and promptly forgot about it.

The situation changed when I got laid off in September and then got hired as a Developer Evangelist for “The Empire” in October. Suddenly, I’m back in a world with a three-versions-later Visual Studio and a two-and-a-bit-versions-later of C# and .NET. I’ve got the programming know-how and the language basics down cold; it’s the changes in the language and library – generics, LINQ and a bunch of 2- and 3-letter acronyms beginning with “W” – that keep catching me by surprise.

Luckily, management is cool with my first year being a “learning journey”. They’re really interested in how I mix my schmoozing and community-building skills with a love of technology and programming and don’t mind that my first year is a “learning journey”. They especially don’t mind if I share what I learn along the way, which is what this series of articles, Sith Lord in Training, is all about. As I learn more about C# and the .NET framework, both present versions and the upcoming 4.0 versions, I’ll write about them here.

Default Parameters in C# 4.0

Suppose that you’ve got a method that takes a single boolean argument. Here’s how the argument affects what the method does":

• If the argument is anything other than true or if no argument is provided, the method performs its normal task.
• If the argument is true, the method performs its task, plus some additional stuff.

Here’s the Ruby implementation:

# Ruby

def myMethod(doSomethingOptional = false)
    puts "Doing my regular thing."
    if doSomethingOptional
        puts "Doing the optional thing."
    end
end

doSomethingOptional is a parameter with a default value. If myMethod is called without any parameters, doSomethingOptional is given the default value of false.

Unfortunately, the current 3.0 version of C# doesn’t support parameter defaults. The way to emulate this behaviour is to use method overloading:

• One method to handle cases where no parameter is given
• Another method to handle cases where a parameter is given

Here’s the implementation in C# 3.0:

// C# 3.0

public void MyMethod()
{
    MyMethod(false);
}

public void MyMethod(bool doSomethingOptional)
{
   Console.WriteLine("Doing my regular thing.");
   if (doSomethingOptional)
   {
       Console.WriteLine("Doing the optional thing.");
   }
}

That’s a bit long-winded for something that should be pretty simple. Luckily, this has been fixed in C# 4.0:

// C# 4.0

public void MyMethod(bool doSomethingOptional = false)
{
   Console.WriteLine("Doing my regular thing.");
   if (doSomethingOptional)
   {
       Console.WriteLine("Doing the optional thing.");
   }
}

And with that, the long-winded (and unnecessary, at least to my mind) method overloading workaround vanishes. Yay!

Named Parameters in C# 4.0

Named parameters make the meaning of the parameters explicit, as long as the parameter names themselves are pretty meaningful. Contrast the following call:

drawCircle(100, 200, 200, "yellow")

with this, which is supported in Python:

drawCircle(radius = 100, x = 200, y = 200, color = "yellow")

C# 3.0 doesn’t support named parameters, but C# 4.0 does. Here’s how you’d call MyMethod in C# 4.0 using them:

myMethod(doSomethingOptional: true)

As for the Python drawCircle method in the example above. here’s how you’d call it in C# 4.0:

DrawCircle(radius: 100, x: 200, y: 200, color: "yellow")

If this syntax is giving you some deja vu, it might be because it’s reminding you of Objective-C, where the call would look something like this:

[someObject drawCircleWithRadius:100 x:200 y:200 color:"yellow"]

See the Video

If you’d like to see more about default and named parameters in C# 4.0, there’s a video on the Chanel 9 site that covers them quite extensively. Go check it out!

While following the exercises in the book Teach Yourself ASP.NET Ajax in 24 Hours – one of the few books I’ve been able to find on Ajax for ASP.NET 3.5 – I found an error in the “Hour 9” chapter in the example that covers client-side error-handling (it starts on page 137). I’ve reported this error to the publisher and with any luck, they’ll post a corrected version on their support web page for the book.

I’ve done some searching and haven’t found anything covering this error so I thought I’d cover it here. Better still, I’ll also cover the fix, which turns out to be quite simple. If you’ve been trying out the code in the book and wondering why it doesn’t work, relax: at least in this case, it’s not your fault.

In the course of covering the error and how to fix it, I’ll also talk about how ASP.NET handles exceptions raised by asynchronous postbacks and how you can make use of it to make better user interfaces. Even if you don’t have a copy of Teach Yourself ASP.NET Ajax in 24 Hours, you should find this article an interesting introduction to client-side error handling in ASP.NET Ajax.

Unhandled Exceptions and Asynchronous Postbacks

In ASP.NET Ajax, if an exception is raised during an asynchronous postback and isn’t handled on the server side – that is, in the code-behind – it gets passed along to the client side. What happens on the client side depends on which version of ASP.NET you’re using:

• In ASP.NET Ajax 1.0, the server-side exception object is serialized into JSON. The JSON is sent to the client, which displays the exception’s message property in an alert box.
• In ASP.NET Ajax for .NET 3.5, the server-side exception is still serialized into JSON and the JSON is still sent to the client. However, instead of displaying the exception’s message property in an alert box – a presumptuous design decision, if you want my opinion – the client throws the exception, which gives you the opportunity to handle it on the client side as you please.

(In this article, I’ll stick to covering ASP.NET Ajax for .NET 3.5.)

This is quite different from most other web application frameworks, where an exception raised as the result of an XMLHttpRequest call to the server results in some kind of “error” page from the server (or a blank page, if you’re suppressing error reporting).

To illustrate this, let’s put together a simple ASP.NET Ajax application. It’s a single page with a single button, that if clicked, throws an exception.

Here’s the code for the page layout. It’s pretty straightforward:

Listing 1: Default.aspx – Layout for the page of our simple ASP.NET Ajax application.

<%@ Page Language="C#" AutoEventWireup="true"
CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Error Handling Demo 1</title>
</head>

<body>
    <form id="form1" runat="server">

        <div>
            <asp:ScriptManager ID="ScriptManager1" runat="server" />
            <asp:UpdatePanel runat="server" ID="UpdatePanel1">
                <ContentTemplate>
                    <asp:Button runat="server" ID="Button1"
                    Text="Click Me" OnClick="Button1_OnClick" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>

    </form>
</body>

</html>

Some notes about the code:

• The ScriptManager control at the top of the form enables Ajax by ensuring that the JavaScript needed to support ASP.NET Ajax on the client side is downloaded to the browser.
• The UpdatePanel control determines the controls that trigger asynchronous postbacks and defines the region of the page that can be updated via Ajax.
• Button1 is the button control that we want to throw an exception when clicked. We’ll set it to call the Button1_OnClick method, which will contain the exception-throwing code.

The code-behind is very simple. In it, we define a single method: the event handler Button1_OnClick, which is called in response when the user clicks Button1. All we want it to do is throw an exception that uniquely identifies itself:

Listing 2: Default.aspx.cs – Code-behind for the page of our very simple example app.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;

namespace WebApplication1
{
    public partial class _Default : System.Web.UI.Page
    {
        protected void Button1_OnClick(object sender, EventArgs e)
        {
            throw new Exception("Click!");
        }
    }
}

Running with Debugging vs. Running Without Debugging

Listing 1 and 2 give us enough to make our simple app work. It’s time to take it for a spin.

Here’s something that doesn’t get covered in Teach Yourself ASP.NET Ajax in 24 Hours: what happens when you try to run this app with debugging (starting it by hitting F5 in Visual Studio or “Start Debugging” under the “Debug” menu)?

Here’s a screenshot of what happened for me:

With debugging on, the unhandled exception thrown in Button1_OnClick is caught by the debugger. Normally, this sort of error-catching behaviour is welcome, but in this particular case, it gets in the way of what we’re trying to achieve: having an exception on the server side and passing it along to the user’s browser to handle.

If we run the same app without debugging, we get the effect we want: the exception is raised on the server side, but the server-side part of the application doesn’t halt with an error message. Instead, the client shows the error message.

Here’s a screenshot. Note that the error message includes the string “Click!”, which is the argument in the throw statement the Button1_OnClick event handler. Thanks to this, we can be pretty certain that the error message is the result of our deliberately-thrown exception:

Now that we have the exception that we threw on the server side being handled on the client side, let’s do something with it. 

Handling Exceptions Passed from the Server on the Client Side

Let’s do something simple – let’s catch the exception caused by the button click, and instead of having a JavaScript error box pop up, let’s make a couple of changes to the button:

• Change its text to “This button has been disabled for your safety.”
• Disable it.

To handle exceptions on the client side, we need to write some client-side JavaScript. Luckily, this is made simple by the number of handy utility classes defined in the scripts downloaded to the client by the ScriptManager component. In this case, we’re going to make use of the Sys.Webforms.PageRequestManager class to deal with the exception because it provides us with the following:

• The endRequest event, which is raised after an asynchronous postback has completed and control is returned to the browser.
• The add_endRequest method, which specifies a method to call when the endRequest event is raised.

Here’s the JavaScript, which we’ll put in a file called ErrorHandler.js:

Listing 3: ErrorHandler.js — Client-side error handler for our very simple example app.

Sys.WebForms.PageRequestManager.getInstance().add_endRequest(EndRequestHandler);

function EndRequestHandler(sender, args)
{
    if (args.get_error() != undefined) {
        $get('Button1').value = "This button has been disabled for your safety.";
        $get('Button1').disabled = true;
        args.set_errorHandled(true);
    }
}

The script performs the following:

• It registers the method EndRequestHandler as the method to call whenever the endRequest event is raised.
• It defined the method EndRequestHandler, which does the following:
  • If an exception did occur during the asynchronous callback:"
    • The button’s text is changed
    • The button is disabled
    • The error is reported as handled, which allows the application to continue

Now that we have this client-side code, we need to get it to the client. We do this by using the Scripts section of the ScriptManager to send this file to the client. The listing below shows the updated layout code for our simple application. I’ve highlighted the change in the listing below:

Listing 4: Revised Default.aspx – Layout for the page of our simple ASP.NET Ajax application.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Error Handling Demo 1</title>
</head>

<body>
    <form id="form1" runat="server">

        <div>
            <asp:ScriptManager ID="ScriptManager1" runat="server">
                <Scripts>
                    <asp:ScriptReference Path="~/ErrorHandler.js" />
                </Scripts>
            </asp:ScriptManager>
            <asp:UpdatePanel runat="server" ID="UpdatePanel1">
                <ContentTemplate>
                    <asp:Button runat="server" ID="Button1"
                    Text="Click Me" OnClick="Button1_OnClick" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>

    </form>
</body>

</html>

The Scripts section of the ScriptManager lets us specify scripts to be sent to the client along with the page, with each script specified in a ScriptReference tag.

When we run the app (remember, without debugging on) with these changes and click the button, here’s what we get:

In a later article, I’ll look at other ways of using client-side error handling in ASP.NET Ajax in .NET 3.5.

The Error in Teach Yourself ASP.NET Ajax in 24 Hours

Here’s the page layout code for the error-handling example in Teach Yourself ASP.NET Ajax in 24 Hours. The code-behind for the page and the client-side JavaScript are fine, it’s this code that has the error. See if you can spot what’s amiss:

Listing 5: Default.aspx — Page layout of client-side error-handling example in Hour 9 of Teach Yourself ASP.NET Ajax in 24 Hours.

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="WebApplication1._Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title></title>
</head>

<body>
    <form id="form1" runat="server">

        <div>
            <asp:ScriptManager ID="ScriptManager1" runat="server" />
            <asp:UpdatePanel runat="server" ID="UpdatePanel1">
                <ContentTemplate>
                    <asp:Button runat="server" ID="Button1"
                    Text="Click Me" OnClick="Button1_OnClick" />
                </ContentTemplate>
            </asp:UpdatePanel>
        </div>

        <br /><br />

        <div id="Message" style="visibility: hidden;">
            <asp:HyperLink ID="HyperLink1" runat="server"
                           Font-Bold="true"
                           Text="Error Occurred..."
                           Font-Italic="true"
                           ForeColor="red" >
            </asp:HyperLink>
        </div>

    </form>
</body>

</html>

Just for kicks, here’s what happens when you click on the button in the app using the code straight from Teach Yourself ASP.NET Ajax in 24 Hours:

The mistake is simple: although there is some error-handling client-side JavaScript in the app, it’s not referenced in the ScriptManager tag, which means it’s not sent to the client. Without error-handling code on the client side, the exception is thrown, there’s nothing to catch it and the user is presented with the standard error dialog box.

The fix is equally simple: reference the script in the ScriptManager tag’s Scripts section:

<asp:ScriptManager ID="ScriptManager1" runat="server">
    <Scripts>
        <asp:ScriptReference Path="~/ErrorHandlingScript.js" />
    </Scripts>
</asp:ScriptManager>

Once that’s done, the program works as promised.

As a new Microsoftie and programmer returning to C# after a six-year absence, I have a lot of learning and re-learning ahead of me. In preparation for this, I spent the better part of an afternoon in the “Computers” section of my neighbourhood bookstore going through the C# programming books, sorting the gems from the junk. I took the “beginner’s mind” approach and looked at all the books on the shelves, regardless of the skill level they were written for, even the books that devoted whole chapters to basic concepts like looping and branching. At the very least, it would give me an idea of the current state of programming literature was like in the .NET world.

A couple of weeks later, I stumbled across the C# “Yellow Book”. It’s the standard book for first year computer science students at the University of Hull (I know of it thanks to a Black Adder episode) and written by Rob Miles, a Microsoft MVP and lecturer at that university. Each computer science student there is given a free-as-in-beer printed copy of the book, and now anyone can get a free-as-in-beer PDF copy online.

The C# Yellow Book is quite good, and can easily hold its own against some of the commercial C# books I’ve seen, which typically sell for about $35. It’s written in a clear and breezy style, explains it concepts well, has examples that actually work (I tried some out just for kicks) and often goes beyond typical beginners’ books with many asides called “Programmers’ Points” that explain good programming technique. Its 185 pages cover most of the basic C# language — and most of the example code is run in console mode except for the section near the end that covers basic Windows Forms. After finishing this book, you should have enough background material to tackle an intermediate book on C# or introductory books on .NET topics like GUI programming, ASP.NET or even game development for the PC, Xbox 360 and Zune (yeah, really, the Zune) with XNA.

I’d say that Rob has a strong incentive to make the book as good as possible because it’s the basis of a course at his university and because he can get some rather immediate feedback from its readership. If only that was true for a professor of mine back at Crazy Go Nuts University, whose Pascal programming book (it was the eighties) had terrible examples, an incomprehensible presentation and writing style and annual revisions to foil used-book sales and to force each new class to buy the latest edition. Kudos to Rob and the computer science department at Hull for giving away the course textbook for free!

If you’re a starving student looking to learn Windows programming, I’d recommend getting your hands on a copy of Rob Miles’ free-as-in-beer C# “Yellow Book” and pair it with Microsoft’s free-as-in-beer Visual C# 2008 Express Edition. Alas, I can’t point you to any free-as-in-beer computers.

Links

• Rob Miles’ C# “Yellow Book”
• Visual C# 2008 Express Edition
• WindowsClient.NET: The official site for GUI development in Windows, covering both Windows Forms and the new GUI framework, WPF.
• ASP.NET: The official site for ASP.NET, Microsoft’s framework for web application development.
• XNA Developer Center: The official site for XNA, Microsoft’s game development framework.
• XNA Creators Club: The online community for XNA game developers.

Here’s a fun little claymation video showing called Pointer Fun with Binky that explains C++ pointers “to kids”. Why can’t all programming be taught this way?

My favourite phrase of the moment, thanks to this video, is “Magic Wand of Dereferencing”.

[Found via Being Cellfish.]

Interview with Chris Slemp, MSDN

Here’s another video interview featuring Yours Truly at the PDC: it’s with Chris Slemp, Program Manager for the Server and Tools Online group at Microsoft. In the interview, we talk about MSDN and its new social bookmarking feature.

Click here to watch the video.

“Grim Fandango’s” Puzzle Document

If you’re looking to get into the mind of a game designer and the design of one of the most highly-regarded computer adventures games, be sure to check out the Grim Fandango Puzzle Document. Tim Schafer, in “a temporary fit of Cake-induced Grim nostalgia,” decided to put the game’s puzzle design document online in PDF form (it’s 2.3MB in size).

Here’s a great summary of the Grim Fandango Puzzle Document, written by Andy Geers:

I use that word "crafted" because that’s exactly what this newly released document shows: true craftsmanship. We see the incredible attention to detail, the pacing of the narrative as it builds and as the puzzles get increasingly sophisticated, always coaxing the player along with them. As somebody whose spent the last few years trying to write my own adventure game, what struck me most about this document is the sheer simplicity of it – it’s well established that it takes a great deal of clarity and hard work to boil down something so vast as Grim Fandango into such a simple representation that conveys so much information in such a succinct way.

It’s a considerably more interesting read than most specs.

My Job-Related Reading List

Nothing gives you that frozen-caveman-thawed-in-modern-times feeling like returning to a software platform after not developing in it in seven years. Getting back into the swing of Microsoft’s development tools has been fun so far, but it is, as a lot of people have told me, like drinking from the firehose.

To quickly get acclimated with C#, ASP.NET and XNA, I’m expensing the following books I bought today:

• Pro C# 2008 and the .NET 3.5 Platform by Andrew Troelsen
• Professional ASP.NET 3.5 in C# and VB by Bill Evjen, Scott Hanselman and Devin Rader
• Beginning XNA 2.0 Game Programming by Alexandre Santos Lobao, Bruno Pereira Evangelista, and Jose Antonio Leal de Farias

I’ll let you know what I think of these books as I read them.

“Zero Punctuation” Reviews

And finally, a couple of reviews from my all-time favourite game reviewer, Ben “Yahtzee” Croshaw. The first one’s for Saints Row 2, which includes a great argument for why it might actually be a better game than Grand Theft Auto IV as well as a brilliant concept for a new game:

and here’s the latest review, for Dead Space, which he summarizes as “competent but bland”. Luckily, his review is anything but…

The July 25, 1994 issue of Time magazine.

The computer science student phase of my academic career (the less said about the previous phase, in which I was an electrical engineering student, the better) ran from 1991 to a successful conclusion in 1994.

If you are like me, you strongly connect memories with the music of the time; you could say that my computer science student phase ran from the time of Nirvana’s Nevermind and Soundgarden’s Badmotorfinger to Green Day’s Dookie and The Offspring’s Smash. Let’s just say that I often showed up to my classes and labs in a flannel shirt.

(If that last paragraph makes you think “Whoa, that was a long time ago!”, you’ll be blown away by the fact that the initial work on C ran from the time of the Beatles’ Abbey Road to Led Zeppelin’s Houses of the Holy. A fair number of you probably weren’t even born then.)

My Student Language of Choice

I don’t know what the situation was like at other schools, but at the time, computer science students at Crazy Go Nuts University were allowed to hand in programming assignments using the following languages:

• Pascal
• Turing
• C

(Remember, there was no Java back then. The Green Project, from which the language/platform sprang, was still ongoing at this time, and Java was still going by its “Oak” codename.)

The general recommendation that came from most of my professors was to use Turing. They told us that it was a kinder, gentler language than Pascal and even more so than C, which they implied was designed by dyslexic aliens. When some of us suggested that it might be better to use a language that saw actual use in the real world, many of them countered with the argument that learning principles of computing was more important than learning specific languages. We might’ve responded by pointing out that one of our professors was a co-creator of Turing and probably got a vig for every Turing installation (it was a commercial language), but that might have been an academic career-limiting move.

I ignored their recommendations and went with C. In the lab, I used good ol’ cc. At home, it was Turbo C at first, and later, when I got my first Mac (a Quadra 660AV bought with money from DJing), Think C.

I never used C in my professional career. My first job out of school took me away from a world where input and output was all printf() and scanf() to interactive CD-ROMs and Macromedia Director (now Adobe Director and 7 versions later), and after that, the languages remained pretty high level: Visual Basic, Python, Java, C#, NSBasic, PHP and Ruby, with only a slight detour through through Visual C++ and C++Builder.

My C Books Back Then

It’s almost impossible to talk about C without mentioning “K&R”, the nickname for what is considered to be the official bible of C, The C Programming Language, which was written by Brian Kernighan and Dennis Ritchie. The latest edition of the book — the second edition — is a bit long in the tooth as it was written in 1988, but for the most part, everything in this book should still apply to the current C99 standard.

I never owned a copy of the book in my student days. I signed it out when necessary from the electrical engineering/computer science library in Walter Light Hall. I did own a copy for a brief period in 2002 when my deadbeat ex-housemate left a lot of his stuff behind, but I sold it (along with most of his stuff) in order to recoup some of the money lost from his stiffing me on rent, utilities, groceries and the largest domestic phone bill I’ve ever grappled with.

The books I had while at Crazy Go Nuts University were the second edition of A Book on C and Understanding C Pointers (a book that seems to be no longer in print). I liked A Book on C enough to pick up the fourth edition on sale a couple of years ago, and someone out there has forgotten to give me back my copy of Understanding C Pointers (you know who you are!).

Back to C

I’ve decided to get back into C for a number of reasons.

I have to admit that one of those reasons is completely irrational: it’s ego. There’s certain geek cred that comes with having at least some proficiency in C. While I had those bragging rights back in school, I can’t honestly claim them now; I haven’t even written a file whose name ends in .c in over a decade. Luckily, I had a pretty good grasp of C back in school, and the noodling I’ve been doing with good old gcc suggests that I’ve still got it, which is pretty reassuring.

I’ve also been meaning to do some development with things that are programmed in C or C dialects:

• The Arduino electronics prototyping platform has its own programming language based on C. I’ve been meaning to try out hardware hacking with the folks at the local group HacklabTO.
• I’ve also been thinking about putting together some Mac OS X and iPhone apps, which require Objective-C.
• I’ve even been thinking about doing some GTK noodling, which is done in good ol’ C.

Finally, there’s the matter of just making myself a better programmer by working in C by refreshing my knowledge of the low-level stuff that C requires you to work with, and also the “brain stretch” that comes with working with a language and environment (what with going back to strong typing, compiling and make) that I haven’t worked in for some time.

I’ll be doing some C coding in my spare time, as well as noodling with the Arduino programming languane and Objective-C, and I’ll be posting my notes, observations and experiences here. As I’m fond of saying on this blog, watch this space!

Better late than never: C# 3.0 will feature map, reduce and filter, and Dare “Carnage4Life” Obasanjo explains how to rock these features. He concludes the article with “If your programming language doesn’t support lambda functions or have map/reduce/filter functions built in, you just might be a Blub Programmer who is missing out on being more productive because your programming language doesn’t support ‘esoteric’ or ‘weird’ features,” which sounds kind of weird in an article about C#, a language that could only be Blubbier if its name were BlubLang or Blub#. I suspect I’ve woken up in some upside-down parallel universe again!

Here’s a handy guide to reading C declarations, where things can get very confusing very quickly. Quick — what’s being declared in the line “int (*(*vtable)[])();” ?