A painting of me

Laying Out Software

   30 July 2018, early morning

I wrote this in 2007, when my life was all C and C++. I was working on migrating something that morphed from a small focused C program to a larger messy C++ program. I don’t remember why I didn’t publish it at the time. I’m sure I had more I wanted to say. Or maybe this advice is bad and with my forgetting all the C++ I used to know I no longer remember why.


I should write some posts about cleaning up old and poorly written programs. As software develops over time it sometimes ends up a huge unmanageable mess. It takes concerted effort to keep source code neat and organized. Furthermore, spending the time to think about how you organize your software will save you time in the long run. So, my first piece of advice for you budding software developers — i’m looking at you here Shima — is that source files should be as small as possible, and no smaller.

If you are working in C++ (or a similar object-oriented language), header files should be used to declare classes, and source files should be used for their definitions. Inline function should go in their own file as well. You should be able to look at a file and know what its contents are. Languages like C++ are fairly easy to work with because the structure of your code in the file system generally mirrors the structure of the program as discrete objects.

When working with a procedural languages like C, it is sometimes harder to see where things should be delineated. It is easy to fall into the habit of having one mother-of-all header files that contains all your declarations, and one source file with all your functions. This is stupid. Code should be organized such that unrelated functions, typedefs, structures, etc, are kept apart. Digging through a 3000 line source file looking for a function definition will make you crazy. You shouldn’t need a fancy IDE to manage your software projects.

Regardless of the programming language you are using, related functionality should be grouped and declared in their own header files, with definitions of functions in their own source files. Dividing your source code neatly in this fashion allows code that requires this functionality to (ideally) #include just the definitions it needs, and no more. You should be able to look at the #include directives in source file and header files and understand the dependencies of the code contained within; you should be able to see the relationships between the functions in your program. If you are lazy about the file structure of your source this becomes difficult. Don’t be lazy.

Comment |  

We Must Abuse the Broadband: Pre TXP.

   12 January 2010, late at night

I took my original photoblog down sometime in November 2006. When I moved all my sites over to Dreamhost Movable Type, which was what I was using to run the site, stopped working. I can’t recall why. At the time, I wasn’t particularly enamored with Movable Type anyway; I figured I’d eventually move things to Textpattern. I did do this, but it took me a good while. The thing is, the site never really worked as well under TextPattern. While the site was on hiatus I put all the photos I had posted over the years on Flickr. There were 718 photos in total. Without titles and descriptions though, it was really just a big mess of images. My plan was to one day figure out how the Flickr API worked, figure out how to parse my Movable Type export file, and then fill in all this information. It took me 2 years or so, but i’m finally done.

I did this all using Ruby. I used FlickRaw to talk to Flickr and ruby-mtexport to parse my MT export file. Thankfully all the images on my site were named after the date they were posted, which made it easy to match up data in the export file to a photo on Flickr. I can’t recall the last time i’ve been so productive when programming. Ruby really is a great little language.

For the time being Flickr continues to be the place to go to see my photographs. I still want to turn IMG VQVZ into a proper photoblog or portfolio site. I just need to sort out how that would work.

Comment |  


   4 January 2010, lunch time

I wrote another small Sinatra web-app over the holidays, one for viewing groups on Flickr: Group VIEWQVZ. This site is basically a simpler (lamer?) version of Flickr River. I think if I knew how well Flickr River worked I wouldn’t have started with this thing. I did learn a little bit about HTML5, and a bit more about using Sinatra. I put the code up on Github for those of you who want to see how a Sinatra application works. For those of you who know Ruby, you can tell me what i’m doing wrong.



   21 December 2009, late evening

I took the code I wrote for IMG VQVZ to finish off my Blansdowne photo site. You can now browse my most recent photos of the area, and look at the sets of images I’ve made using those photos. The only thing left to do is take photographs that are interesting. This might be the hardest part of the project.

Comment |  


   18 December 2009, mid-morning

When I met Ali and a few of the Well.ca people at Startup Camp a couple years back, I told the organizers I was working for the skunk-works project VQVZ. I suppose technically I was, since I’ve been sitting on the domain for a long time now.

