When I was thirteen years old, I thought programmers fell into two categories: game developers and boring, big-business enterprise developers.

"Yeah, in enterprise stuff, you just program a GUI and people can put data in, like their name, their salary, their boss' name, and their boss' salary," I explained to my brother. It was because the programming books always used employees and bosses as examples. So I decided that I would become a game developer. I was thirteen.

When I entered university, I chose computer science as my degree. By this time, I had lost interest in gaming, but I still loved programming. I would program games for fun, because it was either that or database programming, and MySQL seemed hard. And I knew that writing HTML wasn't actually programming.

I took a basic data structures class and a basic logic class my first semester in university. It was fun, but the end of the semester, I started to dread my future as a boring database programmer. I thought about switching majors. History, perhaps, or writing. Or music composition. I wanted to create, you see. I wanted to create beautiful things. I had written short stories and pieces for piano and orchestra, and it was always so fun. I started on a symphony, but realized that I didn't know much, so I never finished it.

Then I found out that my professors weren't teachers; they were researchers. I didn't know how you research something, but I figured that research was better than boring database programming. So I took a course on autonomous vehicles my second semester and I started reading research papers on how cars can drive themselves. I stayed on campus for the summer on a research fellowship and continued my work. I coded my algorithms and ran my experiments. My work didn't improve on anything, so I threw everything away. That's research, I supposed, lots of throwing stuff away.

Then I started to read. I found Paul Graham's essays. I learned the word "startup." I realized that there is a bigger world out there. And I found that creation is still possible, that programming can be beautiful.

And finally, there is no startup "buzz" around UTCS. None at all. Compare that to Stanford's CS program, where students can take classes like Web Applications and iPhone and iPad Application Programming and Cloud Computing (look at that list of top-notch guest lecturers!). Oh, but UTCS isn't a trade school! How dare we teach our students iPhone programming! But Stanford's campus is teeming with students passionate about starting awesome companies. What about our campus? At UT, I just hear people complain about the difficulty of using version control.

One reason for this embarrassing lack of buzz is that Austin startups differ from Silicon Valley startups. Successful Austin startups, it seems, are usually B2B, and thus unknown to the common student, and use not-so-sexy technologies like Java, which drives passionate students away.

Ideally, every git commit would contain one logical work. But we don't work this way. We often get side-tracked from our current task. In the middle of a bug fix, we may see a method vulnerable for refactoring. So we refactor it.

 And now we have to commit a bug fix and a method refactor, and they're both in the same file. The lazy way out would be to commit the file with a nice message: "fixed bug #183 and refactored method_name".

Clojure is a fascinating language, but setting up a nice, vim-based working environment is a pain. I finally managed to get vimclojure working (vimclojure 2.2.0-SNAPSHOT with Clojure 1.2), and I hope my notes will help you set up.

Download and Build Vimclojure

$ hg clone http://bitbucket.org/kotarak/vimclojure
$ cd vimclojure/client
$ make

