Ongoing Projects

I never start projects. I bump into them. Sometimes they feel like a distant member of Grampa’s extended family. Other times, they feel like a close friend you’ve been dying to talk to for the past 6 months, but gosh darn it where’s his number? Unlike most seasoned hackers, I only have three large projects I wish to see to completion before I touch something new.

• index_server – the full text indexing tool for Haiku I wrote this summer.
• Goonj – a media player and music library manager for Mac OS X (I’m working on this with Pratul).
• Make the Dell Vostro 1520 100% Haiku compatible. For this, I need to write drivers for the following devices: (1) touchpad (2) wireless card (3) webcam and (4) sound card. I’ve already started digging through some driver code, but it will be a while before I have something usable.

Interests

I’m a sad case, really. I need to write a blog post to remind myself what I’m interested in. If you don’t want your kids to turn out this way, make sure they take enough baths. Yes, even in winter.

High-level stuff bores me. I find I’m much more comfortable with C and C++ than Python. With that in mind, here’s a small overview of my fields of interest:

• Compilers
• Virtual machines (and emulators)
• Operating systems
• File systems
• Games (why not?)
• Information retrieval

Lately, I’ve been reading up on electronics. I’ve barely scratched the surface of what’s possible with just a few cheaply available components, and I’m already shaking with excitement. College does not permit me to learn as much as I’d like to, but I’m slowly getting there. I’ll have something to show for my efforts in a couple of months. Let’s see what comes of this new obsession .

Now, on to the trivialities.

The results for Google Summer of Code 2009 came out on April 21, and I failed to make it. According to my mentoring organization, I was one of their top picks, but failed to get in because I didn’t submit as many patches as the other students. No GSoC work means I have no commitments this summer. Akshay is trying to get a RoR job somewhere, and I think Apoorv has something planned, too. I feel I ought to start making my own TODO list now.

I have spent the past few weeks thinking about how much time I waste on worthless activities (something which led to a fight between me and Apoorv – he’s absolutely certain he’s not wasting any time). The agenda for April is to cut out all the time-sucking activities from my routine. I’ll probably read up on time management and check out what the GTD hype is all about. Also part of the agenda is keeping my workspace clean. Right now, I have a single table for everything – study, web browsing, movies, programming and food. I’m going to have to try and keep my work and fun areas segregated so that when I sit down in my work chair, my mind goes, “Okay, time to work. No more distractions.”

lut4rp tells me I need to get some code “out there”. A lack of Objective-C knowledge is preventing me from delving deeper into Cocoa, so I will be spending some time writing ObjC code and putting it up on GitHub for everyone to see (and laugh at). I really wish I could spend more time with Python, but I want to go indie with a few desktop apps and that’s something which Python fails to do well (at least on OS X). I want to push the limits of ObjC, just to see how dynamic it really is (so far, I’ve used it like a spiced up version of C). In my experience with the language so far, I have felt it is nothing compared to heavyweights of the dynamic world – Ruby and Python. I sincerely hope I’m wrong.

The next logical step after Objective-C is to sharpen my 1337 Cocoa skillz. The strategy this time is to leave the more advanced technologies for later. What’s the point of getting into CoreData or Keyring Services if I never plan to use them? As an aside, the Hillegass book is awesome, but I don’t think it’s written for people new to Cocoa. It reads more like a cookbook than an introduction to OSX programming. I’ll be using Apple’s docs + online tutorials (and refer to Hillegass if the need arises). Since I’ve already covered more than 50% of what is required to write decent OSX apps, my next steps are mostly going to center around getting familiar with the libraries available to me.

My one-post-a-day idea bombed, mostly because exams kept me busy. I had two weeks of exams, followed by a week of semi-rest, followed by a week of practical exams. Another round of practicals begins on Monday, which will be followed by ten days of semi-rest and another two weeks of exams. The last two months of the semester are always like this at IPU. I’m used to it now, so no worries :p

Note that most of the problem areas I have listed deal with C++ and the Turbo C++ IDE. This is because most Indian colleges teach C and C++ in the first two years of the CS/IT course.