I bought Blansdowne.ca a while ago. My original plan was to set up some sort of community site, similar to the site Joe Clark runs about Leslieville. I sat on the domain for ages. Shortly after buying my GRD II I snapped a few photos of the neighbourhood, put them in a small set on Flickr, and thought it’d be nice to use Blansdowne.ca for a photo project instead of yet another blog. The site remained static for a long time. A few weeks back I got to work figuring out how I would build a simple photo application to run the site. I wanted to be able to display collections of photos on a single page, and have a simple photoblog that would display images in chronological order. One reason I gave up updating We Must Abuse the Broadband was because Flickr was basically easier in every regard to work with. So, one of my main goals with this project was that updating the site needed to be easy.

My first idea was to have a simple text file that would act as a manifest for the site, describing images I’d keep in a directory on the file system. A Ruby script would read the manifest, and generate a bunch of web pages from that. I got this working fairly quickly. I realized that updating this text file could end up being a pain in the ass as the number of photos grew, so I started adding more logic to my script to manage adding images to the file. I didn’t get very far with this. The command line script worked well, but I still thought as the site grew it wouldn’t scale. The first thing I did was drop the text file. I started using Datamapper as a front end to a SQLite database. I decided to worry about how I would update the site later and ended up moving everything over to Sinatra, which is a simple Ruby web framework. (Sinatra is so simple I figured out how it worked and got the site working with the new framework in the middle of the night after drinking at LeVack Block. I am a big fan of the framework.) The Sinatra application worked as well as my little Ruby script, but now the pages were being generated dynamically. This done, I started working on a seperate Sinatra webapp that would be used to manage all the images on the site. (I built a separate app so I wouldn’t need to worry about authentication: this second application would never be running on my webhost.) I managed to get adding images to the site working fairly well. I was at a bit of a loss as to how I would manage the sets of images I wanted to display. I left the site alone.

Late one night, after drinking a coke and being totally wired while trying to sleep, I realized that trying to be better at managing photos than Flickr was probably a waste of time. I put the Blansdowne site aside and started working on a little test site that would use Flickr as the back-end for a photoblog. Yesterday I finally put something up at VQVZ. Currently it’s simply a way to view all my photos on Flickr. It is similar to the site I Hardly Know Her. One improvement is that you can use the keys j/k to browse through the photos, and to move between pages on the site. (This is a feature I was bugging the guy who runs I Hardly Know Her to add.) The site can use machine-tags to display a subset of photos: for example, pictures of my lovely wife, and the same Blansdowne photos that started this whole process. This isn’t an ideal way to display sets, since you have no control over the sequence. So the next step in this project is to sort out displaying actual Flickr sets. Well, there is probably a lot more to do, but you need to start somewhere.

And that is probably more than you wanted to know about how my brain works.

Update: And i’m more or less done.


Using Local Gems on Dreamhost

   12 December 2009, late morning

This was tripping me up this morning. Dreamhost doesn’t have a lot of rubygems I use installed for everyone to use. I have gem installing rubygems in my home directory, under $home/local/gems. You do this by setting the environment variable GEM_HOME. In Bash, I have the following in my .bashrc file: GEM_HOME="$HOME/local/gems". In order for passenger to use your local gems when it is running a ruby web application, you need to set the variable ENV['GEM_PATH'] in your Ruby script. An alternative would be to “vendor” all the gems you need to use — that is storing them locally and referring to them explicitly. This seemed like pain in the ass. To see this all in action, here is rackup file I use to run the Sinatra app that is currently running blansdowne.ca.

Update Dec 18 2009: This looks to barely work. For reasons I haven’t quite sorted out, you end up with random Rack errors on occasion. I suspect it’s because Dreamhost isn’t the sort of place to host Ruby applications, but whatever.

Update Dec 21 2009: I think a more complete solution looks to be outlined here I’ve updated my Rackup file as well.


ImageMagick and jpeg-6b

   4 August 2009, early evening

If you grab the source for ImageMagick, build and install it, you might expect you’ll be able to muck around with JPEGs. You’d be wrong of course, you need to download and install the jpeg-6b library. Now, you might think a quick ./configure; make; sudo make install, is all you need to do get going with jpeg-6b, but you would be wrong. You need to run sudo make install-lib as well to actually build the libraries that ImageMagick needs to process JPEG images. This seems a bit convoluted. It’s not like JPEG is an obscure format.


Toronto Comment Killer

   12 May 2009, early afternoon

This is my gift to my fellow Torontonians: A greasemonkey script that will kill comments on articles published by the Toronto Star and the National Post. The comments sections for all the Toronto newspapers are basically giant hives of scum and villainy, a place for racists and cranks to hang out and shout out all the things society won’t let them say in public anymore. No one needs to read this stuff, unless you need high blood pressure. Placing comments inline with the news articles is obnoxious and disrespects the writers at the Star and the Post. This script fixes that. (The Globe and Mail no longer displays comments on their articles inline, praise the lord.) If you use Google Chrome, rather than Firefox, you can follow these instructions to use the script. Any problems, please leave a comment and let me know — It’s amazing how little Javascript I know.

