And now for something completely different: the post that I’ve alluded to for a few weeks (and as far back as last year)…
Atomic conditional inserts with complex conditions
I was going to blog about the software I’m currently writing, but that’s not happening, yet (although it’s been beta-test-ready for about a week and, given that I’ve made just under 100 subversion larger-than-ideal check-ins in the last seven days, it’s been getting refinements literally almost by the hour). Instead, I’m going to share a little trick I came up with to do atomic conditional insertions into a database without using triggers or conflicts. Indeed, I’m using little old sqlite3, so there’s nothing fancy going on in this database at all. Sure, the software I’m currently working on is probably going to be open sourced at some point, but this would just get buried in there.
Continue reading “Atomic conditional inserts with complex conditions”
Jam-packed week
Yes, it’s that crazy week again. Pi Day, Dead Caesar Day, and St. Patrick’s Day. But that’s not why this week’s blog post is so short… I’m trying to cook up a storm (having likely discovered one unrelated HTML5 bug in each of Safari and Firefox), so we’ll see what happens next week. Hopefully there will be less RFC reading next week.
Fault tolerant… public transit
I was going to write a proper blog post today, but I got stuck in a good old fashioned TTC delay for about forty minutes this morning (this also means I haven’t proofread this post nor thought too much about the topic). Some poor folks that left later than I may have been held up by multiple delays. Indeed, a single delay on the TTC seems to invite further delays. I.e., though long delays aren’t (that) frequent, once there is one delay, multiple long delays seem to crop up. If the TTC has statistics on the number of chains of delays that appear within half an hour of each other, I’d love to see if I’m just experiencing a memory bias (also likely). However, I’m not here to rant today, but to put some thoughts down I had during my bonus (cramped) quiet time today.
Continue reading “Fault tolerant… public transit”
Newest CS assignment for CSC120
Yesterday, Michelle Craig and I were discussing ideas for the last assignment for her CSC120 class, Computer Science for Scientists. The assignment had to include some components of databases, Python dictionaries, file reading, and string parsing. What we settled on was automatically generating a class composite; the idea was based off of what I had for the Food-In conference. Instead of including the group that each person belonged to as I had for the Food-In attendees, we’ll put something in like college, instruments played, favourite transition metal, or programme of study. Food-in composite, generated entirely in Python from individual headshots, after the jump.
Continue reading “Newest CS assignment for CSC120”
Hot Yam! Retreat
It’s reading week, so instead of taking up your precious reading time, I’m going to post some pictures. I was up at Hart House Farm at the end of January for a retreat with Hot Yam! and again this past weekend for the Food-In Conference, so I thought I’d share a few pictures (click to enlarge) from the Hot Yam! retreat in today’s post and some pictures from the Food-In at a later date. More after the jump.
Nonereliable
If your pocket calculator made a mistake every ten operations, would you still use it? Or if the brakes of your wheeled-vehicle of choice only worked 99.9% of the time, would you keep using it? Or what if one in every thirty flushes resulted in your toilette backing up and surprise alligators streaming out? After I lost all the data on my phone, save the Chuck Norris-like audio files, I started thinking about what technology I’ve abandoned because it was so unreliable that it was more trouble than it was worth, or “nonereliable” ((Yes, this entire blog post exists just so that I can make this word a “thing”)). More generally, I began to wonder what makes things or people so unreliable that we’re better off without them. So, in the blog post, I’m just thinking aloud, considering a few examples of things I consider to be unreliable and trying to determine some factors that influence whether I continue to rely on them.
I am Customer. Hear me ring!
Prologue
A fair numbers of people are under the impression I don’t own a cellular phone. I do. ((I’ve had one for a decade, now. I’m just very bad at answering calls and haven’t figured out this “voicemail” business, so I usually don’t give out my number.)) In fact, as of September, I’ve been the unhappy owner of an Android phone that’s more “special” phone than smartphone. The reasons for my discontent, as I’ve alluded to in a past blog post, lie in both hardware and software. Two weeks ago, I noticed that a minor software update was available for my phone (version 2.1 to a more recent version 2.1) and I thought that it might at least help reduce the number of random crashes/reboots I was experiencing. I expected to be no worse off, in any case. Instead, this software update managed to sour my opinion of both WIND Mobile and Android.
Debeakered: One year and 49 posts later
It’s been a year since Jorge managed to convince me to start blogging. Things have mostly been downhill since the 15K+ views for my iPad environmental impact analysis, but that was mostly to be expected, given the media coverage around iPad at the time. Besides, many of the views are just from spammers. However, truth be told, most of my personal favourite posts such as the Tragedy of the Commons 4-part series and Peddling an idea were written when I used to spend more time thinking about and writing posts.
Thoughts on programming for all: Part IIb — Downsides
Last week, I discussed one of the downsides of students being taught to think algorithmically, even if they absorb it all. Unfortunately, just because students can pass an introduction to programming course doesn’t mean they have any understanding of code that they or anyone else has written. Whenever I teach a course, I make a point to mention cargo cult programming and warn students not to fall into that trap.
Continue reading “Thoughts on programming for all: Part IIb — Downsides”