• C++ is a programming language, not a piece of software. To convert the C++ syntax into an executable, you need a compiler. In Indian colleges, Turbo C++ is a widely used compiler. So, if you need TC++, you have to ask me, “Do you have a C++ compiler?”, not, “Do you have C++?”. It’s not only annoying, but it shows you are incompetent.
• Besides Turbo C++, there are many other compilers you could be using. Loosely speaking, C++ itself is a standard document containing all the rules of the language. Any compiler that follows these rules can compile your C++ code. Two compilers you will inevitably have to deal with are Microsoft Visual C++ and the GNU Compiler Collection (popularly known as GCC). More on this later.
• A compiler is a command line tool. That means it has no graphical user interface (GUI) you can see. You just send it a C++ file, and it spits out an executable. The Turbo C++ IDE hides this compiler from you. When you press CTRL+F9, it sends your C++ code to the compiler along with several other options that tell the compiler to compile the code and produce an executable. If it wasn’t for the Turbo C++ IDE, you would have to type these commands by hand every time you wanted to compile your code. Again, more on this later.
• Turbo C++ is a compiler. The Turbo C++ IDE is an integrated development environment (that’s what IDE stands for). The job of an IDE is to provide you with an editor (where you type your code), several tools to make your programming job easier (highlighting keywords, the ability to look up things in a help browser etc.) and to make it easy for you to organize your projects. That blue screen where you type all your code is not the compiler, it’s the IDE. A few of the most popular IDEs are Microsoft Visual Studio, Eclipse, NetBeans etc.
• A C++ file (i.e., a file with a “cpp” extension) is just a plain text file containing code. You can open it in any text editor and make changes to it. Note that a text editor is a piece of software that is used to create plain text files without any formatting. Notepad is a plain text editor, whereas WordPad and Microsoft Word are not since they are used to create formatted documents.
• Windows is an operating system from Microsoft. I’m sure you know what that means. What nobody ever told you was the fact that most of the popular operating systems differ from each other in many fundamental ways. If you compile a piece of code on Windows, and then run it on another computer running Windows, it will work perfectly. On the other hand, if you try to run that executable on a Linux or Mac OS X machine, it will not run because of these fundamental differences. That is the reason none of your Windows games work on Linux/OS X.
• Nope, you can’t “hack” a computer using just a simple tool. Ankit Fadia might claim he can teach you how to hack, but he knows no more about “hacking” than a tea leaf knows about the history of the East India Company. The correct term for breaking into a system by exploiting weaknesses in it is called “cracking”, and it’s not something you can learn in a classroom. That “ethical hacking” course is a fraud.
• A programming language is supposed to be studied as a coherent whole. If you say “I’m great a loops, but I don’t understand functions.”, that indicates you don’t get programming.
• Update [April 4]: This is the most important part of this entire post, yet it inexplicably slipped my mind. Turbo C++ is a very old compiler from a bygone era. Nobody, I repeat, nobody uses it for actual development. I reccommend using the GNU Compiler Collection. But GCC is just a set of compilers (and some related tools) which you will have to operate from the command line – not an easy task for someone who is just starting out. What you need is a decent IDE to go with your compiler. Bloodshed Dev C++ is a very nice IDE meant for beginners, and it comes with GCC so you won’t have to install that separately. Do yourself a favor and download it right now.

I will keep adding new points to this list as I encounter them. Leave your suggestions in the comments section of this post.

Take my opinions on the Mac as a development machine with a grain of salt, since I’m neither a professional programmer, nor do I contribute to any major open source projects. I’m still in the early stages of hackerdom, and most of the code I write is either for learning, part of simple scripts I write to automate tedious tasks or, more recently, part of small desktop apps I write using the Cocoa libraries. Even though I haven’t written or worked on any complex piece of software, I grew up using Linux and open source software and have been exposed to many different programming languages (before I settled on Python as my language of choice). I installed Fedora Core 1 (or was it FC2?) just for fun when I was 14 and ended up using various Linux distributions for about four years before I bought my MacBook.