Comment [2] |  

Java Here I Come

   10 June 2008, mid-morning

I haven’t had to write a Java program in ages. I think the last one I wrote was for CS341 (Algorthims), which would have been sometime in the Winter of 2002. After Algorithms all the courses I took used C++ — or were all about the math. Java looks a lot like C++, but the similarities end pretty quickly. The last time I wrote Java code it was all vim and the command line. Apparently that’s not the way people do things anymore. I’m downloading Netbeans – ever so slowly – now. I don’t think I’ve used an IDE since I was in high school. (Turbo Pascal, light of my life, fire of my loins. My sin, my soul.) I’m not a big fan of IDEs. I think they can sometimes hide too much of what is going on from the developer. With something like C++, I think it’s important to know how to cobble together a Makefile, and understand dependencies and the like. That said, I’m also not a big fan of doing crap work the computer can do for you. I’ll have to see how Netbeans works out.

Comment [3]  

Ruby & Python

   9 May 2008, early morning

Tyler mentioned on his blog, in passing, that one reason he likes jQuery more than Prototype is that the formers syntax is a bit object-oriented.

prototype has syntax which strikes me as antithetical to OO principals. for example, Element.hide(‘comments’) instead of $(’#comments’).hide().

I was thinking about the above while writing some Python code at work. I now prefer Ruby to Python, but it took a little while for me to warm up to Ruby. Ruby has a very terse syntax, and there is a lot of room in the language to write programs that look like that are composed of magic and pixie dust. (This is especially true when you look at Rails code.) Once you have written a few programs in Ruby it is a bit easier to see what’s up: where people have decided to leave brackets off, etc. Ultimately I prefer Ruby because if I want to know how long a list is, I can do so as follows: [1,2,3].length(). In Python, the same task is accomplished as follows: len([1,2,3]). The later just seems ass-backwards to me now.

(Python’s object-oriented programming support seems pretty half-assed, but I’m no expert in the language so my opinions of it may stem from my ignorance more than anything else. Still, what’s with all the self parameters. And __init__? Come on, you can do better than that.)

Comment |  

Plugins Table Plugin

   6 April 2008, mid-afternoon

It has been quite some time since I’ve written a plugin for textpattern. This plugin is quite simple; it will produce a list of the plugins you have installed in textpattern. To use the plugin, simply place the tag <txp:rsx_plugins_table /> in a form or page template. The plugin will produce a table, which you can style with CSS if you feel so inclined.

Download the plugin: rsx_plugins_table.txt. More information can be found at the Textpattern Forum thread for this plugin.

Update: I’ve added a new plugin that generates a definition list of your installed plugins instead of a table. This may be good for people who were trying to display the table in a very narrow space. I’m using this plugin right now on my about page. To use the plugin, simply place the tag <txp:rsx_plugins_list /> in a form or page template.

Download the plugin: rsx_plugins_list.txt

Update May 29th 2006: You can now decide to not show inactive plugins in the listing or table by using the show_inactive parameter.

Update Apr 6th 2008: You can now decide not to show the description field in the list or table by using the show_description parameter.

Update July 13th 2009: The code for both plugins is available on GitHub, as are the plugins themselves: rsx_plugin_table and rsx_plugin_list.

Comment [3]  


   28 November 2007, late evening

Today I discovered MobileScrobbler, which I have to say is a very cool application. It’s a Last.FM client for the iPhone or iPod Touch. It works like the desktop scrobblers that integrates with iTunes, pinging the Last.FM servers whenever you play a new song on your iPod. This is actually a good use of the network connectivity of the iPhone. It’s neat watching your Last.FM page update while out and about with your iPod. (The only thing I don’t like about the program is how it’s poorly written. Not that I can really fault a program someone is giving away for free.) Programs like this make me want to learn Objective-C.

Comment |  

Pointers and Arrays

   23 November 2007, mid-afternoon

I’ve been reading up on Ruby in my spare time, while writing some C code at work. The differences between the languages is so stark. Here is a little problem I had at work recently.

Read the rest of this post. (333 words)

Comment [2] |  


   8 November 2007, mid-morning

I installed Git on a couple servers here at work and on my machine at home in order to give it a whirl. Git is a distributed version control system, famous for being developed by Linus Torvalds. It is currently in use to manage to Linux Kernel. Git is quite different than CVS and its successor SVN in that there aren’t any central repositories you pull your work from and submit your work back to. With Git, you can clone an existing repository and it becomes your own sandbox to play in; you can create branches and tags and do all sorts of stuff in your own repository, which no other developer needs to worry about. To actually share your changes, the work flow suggested is that you set up a ‘public’ clone of your repository which you submit your final changes to, and which other developers pull changes from. (You could also just share your actual repository.) Although the system is distributed, a group could still maintain a single ‘main’ repository that everyone pushes their changes to, and pulls from when they want a final build of a product. The big plus I’ve noticed so far is that since you don’t need to talk to a server all the actions you perform on your repository are very fast.

Apparently Git was tricky to use when it first came out. This doesn’t seem to be the case anymore. Setting up a repository is dead easy — far easier than the same task in SVN — and adding files, changing them, and committing your changes is also dead simple. Perhaps things get trickier when you move onto the more esoteric features in Git, but I suspect for most of the work a developer does it works well enough.

Linus gave a talk on Git at Google a little while back. I had never heard him speak at length before. It’s actually an entertaining talk, though he’s a bit of a jerk-ass. And by “a bit” I mean he’s a serious jerk-ass. (It’s been a good while since i’ve been around that sort of arrogance: high school was a long time ago.) I do have to say I find his style of talking kind of refreshing. Presumably he’s waiting for someone else to come along, call him a moron, and show him how he should be doing things.


On Text Editors

   22 October 2007, early afternoon

I think every programmer should know how to use vi. It’s a small lean text editor that is usually found running on pretty much any Unix box you may find yourself in front of. I’m not saying you should know all the ins and outs of vi, but you should be able to start typing away if need be. I also think every programmer should know enough about Emacs that they can quit the program if they ever open it by accident. (FYI: Control-X Control-C will do the trick.)

Comment [2]  

Laying out Code

   12 September 2007, late morning

The placement of braces is a very contentious issue. People can get quite passionate about their placement.

Read the rest of this post. (237 words)

Comment [7]  

Multiple Header Files

   9 August 2007, early morning

When programming, related functionality should be grouped and declared in their own header files, with definitions of functions in their own source files. Dividing your source code neatly in this fashion allows code that requires this functionality to (ideally) #include just the definitions it needs, and no more. You should be able to look at the #include directives in source file and header files and understand the dependencies of the code contained within; you should be able to see the relationships between the functions in your program. If you are lazy about the file structure of your source this becomes difficult. Don’t be lazy.

[ed. I think i’ll make this into a bigger post on how to clean up messy projects.]


Building Git on Mac OS X

   2 August 2007, early evening

This is a brief guide for those who want to build and install Git under MacOS X. The install process is fairly straightforward. The only hiccup is that the development environment for MacOS X doesn’t come bundled the Expat XML Parser. I’m not sure who these instructions will be helpful to, as most people bothering to install Git probably know what they’re doing.

Read the rest of this post. (631 words)

Comment [33]  

A Funkaoshi Production and del.icio.us Links are Friends Again

   2 August 2007, mid-morning

I started using del.icio.us links back in May 2004. At the time I didn’t post links to this site the way I do now, inline with larger blog entries such as this. Interesting things I found on the net would get their own little blog post, regardless of how long or short that post might be; I wasn’t fond of doing things this way. Shortly after I started using del.icio.us, I began posting the links from there on the links page here. The page was populated with my last 10 or 20 links on del.icio.us, in addition to the links that are currently there. I also wasn’t too happy with this scheme, since it forced people to browse to another page to check for new links. That solution was short lived. When I started posting links here inline with my posts, I also started cross-posting those links to del.icio.us. This worked seamlessly till August 9th 2006. By this time I had really stopped checking my del.icio.us links page to see it was being updated properly, so I didn’t notice things had stopped working till some time in December. del.icio.us had changed its API and I hadn’t noticed.

Recently Jody mentioned he wished I posted my links to del.icio.us. (He is a lot more creative with the way he uses del.icio.us than I am.) Up until this time, no one had really said anything about the loss of my links on del.icio.us. I had really only been cross-posting for the sake of doing so. It was a programming exercise and that’s about it. Yesterday, I sat down and tried to figure out what had changed between del.icio.us and my script. The details are short and boring, but it didn’t take too long to fix things. My links are now being cross-posted to del.icio.us again.

A side note on PHP, and languages that let you pull variables out your ass: declaring a variable before you use it is a good thing. For example, in Pascal I wouldn’t end up with a bug like $title = urlencode($tittle);, which left me wondering why $title is empty when you urlencode it. Maybe i’m just a sucker.

Comment [1] |  

What the Functor?

   22 March 2007, mid-morning

A function object is any object that can behave like a function. A function object is commonly referred to as a functor, because function object takes too long to both say and type. In C++, we implement functors by creating classes that override operator(); syntactically, this makes a function call and a call to the member function operator() of the functor identical. Functors are used throughout the STL.

There are countless places where the STL requires you provide it with some code so that the generic task it aims to solve can be tailored to solve your specific task. Consider the STL set. When you instantiate a set you must provide the STL with information on how to sort the elements within it. (This class is implemented as a balanced-binary tree, and as such, needs to know how to keep the elements within it sorted.) You tell the STL how to sort your elements by supplying a function object that when given two elements from your class returns true when the first is “less than” the second — you define what it means for one object to the less than another.

This sort of behaviour would be implemented in C using call-back functions: supplying pointers to the functions you want some block of code to use. You can think of functors as the evolution of call-back functions; being proper classes, functors can encapsulate functionality nicely. Since functors do everything call-back functions do and more you should probably use them over call-back functions, more often not.

Comment [1]  

Function Definitions and Throw

   20 February 2007, early morning

Today while reading about auto_ptr’s — a topic for another day — I saw the function declaration/definition ~auto_ptr() throw() { delete ptr; }. I thought to myself, “What the hell is that throw() all about?” C++ can be a strange and esoteric language. Keywords get reused often, and mean different things depending on their context. Clearly this had something to do with exceptions, but what? After looking in my giant tome of C++ knowledge I had an answer. In C++ you can be explicit about what exceptions a function may throw. You do this by listing the exceptions within the parentheses following the throw keyword, which you include after the functions name. I have very vague memories of this being discussed in CS 246, though I can’t be certain it was. Anyway, I took CS 246 a bajillion years ago. throw() corresponds to a guarantee the function throws no exceptions. If you don’t include the throw keyword when declaring a function, then the function can throw any exceptions. In Java this is actually required behaviour: if your function throws an exception, you must list the exceptions thrown using the throws keyword. I haven’t had to program in Java in ages.

Comment [1]  


   1 February 2007, late morning

You can use the sizeof operator in C and C++ to find out the size (in bytes) of a type. For example, if we have defined an array char array[10], then sizeof(array) will return the value 10. sizeof looks like a library function, but it isn’t one, it’s part of the definition of the language itself. The call sizeof array also returns 10. In most cases you can use or drop the parentheses around the operand for sizeof. The one exception to this occurs when trying to determine the size of a type. If a type name is to be the operand for sizeof it must be wrapped in parentheses; if you don’t do this, your program won’t compile. I usually drop the parentheses for calls to sizeof so I can tell at a glance if its operand is a type or a particular variable.


Frontend Editing

   29 October 2006, lunch time

I’ve made a plugin to allow for front end editing.

Read the rest of this post. (374 words)

Comment [18]  

Inlining Functions in C++

   27 October 2006, lunch time

The inline keyword is used in C++ as a hint to the compiler that a function you are writing should not be treated as a normal function, but should instead be treated as a macro. When the compiler encounters a call to such a function in the source code it is processing, it will replace that function call with the function’s source code, its body. This _should _ make your program faster. (A function call is a slightly involved process.) You inline a function by prefixing its definition with the keyword inline.

Read the rest of this post. (385 words)

Comment [2] |  

Using poll Instead of sleep to Delay a Program

   12 May 2006, lunch time

The sleep() function in C will delay your program for some number of seconds you specify. If you want to delay your program for some number of milliseconds, then clearly sleep() will not work. A good alternative to sleep() is the poll() function. Normally, this is used to check if there is data to be read from a group of file descriptors; it can also double as simple sleep command. poll() takes three parameters, an array of structures (struct *pollfd), the number of elements in the array (unsigned int), and the number of milliseconds to wait for data (int). By ignoring the first two parameters, you can use poll() as a higher resolution sleep(). Simply set the first two parameters to 0 when calling the function, and set the timeout to be however many milliseconds you wish to delay your program. I use this when writing simple simulators at work, and it works well enough.

Comment [6]  

← ← ←