Wayne Koorts’ Blog

I’m working my way through The C Programming Language at the moment, and so far I’m loving C’s purity and leanness.

One of my few disappointments with the book is the lack of solutions to the exercises. The exercises are refreshingly challenging because the book isn’t aimed at beginning programmers. Unfortunately this means that the desire to validate one’s solutions is quite strong. Fortunately, Google had a solution to this problem: Richard Heathfield’s solutions site.

I just finished my solution to exercise 1.23 (“Remove all comments from a C program”) and I’m quite chuffed with it so thought I would share it here. Out of the multiple solutions provided on Richard’s site, mine was about the closest to following the guidelines as far as what knowledge one is supposed to have of C by that (early) point in the book (the only thing I cheated with is the use of break and continue – it would have just been quite ugly without those two small additions). Basically the solution is a state machine using if / else instead of more traditional switch methods as switch had not yet been introduced.

My solution deals with all the special cases I could think of, and even deals with the tricky sample input on Richard’s site, provided at the bottom of the solutions page for this exercise.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89

/*
 * K&R Exercise 1-23
 *
 * "Write a program to remove all comments from a C program. Don't
 *  forget to handle quoted strings and character constants properly.
 *  C comments don't nest."
 *
 */
 
#include <stdio.h>
 
int main()
{
    int c;
    int c2;
    int in_quotes = 0;
    int in_comment = 0;
    int current_quote;
 
    c = getchar();
    while (c != EOF)
    {
        if (!in_comment && !in_quotes)
        {
            if (c == '\'' || c == '"')
            {
                in_quotes = 1;
                current_quote = c;
                putchar(c);
            }
            else if (c == '/')
            {
                c2 = getchar();
                if (c2 != EOF && c2 == '*')
                {
                    in_comment = 1;
                }
                else
                {
                    putchar(c); /* Just a regular '/', so output it. */
                    c = c2;
                    continue;
                }
            }
            else
            {
                putchar(c);
            }
        }
        else if (in_comment)
        {
            /* Check for a closing comment. */
            if (c == '*')
            {
                c2 = getchar();
                if (c2 != EOF && c2 == '/')
                {
                    in_comment = 0;
                }
                else
                {
                    /* Don't advance to next character in stream. */
                    c = c2;
                    continue;
                }
            }
        }
        else if (in_quotes)
        {
            /* Skip over escaped chars. */
            if (c == '\\')
            {
                putchar(c);
                c = getchar();
            }
            else
            {
                /* Check for closing quote. */
                if (c == current_quote)
                    in_quotes = 0;
            }
            putchar(c);
        }
 
        c = getchar();
    }
 
    return 0;
}

Really!  And, quite frankly, I’m sick and tired of programmers talking about them like this (not all programmers, some are worse than others, and all the usual disclaimery stuff applies)

I’m a user first, programmer second.  So are you.  Chances are you were using a computer for everyday tasks for a while before you started programming.  The fact is, we will never again be able to see computers in the same way as we did back then.  This is why we have average users test our software, and it’s vital that we do so.

Think about what it means to be a programmer.  Our job is to make computers more accessible to our dear users.  Everything we do, we ultimately do for them.  If we code with the user in mind at all times, and respect their needs, then everybody will ultimately be better off.

Sure, sometimes (hell, often!) a user’s request may not feel like the right thing for the system, and sometimes it won’t feel like the most elegant thing to do, but there are times when a leap of faith is required.  There will always be a balance between what users want and what we feel is good for them, but I’m appealing to you to lean in the direction of the user.

Nobody likes validating input to death, or putting up what seems like endless tooltips and hints all over the place, but users really do appreciate the little things we do to make their experience better.  Unfortunately, it’s more of a case of preventing outrage than garnering actual praise, but that’s what we signed up for, for better or worse.  The more people use the system for its intended purpose and the less we hear back, the better.

Make your error messages friendly.  Let the user feel like they have a more casual relationship with the system and they might feel less frustrated when something goes wrong.

“Don’t you worry about blank, let me worry about blank.”

Customer service rules apply even when the customer isn’t right in front of us.  Think of the system as an extension of yourself.  Build a little bit of your personality into the system for a more personal experience.

Please, please don’t think of your users as < than you, it’s just not fair.  Think of how out of place you would feel in their profession.  Respect the average user, and let’s make the computer experience better.  For them.

Here’s a mockup of the main window for the upcoming Tubecaster 3.  The release will include support for multiple downloads at once, playlist download support and built-in media conversion tools.  Stay tuned!

I’ve used Django for a few small projects in the last year and have absolutely fallen in love with it. While I always insist that I’m not a language or framework zealot I will quite happily and unashamedly push the Python / Django team wherever possible. Here are some of the reasons why.