I bought the MacBook about 8 months ago, and started learning Cocoa for writing desktop apps for the Mac, and I’m loving every bit of it.

All right, here’s my list.

The Good Parts

• Mac OS X is UNIX under the hood. Heck, launch Terminal.app and have fun playing with awk, grep, sed and friends – the same stuff one would use under Linux. OS X also comes with Perl pre-installed. I have no idea if Python and Ruby are parts of the core system, but they’re definitely parts of Apple’s Developer Tools package.
• You can grab all your favorite editors and languages off MacPorts, which is very similar to Debian’s APT (actually, it’s closer to Gentoo’s emerge tool).
• Most Linux applications run perfectly on Mac OS X. In fact, many of the lesser known apps have Linux and Mac OS X ports, but no Windows ports. The Transmission BitTorrent client is one example.
• I believe the UI of my OS has a profound effect on my productivity. The OS X UI has been designed to not draw attention to itself unless you look very hard. Contrary to popular belief, OS X does not have any eye candy, unless you consider smooth transitions from boot screen to login screen to the desktop eye candy. Exposé and Spaces look like eye candy to someone who has never touched a Mac before, but they are productivity features which just happen to be beautifully designed. A stock Ubuntu system with Compiz has much more intrusive eye candy than a stock OS X system.
• If you’re looking for a new programming language and a new set of APIs to learn, then there’s no better choice than Objective-C and Cocoa (this is exactly what I’m learning these days). After having written a few apps using Cocoa, you will never want to go back to writing apps for Windows or Linux. The API is consistent and well designed, and contains classes for the most common tasks you might wish to perform in a desktop app. Interface Builder is awesome in the true sense of the word, and unlike most other IDEs, XCode is fast, responsive and almost a pleasure to use (almost, because I still prefer the editing capabilities of Emacs over any other editor).
• No tinkering with config files, no hardware driver issues, minimal maintenance, no slowdowns over time, no malware issues and not having to do an apt-get upgrade every three hours. The it just works nature of the Mac has given me more time to work on my own code, rather than spending most of my time finding ways around other people’s mistakes.

The Bad Parts

• If you’re writing commercial applications, then Windows is the way to go. Apple will never have significant market share on your average desktop, since both Windows and Linux can run on anything from a Rs.25000 ($500) Zenith desktop to a custom built, Rs.65000 ($1360) gaming machine, whereas the Mac OS runs only on Apple hardware.
• Macs don’t play well with other operating systems. Installing Windows using BootCamp works fine and dandy, but running it for a long time causes my MacBook to heat up to over 65ºC. While installing Linux on a Mac is easy, it’s not officially supported by BootCamp, and getting it to play well with the hardware requires many hacks and workarounds.
• Customizing a Mac is not easy. Linux allows you to customize every aspect of the OS, and even Windows allows a certain level of customizability, but the Mac allows none. Be prepared to either install unsafe hacks that mess with the OS or just STFU and follow the One True Way of Steve Jobs.
• Be prepared to pay for quality. The software-wants-to-be-free culture of the Linux world is not acceptable in the Mac world. If you can’t pay up, then have fun using unstable ports of clumsily put together GTK apps under the X-Server.

Even though the Mac has its own disadvantages, I’d rather use a Mac than a Windows/Linux machine for development any day.

Update: The professor in question has been reported and is now banned from taking any more classes.

This piece might come across as one intended to bad mouth my own college, but I have a sneaking suspicion that things aren’t all rosy in other parts of the country either.

I suppose every geek has had this same feeling before. You take a seat in the front row of your first Introduction to Programming lecture, all worked up about the fact that here, finally, is a class you can be on top of. The professor walks in, gives a little introduction, and you realize it’s going to be a long, long semester.

Today I decided to make a list of all the atrocities committed by my Introduction to Programming professor. I wasn’t expecting much because, even though he sounded like a complete knucklehead to the geek inside me, I was sure he at least knew the textbook inside-out. I was, as one would expect, wrong. So, hackers, get ready to cringe. Here’s my list.

