It’s so refreshing to see a well-written Doctor Who episode. It’s been years.
Now if they have more than one well-written episode in a row it’ll be a freakin’ miracle.
Archive for Geek
Sorting collections in Meteor.js
I was surprised to find that it was trickier than I expected to find a good example of sorting my collection queries in meteor.js. It’s not hard, but the syntax was different than most of the MongoDB examples I was looking at. Here’s a sample format:
Template.myTemplate.gizmos = function () {
return Gizmos.find({}, {sort: [[ name: "asc" ]]});
};
You can also accomplish the same thing like so:
Template.myTemplate.gizmos = function () {
return Gizmos.find({}, {sort: { name: 1 }});
};
Meteor + Firefox + Cookie settings = SecurityError
I first noticed these symptoms last week, and had this in the back of my mind to track down. I deployed our Meteor app to an internal server last week, and started having problems with Firefox. Firefox is still my default browser (yes, I’ve heard ALL THE THINGS about Chrome, but I haven’t changed), so it was a little sad to discover that my app didn’t work. In particular, my first page ended up being completely blank because a JavaScript exception was being thrown and no rendering was taking place.
Looking into the JavaScript log, I found this error:
SecurityError? The operation is insecure? Wuh?
Single Page Application
I’m increasingly finding the idea of the Single Page Application mind-expanding. I think there’s a tendency to think of it as “the type of application you might write in an easy domain”, but I find it interesting try to imagine how any application you might write would look different if you thought about it in terms of a single page application.
WisSched for Android
Made some good progress tonight. I’m going to hafta make some decisions about how much theming I’m gonna do. Frinstance: here is a snippet of info from the “Con Info” part of the app:
Internally, I store the content as simple HTML, and on the iPhone, I apply a bit of CSS glory to get a look and feel that approximates an iPhone feel (although I’m getting tired of that grey pinstripe background). Pop the HTML into a UIWebView and we’re golden.
The same general strategy works for the Android: throw the HTML into a WebView. But, in general, my Nexus tends to make very different default theme choices: showing white text on a dark background in non-HTML parts of the app. So I gave the Android version the most basic of CSS styles. This look fits in better with some of the other widget defaults. I’ll probably do some tweaking as I get closer to having a finished version.
WisSched on iPad
Yesterday, I submitted a new binary to Apple: there’s no WisCon 37 content, but I don’t want to wait until the last minute to get functional changes in place. There are a few new features, but the primary changes relate to iPhone 5 support and iPad functionality.
Here’s my favourite new piece, specific to the iPad:
The layout is dynamic: that is to say, that given all the panels, rooms, and timeslots, I’m able to lay it all out programmatically. There are tricky elements: multiple rooms that act as one room for certain events. The Gathering is sometimes considered to be multiple events that all take place in one room. And I want to do a second pass on my algorithm for time labels (what do you show when multiple time slots overlap?) But I’m mostly happy with the final result.
It’ll probably take 2 weeks before Apple approves it.
The Law of ‘S’
For me, a lot of the discipline about programming is about finding useful heuristics for a large number of circumstances. Today, was tracking down an error in someone else’s code that my usual heuristic would have saved me from. It involves the letter ‘S’.
Let’s say, for the sake of argument, that I’m making a banking application. And let’s say that I have to name something: a variable, a CSS class, an XML node, or a JSON property. In some circumstances, it might be meaningful to say “account” and in some circumstances, it might be meaningful to say “accounts”. Here’s my rule. If both forms of the word seem reasonable in context, then I always use the singular. And then, later, when I have to apply the CSS class, or read the XML node, I’ll know what form I chose because I’ll know I followed the rule.
Unfortunately, there’s one programming problem that I haven’t figured out a good rule for: other people. Other people write code, and aren’t as anal as I am. Bummer.
Objective-C Oddities
I was tweaking a bit of Objective-C code the other day, and stumbled upon one of those situations that seemed like it should be straight-forward, but which bit me. Consider the following.
My app is downloading some information in a background thread. Here’s my code:
NSData *data = [NSURLConnection sendSynchronousRequest:request
returningResponse:&response error:error];
if (error != nil) {
NSLog(@"error : %@", error.localizedDescription);
} else {
// check response code, etc.
...
}
The code compiled fine, but when I ran it, I would sometimes get an EXC_BAD_ACCESS crash. Turns out, the Cocoa APIs are designed to communicate information via the response type, as StackOverflow clarified for me. According to the Apple Error Handling standards:
you should always check that the return value is nil or NO before attempting to do anything with the NSError object.
So I’d needed to write:
NSData *data = [NSURLConnection sendSynchronousRequest:request
returningResponse:&response error:error];
if (data != nil) {
// check response code, etc.
...
} else if (error != nil) {
NSLog(@"error : %@", error.localizedDescription);
}
At some level, this type of error feels wrong. I’ve got a non-nil error object; it’s just in a state that I can’t use it. It feels to me like there’s something messed up with the way the API works.
But whatever. Data first; error second.
Caricatures of Agile: The Goldfish
As agile developers, we sometimes like to point our fingers and snicker at some of the more problematic personalities that can sometimes haunt waterfall development shops. To some extent, we take comfort from the sense that many of these personalities are able to hide out in the nooks and crannies of the waterfall methodology, but certainly Those Types Of People would never survive in an agile shop.
Take the classic example: the Hidden Deadbeat. While many agile environments force a lot of developer interaction by putting the team in a shared project room, the waterfall world still embraces the cubicle farm. And we’ve certainly met a large number of Hidden Deadbeats: people who don’t really do or accomplish anything, but who succeed in not doing anything for long periods of time because they don’t have to interact with people very often. If nobody really knows what they do, then nobody really knows that they’re doing nothing.
But agile projects have their fair share of… interesting personalities. There are some behaviours that are downright dysfunctional. Sometimes a difficult behaviour can provide a good counterbalance to another problematic behaviour. Pairing someone who just wants to get things done with someone who likes spending a lot of time thinking about concepts and theories creates a powerful team.
