What I Learned Today

WordPress tells me this is the 17th post I’ve written. That’s not true at all. I know it’s not true. This is the 31st post I’ve written. But the missing 14 or are gone forever. Why? Because in my own hubris and impatience, I deleted them forever, accidentally, at 2am this morning.


Using Amazon Linux, I installed the (then) current versions of apache, mysql, php, etc. That’s fine. They’ve worked great. But a program I wanted to play with required PHP 5.4+, while I was stuck on 5.3. So I uninstalled PHP, but then needed to update apache, mysql, etc. – so I just uninstalled them all, purged everything, and installed newer versions.

I purged everything.

I purged everything.

I purged everything.

I purged the mysql database.

All of my posts are WERE stored in that database. All of the data from my project management software were stored in that database. All of the user login data from my site were stored in that database.


When I told my wife I’d done this, the first thing out of her mouth: “Did you do this really late last night?” Yes. Yes I did. Just like she’s been reminding me not to do since she was my girlfriend. I know better. It happens A LOT (though never this critically – see lesson 3…). I know by know that when I wake up at 6am with 4 hours sleep, work a full day, grab supper and run out to a function until 10pm, get home at 11 then work for 2 more hours until I’m passing out – that is not the time to do what I did.


The only reason this is post 17 and not post 1 is I do have a backup from the end of February.

This is what I’m kicking myself the most over – because the very last thing I put into the mysql database (I’m not kidding) is a reminder to myself to set up a regular backup system.

The irony of this is agonizing.

What I Lost

2 months of blog posts – my World War I series 100 years later in Real Time (each Saturday, releasing a mock news article about what happened 100 ago to date). 2 months of project management work items/tasks/bug tracking/etc.  Other things I don’t know yet.


1. Regular backups. Since I write bi-weekly, I’ll just do it after each article.

2. Don’t do anything after 11pm that can’t be CTRL-Z’ed.

3. Understand what the command I’m about to do does.

4. Get away from my computer right now before I break it physically.

I’ve mentioned it before, but I just wanted to reiterate: I’ve been much more productive with the pomodoro technique the last few weeks. I use kanbanflow.com to manage it – the combination Kanban board and pomodoro timer works great for me. In the past, by todo list has been pretty random, ad-hoc, and subject to constant changes.

Saturday, I set up my board – my todo tasks for the following week. This will range from “Exercise like this” to “Read this” to “Update that.” Each morning, I make sure my hard-copy planner matches up with what’s on the board, and also do a review of the previous day to see how I did. I DO NOT add anything to the new day’s list that morning – any additions were done on previous days. This means that my list is feature-locked each morning. I feel like this is a little bit of Scrum – Sunday I review my previous week, check to see what I need to do this week, have daily standups to see how I’m going, and check my progress at the same time.

The pomodoro advantage increases productivity first by keeping me focused (“I can focus on this huge task for just 25 minutes”), removing guilt over relaxing (“I’ll check that email in 7 more minutes” [yes, I feel guilty for taking breaks]), and also letting me keep track of my time (“Ugh, I spent 45 minutes reading email? That’s awful!”). I’m still crunching numbers on my productivity last year and so far this year, but when I get to a good point (perhaps end of this quarter) I’ll take a close look at how it’s been.

I had originally intended to spend this post discussing Ceedling, and Unity testing, but now I won’t. Why? Over the weekend, I was reading the API guide for Arduino libraries, and realized they’re heavily focused on object-oriented programming. Synthduino was written in a functional style (it’s C) – while I’d used a basic struct to hold together a note’s frequency and duration, all the calls where global functions that accepted either a note or one of its members as a parameter. This was contrary to the API.


I did research, trying to find a good unit testing suite for C++. Turns out I’d somehow missed what should have been a top result: Google Test (aka gTest). I had gotten distracted by the Wikipedia list of suites, and gone through there. If only…
Anyway, I’ve spent the last 2-3 days rewriting Synthduino in C++, with classes, and rewriting the test suites. Fortunately, the logic and test data is the same, so I’ve got that going for me. Once I’ve spent more time with Google Test, I’ll try to do a better comparison between it and Ceedling/Unity.

Wherein our hero fights the dragons of cross-platform compatibility, libraries not being updated, inadequate documentation, and the fact that Arduino can’t do unit testing natively.



I’m currently working on the new release of my project Synthduino, and I’ve fallen in love with Unit Testing from various Ruby and Ruby on Rails projects I worked on last year. I decided it would be good to bring unit testing to Synthduino, not only to give me a clearer roadmap of development (unit tests help focus effort), but also make sure my work is good quality (as I do want Synthduino to be used).


I briefly considered writing my own framework, but I’m not really comfortable enough in C/C++ to do it, so I looked into frameworks. Based on what I read, I narrowed it down to two options: CppUnit and Ceedling. From what I gathered, CppUnit was the more established of the two, but Ceedling was built on Ruby to use rake. I decided to try them both out.


My development platform spans 5 computers and 4 operating systems (Ubuntu, Lubuntu, Linux Mint, and Windows 7), with a git server running here. I needed something that would work moderately well on that.


I started out with CppUnit. The biggest issue I ran into was the complete lack of documentation (seriously – is there any? It’s advertised as a “C++ port of JUnit” – am I supposed to use the JUnit documentation?). I looked around online and found a lot of tutorials that all used completely different ways of doing the same things. On top of that, none of them actually worked on any of my machines – every attempt to do anything, no matter how minor, was a long string of compiler errors or stack overflows.

I looked to Ceedling. Off that bat, I did like it more – it came with example projects, and included documentation (though it was hard to find). I liked the ability to use rake, which I’m familiar with, including the ability to set up stubs for everything with an easy rake command. My biggest complaint would still be that the documentation is a little sparse (and online it’s nonexistent). BUT it’s certainly sufficient, so I can’t complain too much. I’m able to get things done, make my tests pass, and so on.

The only bug I ran into was in functions that used printf – I spend about 4 hours tracing stack calls, overflows, missing symbols, and so on until I tracked it down – an error that had been fixed in Unity in August but not found its way into Ceedling until December (after I had downloaded it). Otherwise it’s been great.


Next time I’ll actually look at some of the testing.