• … Linux is basically a DOS based OS.
• These days we are using 128 and 256 bit processors.
• A compiler is a software that converts code written in a particular programming language to machine code. To compile a program, you must hit ALT+F9. (It took me a while to realize he was talking about the Borland Turbo C++ IDE from 1992, a prehistoric compiler Indian colleges use for all C and C++ courses.)
• The object code generated by a C++ compiler is almost identical to that produced by a Java compiler.
• The first high level language was Ada, also known as Smalltalk. (This was a big WTF moment.)
• The second high level language was COBOL, which was an improvement over Ada. (Cringe, cringe, cringe.)
• FOTRAN came after COBOL. (No, “FOTRAN” is not a typo. This is what he said.)
• FOTRAN, COBOL, Ada and Smalltalk were not general purpose languages.
• This one is classic: C was the first language to run on UNIX systems. All languages before C ran only on Windows.

I still haven’t completely recovered from the shock.

Hand-Holding Doesn’t Get You Anywhere

What I Did Wrong: I looked for a book on Qt which made understanding GUI programming concepts simple for a beginner such as myself.

Correction: Such a book does not exist. Picking up a For Dummies book (or something equivalent) means shooting yourself in the foot. If you expect people to guide you step-by-step through learning difficult subjects, you should probably not be writing code at all.

Immerse Yourself in the Material

What I Did Wrong: I searched hard for a book that would teach me Qt from beginning to end. I spent hours reading reviews, blog posts, forums and back covers searching for the One Book.

Correction: One source is never enough, and the One Book does not exist. The best way to learn any new API or language is to completely immerse yourself in the material. Subscribe to mailing lists, hang out in IRC channels, read blog posts, articles and tutorials, help people out at StackOverflow, read code written by the experts, try to modify existing code, add new features to your favorite application and talk to people who know the stuff well. Oh, and buy a good book.

Don’t be Systematic

What I Did Wrong: I tried to systematically study the material from the first chapter to the last, completing every exercise given in the text.

Correction: Being systematic is the biggest mistake I made while learning Qt. Trying to be systematic will only tire your mind as you tediously work through some trivial exercise the author thought was important. Programming is a creative activity. The most painless way to learn something is to just let your brain run wild. Speculate, dream, design, experiment. Skip the boring exercises and do only the ones you find interesting or, better still, make up your own exercises. When you find yourself unable to complete the task you put yourself up to, skip around the book and try to find a way to solve the problem.

Taste Things First

What I Did Wrong: As I read through the material, I typed the code samples into my editor to see what the author was trying to say. I moved on to the next chapter only when I had tried out every code sample and completed every exercise in the current chapter.

Correction: When you’re reading through the material for the first time, always read it like it’s a novel. Instead of focussing on how you can accomplish a certain task, focus on what you can accomplish. This way, you will know the strengths and weaknesses of your tools before you sit down to code. Most importantly, you will know where to look for the functionality when you actually need it. Reading the material quickly makes it seem like you’ve accomplished a lot in very little time which keeps your brain from getting bored. Also, it makes reading through it the second time (this time focussing on the details) much easier.

Aim High

What I Did Wrong: Whenever I didn’t understand something, I told myself it was okay. Whenever I felt stupid because I couldn’t grasp a simple concept, I told myself to relax. I thought it was okay to fail, and that not many undergrads even know about Qt. Hell, I thought, there are so many great hackers who didn’t even know how to program at my age.

Correction: When you’re evaluating yourself, always compare yourself to the people who are better than you. If you think you’re stupid, you probably are.

These techniques were partly based on this article. Check it out, it’s pretty good.

From the site: [Uncool's Code Dojo] is a database of short, fun programming tasks that can be solved in under a week’s time.

Here’s a problem – I’ve just learned this new do-all-end-all-super-mofo programming language but I don’t know what to do with it. The Code Dojo is my contribution to bored programmers everywhere who share the same feeling.

Visit the Dojo at http://dojo.uncool.in