Now, we need to download the server (it was recommended that you don't build the server yourself): http://clojars.org/repo/vimclojure/server/

Copy the server jar to vimclojure/server/server.jar.

Set up vimrc

First, we copy the vim plugins into our local .vim folder:

$ cd /path/to/vimclojure/vim
$ cp * ~/.vim/

Then, we modify our .vimrc to enable vimclojure:

$ vim ~/.vimrc

syntax on
filetype plugin indent on
let vimclojure#HighlightBuiltins = 1
let vimclojure#WantNailgun = 1
let vimclojure#NailgunClient = "/path/to/vimclojure/client/ng"

Run the NGServer

To run the NGServer, we need to specify the classpaths of our code, the clojure jar, and the vimclojure server jar:

$ java -cp /path/to/your/code/:/path/to/clojure.jar:/path/to/vimclojure/server/server.jar vimclojure.nailgun.NGServer 127.0.0.1

Mine is:

$ java -cp .*:/path/to/clojure.jar:/path/to/vimclojure/server/server.jar vimclojure.nailgun.NGServer 127.0.0.1 

Using Vim

After this, we can open vim and edit .clj files (inside /path/to/your/code/). If we want a blank buffer, do:

:setfiletype clojure
\sr

Send it to be processed by clojure by hitting \et to process the current line or \ef to process the entire file.

References:

http://groups.google.com/group/vimclojure/browse_thread/thread/69abeea9f57cb73b/9360432c165c2beb

http://groups.google.com/group/vimclojure/browse_thread/thread/168da4c737d084e1/e0a668d25c3e4aef?lnk=gst&q=filenotfoundexception#e0a668d25c3e4aef

Sometimes, you find that you only want one instance of a class to be created. Ever. This way of programming is often referred to as the singleton pattern.

In languages like Java, the singleton pattern is often implemented by using a class static variable as the single object:

In the snippet above, the default constructor is set as private so to prevent the user from instantiating a OneOnly object. Instead, the user must use OneOnly.get() to get access to the one and only OneOnly instance.

This way of executing the singleton pattern is impossible in Python due to the fact that Python does not have an equivalent to Java's final keyword.

A well-defined singleton pattern, however, is possible in Python. The Wikipedia entry on the singleton pattern [1] presents a clever way of doing it in Python. I reproduced Wikipedia's Python example below and added some more code to explain what's going on under the hood.

In the snippet above, singleton() is a function that takes a class and returns a function. I created a simple Counter class. Line 15 shows that Counter is a class. I then set Counter to the return value of singleton(Counter). Counter is now a function, as Line 17 shows. This is awesome. Now, whenever the user tries to "instantiate" a Counter, the user is really just calling a function, namely getinstance(). And getinstance() is built so that it will only build one instance of Counter, on Line 5. If an instance of Counter already exists, getinstance() will simply return that instance.

The Power of Closures

But why does getinstance() work? The most amazing part is that the getinstance() that is set to Counter is a specific getinstance() that "closes over" the variables cls and instances. That is, when we define getinstance() inside of singleton(), getinstance() still has access to cls and instances, even after we exit singleton(). Thus, we don't have to create a new instances dictionary every time. This only happens once, at Line 2. We get to Line 2 through the call at Line 16, which only happens once (for Counter).

Why does instances have to be a dictionary? Well, it doesn't. The only thing that matters is that we don't set the instances reference to a new object somewhere inside getinstance(). If we do, we lose the closure over the instances defined on Line 2. Thus, instances should be a mutable object such as a dictionary or a list.

Let us test our singleton object:

As you can see, every call to Counter() returns the same Counter instance. Great! We now have a very powerful construct to build classes that adhere to the singleton pattern. If we want to create another one-instance-only class named Puppeteer, we simply set Puppeteer = singleton(Puppeteer) after the class definition. Puppeteer will then get its own getinstance() function and its own instances dictionary, separate from Counter's.

Decorating

Python has something called decorators. A decorator is just syntactic sugar [2] for what we did when we wrote Counter = singleton(Counter), which can look a bit ugly. We can prettify this by adding a @singleton before our Counter class definition:

If you haven't seen decorators before, you should now realize that a decorator @singleton will simply set the class name (in our case, Counter) to the value returned by singleton(Counter).

Conclusion

So yes, Python's open nature is sometimes unwanted. But with closures (e.g. getinstance() closing over cls and instances) and first-class functions and classes (i.e. passing around classes and functions as ordinary objects), Python allows us to device beautiful, clever constructs.

References

[1] http://en.wikipedia.org/wiki/Singleton_pattern
[2] Python Decorators Don't Have to be (that) Scary. http://www.siafoo.net/article/68

Is Python magical? Consider the trivial unit test below:

Unless you're a Python guru, I'm sure you've wondered how unittest.main() found and ran TestSomething and TestSomething.test1. If you look at the unittest source code, you find a nice trick:

Ah, unittest.main isn't a function, it's a class! So unittest.main() creates a new TestProgram object, whose initializer then goes ahead and runs the unit tests for you. But how does TestProgram know to load the TestSomething class and run TestSomething.test1?

Most of this work is done by the unittest.TestLoader class. TestLoader will look at the current module (i.e. your current file), examine each class in it, and load classes that inherit unittest.TestCase. Then, TestLoader will look inside these classes for methods that have 'test' as their prefix.

After this, TestProgram will know what tests it needs to run.

Of course, unittest is more complicated than this, but this describes the main flow of unittest. I suggest that you download the Python source code and read unittest.py yourself. It's a lot of fun, really. Plus, reading source code is a great way to improve and enrich your coding, and Python's source is one of the best treasures around.

And thus is born another green giraffe. What is a green giraffe, one might ask? It is a pasture, really. A luscious, green pasture of thoughts, ideas, and code. A place where a human and a machine may forever dance beneath a never-setting sunset. A dream.

The Green Giraffe in its proper noun form, however, is this very website. It is merely an attempt at birthing this elusive green giraffe. I am no conjurer of beasts, but perhaps with some work and thought, The Green Giraffe will manifest itself and become a useful resting place for you coding wanderers.