George Schneeloch

I guess I've always been more on the static language side of the debate. The first language I learned really well was C++. It has its fair share of problems and at times a heaping dose of ugly, but it does the job. I've also realized over the last few years that the static-ness of the language is somewhat up for interpretation. Static languages basically favor doing as much checking as possible when the developer is writing code, leaving as little as possible to go wrong when the user runs it. But you can make the same argument about dynamic languages combined with extensive unit tests. And then there are warnings and hints which don't quite guarantee anything.

In my time at my previous company I learned a lot at what makes unit and functional tests effective, and what doesn't. It's very context sensitive, what is worth writing and what is redundant. There are also diminishing returns for the number of tests written, since additional tests are usually testing something more specific than the first tests. The most common argument I've heard about unit tests is that the code needs to get tested anyway by somebody, so why not do it in a structured thorough way? It's pretty convincing.

More specific than static vs dynamic, languages offer a set of guarantees. C++ and Java guarantee type safety for function arguments while these things have to be tested for specifically in Python. C# bans drop through switch case statements, while Java allows it. It seems like C# would be slightly more static here, since you find out about the error at compile time rather than run time (assuming it's always unintentional.) I also greatly appreciate C#'s mandatory 'override' keyword, which was recently added to C++11.

The downsides of guarantees are that they make the language more verbose, or that they require a lot of extra planning without a clear payoff (for example, const in C++). A good IDE mitigates this somewhat with intellisense and error highlighting.

It would be interesting if you could turn on and off guarantees using something like compiler flags. I suppose it would greatly increase the complexity of the language, and provide headache to other users who now have to keep track of which libraries provide what guarantees. Maybe I'll just wait for the One True Language, its grammar written on stone tablets, to provide the objectively best guarantees and leave out everything else.

One thing I've learned when looking for a job is that it's valuable to specialize in a subset of the software developer world. I'm pretty scattershot regarding what I'm interested in sometimes. I've been applying to positions for Android developers as well as positions involving Hadoop in some way, which don't have much in common. I've spent four years using C#, which is rarely used with Android or Hadoop. Many positions look for a good software developer without getting too much into specifics, which works well with what I'm looking for.

But I've learned that there are certain things like frameworks that require experience to use efficiently. Good frameworks are more intuitive than bad ones, but all require some amount of time to get used to. For instance, I have a pretty good understanding of C# and the .NET framework, but I'm not suited for a position requiring knowledge of WCF or WPF, even though I've used web services and I have experience with UI development on other platforms. The learning curve for WCF and WPF may be short but it's still there.

I spent a lot of time attempting to narrow down a bug yesterday, only to find out that I caused it in the first place.

I've been unemployed for a little while recently, a choice I made in order to work on my own projects. I've gotten some work done but not as much as I wanted. I spend a decent amount of time at the libraries at MIT to minimize distractions for myself. That's worked for the most part.

One tendancy I have is to get lost in bug hunting. For example, Ubuntu runs pretty well on my Samsung Series 9 laptop, but not perfectly. Every so often the trackpad shuts down completely. The wifi sometimes stops, and I have to suspend and unsuspend my laptop to fix it. Sometimes when I unsuspend it won't show the login box at all, just a black screen. Overall these are intermittent problems and they don't really effect me much, but a part of me wants to fix it, at least the trackpad problem. But in my experience those bugs are often not as easy to diagnose as I think.

A little while ago I looked into a rhythmbox bug. When it switched between mp3's and ogg's it would play silence for the duration of the previous song, over the current song. So if the last song (an mp3) was 3 minutes and the current song (an ogg) was 4 minutes, you would hear only the last minute of that song. This problem only came up when I played songs in random mode, since it would switch between ogg and mp3. (The mix is something around half and half, with a small number of flac also.)

Needless to say I couldn't find the bug. Rhythmbox uses gstreamer for all of its sound and codec needs, so the bug could just as easily be in either one. I tried to record logs of rhythmbox working and rhythmbox suffering from the bug. The diff wasn't helpful to me, and it got pretty verbose. I tried making a gstreamer python script to reproduce the problem in a more simple test case, but it didn't work (although I am not familiar enough with gstreamer to know for sure.) And totem worked properly.

I think I spent a whole day trying to fix it, thinking that it would be an interesting learning experience. I'm realizing that some learning experiences are superior to others, and this one wasn't particularly useful. The problem is just too dense and unwieldy.

Eventually I found an already filed bug report here and subscribed to notifications for changes. That bug report was created January 2012 and in May a similar report was filed upstream in the Gnome bugzilla. About a month later a fix was committed. The fix looks pretty simple but I didn't have any feeling that I would have came up with that.

The trackpad issue is probably a similar one. I want to figure out what causes the driver to shut off, but there are so many variables to consider. Is it a bug in the device firmware itself? Is it a kernel module bug? Something with Xorg? And the intermittentness means it's sure to be difficult to investigate

Yesterday I bought the O'Reilly book Learning OpenCV and it's a pretty good read. I took some courses in college on linear algebra and multivariable calculus so I'm decently prepared for the mathy parts. I've only skimmed a few chapters but I feel like I could have a deep understanding of certain things like edge detection through this book. But it's also helpful in providing good examples to start with.

There's been a lot of talk about the Kinect as a great advancement in what's cheaply available to people for computer vision. I have yet to get one myself, I guess I just forgot about it over time. There are a decent number of examples (including one in the book) which create a depth map from two cameras. I'm wondering what kind of quality to expect from a 3D model created from cell phone camera images, and how much pruning will need to be done. I think I'll start with the stereogram example code and go from there