Pythonic. This is a term that has evolved with Python to basically mean compliance with the Zen of Python. Here is the Zen of Python in its entirety as provided by Python.org:

    Beautiful is better than ugly.
    Explicit is better than implicit.
    Simple is better than complex.
    Complex is better than complicated.
    Flat is better than nested.
    Sparse is better than dense.
    Readability counts.
    Special cases aren't special enough to break the rules.
    Although practicality beats purity.
    Errors should never pass silently.
    Unless explicitly silenced.
    In the face of ambiguity, refuse the temptation to guess.
    There should be one-- and preferably only one --obvious way to do it.
    Although that way may not be obvious at first unless you're Dutch.
    Now is better than never.
    Although never is often better than *right* now.
    If the implementation is hard to explain, it's a bad idea.
    If the implementation is easy to explain, it may be a good idea.
    Namespaces are one honking great idea -- let's do more of those!

It just so happens that this aligns perfectly with the way I think. This is what drew me so quickly and intimately to Python itself.  It’s one of those things that makes a language “feel right” to us.  Every time I read the Zen of Python I find myself nodding profusely and grinning cheekily.  Django is Pythonic.

No black magic. Django’s components provide everything you need, but don’t go away and do anything so mystical that you can’t quickly get a handle on what’s going on and what their thought process may be.

Fantastic, complete documentation. The documentation on the Django website is well-written, complete and up to date with abundant code examples.  I really can’t stress the importance of this enough.  Anyone who has spent hours trawling through useless, incoherent, incomplete documentation will immediately see the value in this.

It’s ready when it’s ready. The Django developers are not afraid of holding back on a release if it’s not ready.  Django 1.1 was released about 3 months later than it was intended and the developers had no shame in holding it back because it wasn’t quite ready.  I highly respect them for this because it means that we can fully trust new releases to be very stable with copious amounts of polish.

Stays out of the way. One of the things I respect most about Django is that it doesn’t get in your way.  While it provides a complete stack for everything from data model handling to view templates you are free to substitute components with any of your own.  Don’t like the built-in authentication mechanism?  No problem.  Plug in another one or write your own.  Django’s concept of “applications” (basically pluggable modules) makes this easy.  Want to use your own file storage mechanism instead of what Django provides?  You’re more than welcome.

Built-in caching. Django was designed from the ground up with caching in mind and not only provides its own caching mechanisms but also plugs into existing, tried-and-true caching mechanisms like memcached (used by Facebook).

Easy admin interfaces. Django comes with a fully customisable admin interface for your projects which will hook directly into your data models.  This allows you to concentrate on developing your end user views without having to first get data entry forms in place.  Of course there’s no reason why you can’t continue to use the built-in admin tools or allow portions of them to be used by your end users.

Sane templates. Django’s templating system is just plain sexy.  It’s got the lot: fully-featured tags, batteries-included filters, and very simple, Pythonic, easy-to-learn syntax.

I could go on.  Apart from all that I’ve just mentioned, Django is also backed by Google and has the stamp of approval from Python’s creator himself, Guido von Rossum.

Not convinced?  Just take a look at the vast array of sites being created every day on djangosites.org.

Following on from the wildly successful Stack Overflow programming questions and answers website, Jeff Atwood and Joel Spolsky have launched Server Fault, a questions and answers site following the same format but now for “system administrators and IT professionals” (currently in Private Beta, click here for sign-up instructions).

I’ve been using Stack Overflow for about 5 months and I absolutely love it. It has become the definitive, and I dare say de facto standard, questions and answers one-stop-shop for programmers. You can post a question for just about any programming topic and receive an answer within minutes, sometimes even seconds. This removes an old hassle with posting questions on Web 1.0-style forums where you had to wait impractically long lengths of time to receive answers.

These sites don’t just follow any standard Q&A format either.  Just take a look at the diagram on the about page of either site and you’ll see that they’re a deliciously freakish Wiki/Blog/Forum blend.

One of the things I love about boths sites is their innovative karma and badge system, where users are rewarded by the community for making valuable contributions.  This gives users a reputation score which appears next to their name wherever it appears on the site.  This can be used as an assessment of someone’s overall standing in the community.  Badges are awarded for special achievements like providing an especially highly-rated answer or for being recognised as an expert in a particular technology.

Of course possibly the most important feature of boths sites is that you don’t need to be logged in to ask or answer questions.  This removes yet another annoying hurdle for the casual help-seeker.

I encourage everyone in IT, be it programming or otherwise, to sign up to at least one of these – you won’t look back.

-Wayne