In the last post, I talked about getting unit testing set up in Xcode, why you should write unit tests, and what kinds of things you should unit test. Now, I’d like to talk a bit more about how to write unit tests. If you come from a background doing unit testing, as I did, it’s very straightforward. If not, I’ll spend a little time explaining things a bit more.

One of my personal preferences when testing MVC code is to test my model using a commandline test driver, so when Samuel Goodwin and I were talking about testing code and he brought that up, we started discussing ways to more effectively write those commandline drivers. Long story short, we decided a useful strategy would be able to provide a library to parse arguments like ‘key=value’ into a dictionary. Since we will be doing a lot of iOS app work, and quite possibly desktop Cocoa work later on, we decided writing a class to do this in Objective-C would be useful, and about 24 hours later, FlexArgs was dumped onto the world. But that’s not what I want to talk about here. Rather, I’d like to discuss what I’ve learned about unit testing in Objective-C. As a developer who does a lot of testing in C and Python already, I immediately made it a priority to learn how to do this. In this post, I’ll go over basic unit testing, doing code coverage, and writing better tests. I’m particularly aiming this post at people who know how to code and test, but want to do it more effectively in Objective-C or want to learn how to get started.

I just finished up the first unit of Udacity’s CS373 (Programming a Robotic Car). It’s been a lot of fun, and reminds me of why I love Python so much. In this post, I’m just going to go over what the end result of the first week has been.

I was at an Appsterdam lunch meetup today, and before the presentation I was talking with some people about source control. They worked for Atlassian, and so of course bitbucket v. github came up. (It didn’t help that I was wearing a GitHub shirt. Atlassian - I want to give you money to get a bitbucket shirt but I don’t see any for sale. Why?) Regardless of why I typically use github more, or what my usage profiles are for the two, they were interested to hear my solution to a problem I had: how to simplify working in various source control systems, particularly in both mercurial and git.

Inexplicably, for the longest time I was reticent to enable any sort of analytics on my personal site. Partially because, to be honest, it’s not as if my blog is well read (or so I assume, but soon I’ll have numbers to back that claim up). As I try to get more involved in the world, I’ve found my site is useful as a portfolio of sorts - not so much in the way of “look at my sexy site” as “here’s the cool things I do”. I’ve noticed that GitHub has had some DDoS issues lately, and as I host this site on my GitHub pages, I wanted to minimise any potential downtimes. I’d also noticed that some of my pages were a bit on the slow side to load, as Octopress appears to load quite a bit of javascript. I admit to being a fan of many of the asides, and to have written some of my own.

One of the great things about paradigm shifts is we can throw out the old and start from scratch, getting rid of all the old cruft that’s built up over time. Computers are no different, and the tablet revolution has allowed us to rethink a few things. It looks like Apple is finally converging some of the lessons learned with iOS and OS X. So, let’s take a look at some of these ideas:

It took me a bit to get my Aquamacs install up and ready to do Clojure and SLIME, so I figured I’d jot some notes down for future me and anyone who happens to be listening.

In the last post, we took a look at the basics of set theory. Now, I’d like to take a look at how to actually make use of it in your code.

One of the issues with practically using the code in the last post is that the initial subsets were defined arbitrarily and not derived from the superset. In this post, all the examples are derived from the superset. We’ll use a couple techniques for doing this illustrate some of the various ways to do it.

In Python, we’ll use an object-oriented approach, creating a few classes and working on Book objects. In Clojure, we’ll use records. Though we’ll approach language a little differently, I hope they still bring clarity to the subject.

Noir v. Flask: the shootout

I wrote a quick REST API server as an illustration for a blog post, but I wrote both a Python and a Clojure version. I wrote a test suite to cover the entire API (of course - you do write tests too, right?), and I figured while I was at it, I might as well benchmark the two. Here are the results of 1,000 runs:

Recently, I was explaining to someone the basics of set theory and how the various basic operations translate to the real world. I used the example of the project I’m currently working on, which is a web front end to my ebook library. This is a very quick introduction aimed at people with a programming background but who don’t have a strong math background; the goal is to help you to learn to use them without having to delve deep into the math behind them.