Books you can drop.

Things haven’t gotten better. Right now I’m trying to read a PDF e-book on my computer. It’s miserable.

The computer is the worst imaginable device to read books on. My Eee’s screen is way too small, exaggerated by the PDF’s strange two-column format. I have to scroll down, then up, then down, then jump to the next page, then down, then up, then down, until I’m quite dizzy.

But worst of all, the computer’s much too powerful. When I read, I like to completely change my atmosphere, get far away from the computer, and get into a fresh state of mind. Computers make me very ADD. I read a little bit, then get something to drink. I read a litttle more, then get something to snack on. I read a little more, then check my e-mail. I read a little more, then get caught up in an article about human psychology. I read a little more, then realize how much I dislike reading e-books on my computer, so I blog about it, as if anyone cared.

Trust me, this is no idealistic scientific experiment about the usability and readability of e-books on computers. I need to read this book, but I can’t get a print copy right now. I’ve tried to convert this PDF into a more readable format with a superbly clever Python script, but I’ve wasted too much time trying that already, and it’s not worth it.

Bother.

I guess there’s nothing to do except to go back and keep reading.

Test cases. A good web developer turns problems into simple, reproducible test cases. When something goes wrong, it’s easy to fall into the lets-see-what-this-does rut. This solves your immediate problem, but it doesn’t leave you much smarter for next time. If you whittle down your problem to a comprehensible size, you can understand exactly what is going on, why it’s not working, and what you need to change. (Well, okay, some browser bugs are simply weird, but at least you have got a fighting chance!)

Research. A good web developer researches problems. You’re the smartest man alive, but you’re not the first to find this bug. You need to know which sites to check, such as QuirksMode, MSDN, MDC, and now Stack Overflow. But you also need to know how to use a search engine. Developers are creative creatures and can find a hundred ways to describe the same problem. You need to learn which keywords will bring the gold to the surface.

Documentation. A good web developer writes clear documentation. Once you solve a problem, it’s easy to check it in and move on. But just because you understand the problem today doesn’t mean that your team understands it or that you’ll understand it tomorrow. Write it down!

Localized Hacks. A good web developer favors localized hacks. Some problems can only be solved by ugly fixes, but you can minimize the damage by localizing the complexity. Keep the knowledge of that hack in one place–for example, hide it behind a JavaScript function, stick it into a CSS block, or fix it by adding a single element on your HTML page.

Pragmatism. A good web developer is pragmatic, neither sailing on the clouds of optimistic idealism or sinking to the depths of pessimistic despair, but somehow maintaining enthusiasm and courage in spite of the challenge.

Our conclusion? A good web developer is primarily a problem solver.

Really, it’s not complicated.

My first task was simply getting a bootable system. Rather than write my own bootloader, I used Grub. I based my work off Brandon Friesen’s excellent tutorial. I initially used VMware for virtualization, but since then, I’ve since switched VirtualBox and have had much better success.

As much as possible, the kernel is written in Lua. (Yes, Microsoft’s Singularity project caught my attention.) I am not particularly gung-ho over Lua as a language, but I picked it for its exceptionally small footprint, and it opens interesting possibilities for sandboxing. For example, my C kernel interfaces high-level interfaces to allocate and manipulate memory. However, the Lua scripts cannot specifically address memory. They can only manipulate memory block within the allocated bounds. This allows very powerful but safe low-level programming for my drivers.

With the past several weeks, I finished up basic multi-process support using Lua’s coroutines and debug hooks. (I am not using traditional process boundaries, so everything is running in kernel mode.) Processes can communicate with each other using a very simple IPC mechanism.

Today, my operating system boots into a simple Lua shell, allowing me to run arbitrary Lua code from the command line. This is no small feat, but it is admittedly of limited use. I am trying to decide how to proceed.

A networking stack could be quite beneficial, since it would allow me to program it remotely or to do something interesting like serve websites. However, this involves learning about the PCI bus, the NIC, ethernet, TCP/IP, DHCP, and many more details of which I am certainly unaware.

Alternatively, I could implement rudimentary file system support. For example, I could provide a way to save Lua objects to disk. However, I am lost to what interesting piece this might lead me to.

I blog so infrequently that I’ve probably lost most of my readership, but to all of you out there, what do you think I should develop next?

Of course, vimrc comes to the rescue:

imap <up> <C-O>gk
imap <down> <C-O>gj
nmap <up> gk
nmap <down> gj
vmap <up> gk
vmap <down> gj
imap <home> <C-O>g^
imap <end> <C-O>g$
nmap <home> g^
nmap <end> g$
vmap <home> g^
vmap <end> g$


And once again, I’m a happy vim user.

Update: And to get soft word wrapping, I added:

set formatoptions=l
set lbr


Now I’m really happy.

Here’s one to get you started:

function checkArgTypes(/*expected types*/) {
    var callerArgs = arguments.callee.caller;
    if (callerArgs.length !== arguments.length) {
        throw new Error('checkArgTypes does not have enough arguments.');
    }

    for (var i = 0; i < arguments.length; i++) {
        if (typeof callerArgs[i] !== arguments[i]) {
            throw new Error('Argument ' + (i+1) + ' is of type ' + typeof callerArgs[i] + ' but should be of type ' + arguments[i] + '.');
        }
    }
}

function run(str, num, bool) {
    checkArgTypes('string', 'number', 'boolean');
}

You might want to try it out in jconsole.

And, of course, you can’t ignore the obligatory security implications:

function validateUser(username, password) {
    /* accidentally call trojan function */
    trojan();
}

function trojan() {
    alert('Your password is ' + validateUser[1] + '.');
}

validateUser('user', 'secret');

Ahh, well. I’d best get back to writing real code.

NOTE: Edited to fix WordPress source code formatting problem.

Update: Fixed a typo in my “for” loop. (Thanks Philippe!)

In my opinion, someone should write a tutorial that first introduces the concepts of object-oriented Python, then illustrates how the same concepts apply to JavaScript.

* To defend myself against JavaScript purists, the point is to better understand JavaScript as a language. It’s not that I’m trying to coerce JavaScript into the mold of another language.

In less than three hours of hacking, I’ve set up a WordPress blog on my domain, transferred my b2evolution posts and media, and changed all links to my old blog to redirect to my new one.

I’m impressed.

What does it take for me to set up my Mac so that I’m productive?

First, I must configure OS X so that it’s even usable. This includes enabling active screen corners for exposé (lower-left for all windows, lower-right for desktop), enabling trackpad gestures, and tweaking the dock (small, right side of screen, automatically hidden).

Second, I need to set up .vimrc to get use useful features such as syntax coloring in vim.

Third, I need to install the software I can’t live without:

• Camino
• Xcode
• rdesktop
• Qt
• Subversion
• KeePassX

Finally, I need to install utilities that I use infrequently but am going to need eventually (for example, BitTorrent and Skype).

What’s on your list of Mac OS X essentials?