In search of a Mobile Internet Device

I bought my first laptop about a year and a half ago nd I’ve been really pleased with it. It’s a 15.4″ Toshiba laptop sporting a 3.2GHz AMD Turion, 1 GB of RAM and a 160GB hard disk. I dual boot Windows Vista and Arch Linux and I haven’t had any problems with it so far. I think 15″ is a good size for a laptop that I use for a lot of coding and real work, not just light internet stuff. However, it’s getting a bit of a pain to carry around. I don’t mind taking it from my room to the engineering building to ‘set up shop’ for a few hours, but I think twice about lugging it about with me all day. And the battery life is nothing to write home about.

With professors piling on the homework, midterms around the corner and activities shifting into high gear, it’s getting really hard for me to keep my schedule in my head. I use Google Calendar with the lightweight Todoist as scheduling tools and it works pretty well when it’s time to sit down and make a plan. But I have to remember to actually put down my to-dos on my calendar and I tend to forget that. When I’m moving from one class to the next, it’s easy for me to forget when my friends asked me to meet up. I’ve missed one meeting already this week and almost skipped another. I seriously need to reconsider my scheduling strategy.

I’m seriously considering some sort of mobile internet device. I have wifi almost everywhere on campus and so anything that let’s me get to the internet with a decent size screen will do. Looking around the web there are a number of options that I’ve come across:

1. A Netbook

Take a laptop and make it drop a few pounds. Netbooks are becoming pretty popular on college campuses. The only major downside to these devices is the small screen size. The one in particular that I’m looking at is the MSI Wind. With 1 GB of RAM and a 1.6GHz (which looks like it can be overclocked to almost 2GHz), this is a very powerful package in a small form factor. Another great advantage is that it’s a full computer which means that I’m not limited to just using the internet. On the flip side, being a full computer means that it is something that needs to be turned on and off, or at least opened and closed. Though it’s small enough to be carried around almost anywhere, it’s a bit too much for a quick information recorder. I really would like something that could be slipped into a pocket. At about $300 to $350 for one with a long battery life, that’s a pretty considerable commitment for a college student.

2. The iPod Touch

Yes, the fairest one of them all. I don’t need the iPhone, the plans are way too expensive for the amount of calling and texting I do. However, take away the phone and the rest of it looks like a pretty good deal. It’s small and light enough to carried in the pocket all the time. It’s internet connectivity is good and many of the websites I’ll be using have interfaces made for the Touch’s small screen size. It also syncs very nicely with my Mac’s Calendar and Address Book. At $229 (less on Amazon) it’s certainly the cheapest device I’m considering. However, it is a closed platform, and if I ever find myself needing to push beyond what it’s capabilities are, I might be hitting a brick wall. Not to mention that most of the internet really wasn’t built for a 3.5inch screen.

3. Sony Mylo

This one of the devices I stumbled upon. Mylo is short for “my life online” and it’s designed to be an internet communicator focussed on college students. It’s meant to be more of an internet mesaging device with some media capabilities rather than an organizer. As a result it lacks any built in utilities for scheduling or organzing. But I do like the design, especially the full keyboard. However at about $300, I might as well get a netbook for the same price.

4. Nokia N810

This is a Linux-based internet device which is similar to the Mylo in terms of design. It packs a Mozilla based browser along with Flash and a Skype application. Being an open Linux platform, there are a ton of free apps available for it. Like the Mylo, it too has a QWERTY keyboard and is small enough to put into a pocket. However the lack of any builtin calendar or todo system combined with the $300 price tag does put it into the “might as well get a netbook” range.

5. The Archos line

The Archos line of internet devices do merit a mention even though I’m really not sondifering them because of the price tag. They come with a large screen and are very internet capable. However they are meant to be mostly media devices, which isn’t something I really need.

There are some really interesting options out there, all of which have their pros and cons. I’m still actively on the lookout and won’t be making a decision for a few weeks now. But at this point I am leaning towards the Touch. Not only is it light with a nice interface, it’s also the lowest price of all the options I’ve considered. However, I’m still open to suggestions and if I find something that I really like, I could change my mind.

Testing private methods revisited

I’ve previously advocated private testing as long as the tester was the same person who actually wrote the code under test. Over the past week I’ve been thinking more about private testing and been doing some more reading on the matter. One of the textbooks we’re using in our class is Head First Software Development where the testing is covered in quite some detail. In the book software testing is broken into three types:

  1. Black box testing : Testing the application as a whole from a user perspective with absolutely no knowledge of the internals. Think beta testers.
  2. Grey box testing: Testing the internal modules via their public interface. Think professional test teams.
  3. White box testing: Testing all possible code paths and branches. This would be tests written by programmers themselves.

I feel that this breakdown gets to the heart of how testing should be done in any software of reasonable size (where reasonable is anything over 15 non-trivial methods).  A lot of times programmers (especially students) get the idea that testing is someone else’s job. How they get this idea is easy to see. Writing test code is not particularly fun, it can be tedious and a lot of times it can take more time to write the test than it would be to manually poke and prod the software. So  if the programmers are going to spend all this time and effort writing test code, when on earth are they going to be developing the Next Big Thing?

What are tests really for?

While all the above comments are certainly valid, they all miss the point of testing. The point of testing isn’t to find obvious bugs that poking and prodding will find. Testing is for those hard-to-reach places in the code which only get executed once every thousand real-world iterations. A suite of tests makes sure that the program as a whole does what it is supposed so.  As a programmer you write tests to help yourself find the nasty bugs in your code. You do the black-box testing: pick apart the internals and let the grey box tests verify the public interface. When you’re sitting in front of your monitor debugging pointer exceptions, a good set of tests and a good debugger will help you narrow down the parts of the program that are misbehaving.

What we need is a change in the way programmers (especially students) think about tests. They’re not something that lets higher management, your professor or the project lead verify that you’ve done your job. Test are meant to help YOU. Just two days ago one of my friends was writing a Sudoku solver for a class project. His code was a bit a of a mess and it seemed to him that the solver was randomly skipping certain places and leaving them blank. No matter how much I yelled at him (and yes I did literally yell at him) he refused to write even basic tests.  He would rather fill his code with System.out.printlns rather than write some unit tests, all this despite the fact that he needs to turn in unit tests for his project. He was doing the same set of manual pokes and prods every time he made a change to his code. It took me a while to realize that unit tests are more than just a chore and I really hope other students take this lesson to heart.

Testing needs to evolve.

The other side of this is that tools need to evolve to support programmers and testing. In particular programming languages need to have support built-in for testing. There needs to be proper security models that allow efficient testing of private methods while keeping them private for production purposes. Neither JUnit for Java nor CppUnit for C++ allow this and I’m not sure about the technical feasability of it, but it sure would be something useful to have. I’m not a fan of IDEs, but the Eclipse environment does a good job of flagging basic errors as you type. It’s this sort of deep integration that testing needs to evolve toward. Standard hand written tests for whole methods are great, but we should also have ways to insert specific values into smaller code blocks and test the outputs. Think of a debugger mated with a test environment. A lot more programmers and students would use tests if there wasn’t boilerplate to go along with them and if they could be created and saved on the fly.

Closing words

Testing is a integral part of software development. If you can’t (or won’t) write at least basic tests for  your code, you shouldn’t get a job writing code. You don’t need to be proficient in the latest whizz-bang testing framework (yet), but you do need to be able to understand the basic concepts and pick up a framework in a few hours. You should understand why manually littering your code with prints is a bad idea (except in simple cases).

At the same time, we can’t pin the balme on students, programmers and the education system. Software engineering is one of the few disciplines where practitioners can seriously build their own tools. There needs to be an active effort from working programmers to create more powerful test tools that allow more direct code analysis. I can’t say more about this because I really don’t know how where the state of the art is at the moment, but I know that the tools most programmers use need to advance tremendously.

But like many things in technology, forward is the main direction of movement. As compiler and virtual machine technology improves, I’m pretty confident that testing technology will go along for the ride. I’m really looking forward to the day that I can select a block of code and run real time tests on it. What do you think? Is testing something that is worth time and effort (both in terms of creating tests and creating tools) or can we do without them?

Simplicity first, everything else somewhere after that

I’m currently hard at work putting together a GUI for my research project using Python, Qt and the PyQt interface. Actually that’s a lie, I’m forcing coding in between classes, homework, meals and gym time. Anyways, the point is I’m building a GUI using PyQt. Qt is really quite an advanced toolkit which does much more than just let you build a pretty interface. While the full powers of Qt certainly merit a full series of blog posts on their own (and I’m certain someone has already done just that), one part  of the toolkit that I find really neat is their framework for displaying complex data models.

Here’s the basic idea: you have a somewhat complicated data structure sitting around and you want it to be displayed as some sort of list or tree-like structure. You also want the user to interact with the data structure and any changes made to the structure should be reflected in the display without you having to explicitly control the updating. Qt gives you a way to do this using models and views. First you have to build a model of your data as a subclass of the QAbstractModel class. Your data needs to be able onto a grid-like structure of rows and columns and your subclass controls how that mapping takes place. You then hand off an instance of that subclass (with the data you want to display) to some display widget, generally a list of tree view. This widget then becomes (as the name suggests) a “view” on to the underlying data model. Changes made to the data automatically make their way to display via the model you specified and vice versa.

As you can understand, I’m hiding the details, and believe me, there are a lot of details. While it’s really nice to have this automatic mapping if you have a complex data structure, it’s implemented via this rather complex structure of interacting classes and objects layered on top of each other. The result is that when you don’t have a complex data structure, jumping through the hoops and navigating the network of QSomethingOrTheOther objects is simply a pain in the ass.

My system has a routinely updated list that needs to be presented to the user. My first ideas was to implement a Model-View structure so that I didn’t have to handle updating the display maunally. Bad idea.  While I certainly got the system working to a certain extent, my resulting code a was a mess of interlocking method calls and object juggling which really seemed unjustified considering that I was just displaying a simple list. I eventually decided to take the plunge and in twenty minutes rewrote most of the relevant parts. The result was a dead simple item-based list that would get updated in response to particular method calls from the rest of the GUI elements.

Lesson learned: simplicity first. It is very tempting to just go after the most complex, most theoretically solution. After all, the tendency to tinker and try out new things is deeply ingrained in the hacker psyche. But sometimes our search for carefully ordered, hyper-complex order descends into a chaotic mess of obfuscated code that really does a lot more than is necessary. The simplest solution is often not the best but a lot of the time, it’s just good enough. And in the case of software, good enough is often better than perfect. Remember that you’re not just coding for machines, you’re coding for people too. If your first reaction to your own code is WTF??? then something needs to change. Have fun coding simply.

Looking for practical software engineering exercises

I do believe in the old saying that practice makes perfect. Of course things aren’t so simple and it’s important to the right kind opractice, but without practice it’s impossible to develop a mastery of anything. Software engineering is no different. You can spend all the time in the world reading about Agile development practices and Object-oriented design, but if you don’t produce working software projects on a regular basis, you’ll never experience what it means to face all the troubles and diversion that can crop up along the way. The act of taking a project from development to finish allows you to hone your skills and learn from your mistakes and hopefully make sure that your next product works just a little better than the last one.

The greatest concern I have about modern computer science classes (at least the ones I’ve been) is that students simply do not have the chance to practice. Sure there are labs and projects and multiple hours spent a week, but almost all of that time is devoted to just learning new concepts and getting to know how to use them and not does not allow for the honing of the learned skills. You can’t really blame the schools, because they have only four short years to teach students what they need to have a bare minimum of competence  and college is about more than just living your major 24/7.

All that being said, I still do wish that there was a way for interested students to hone their skills if they had the time and the desire to be better and what they’re learning to do. For a lot of things this is actually quite easy. Thanks to the fountain of knowledge we call the internet, students can easily find tutorials and exercises on a lot of different topics for free online. All my knowledge of Python comes from the internet and I’ve used online sources to practice functional programming in ML and Lisp. I’m currently on the look out for software engineering exercises.

My software engineering class has weekly labs and two projects during the semester, but they’re not really enough for me. The labs are designed to teach us the C++ and other tools like Kdevelop and Doxygen. However for someone like me who already has experience with 2 other object oriented languages under his belt and some previous knowledge of C++, the labs are not very hard  and take less than the 3 hours a week allotted to them. One of the projects is designed to teach us the whole process of software engineering including requirements gathering, use case modeling, design and finally implementation. The other project is basically a test of basic competency in C++ and object oriented programming. While the projects are good in the sense that everyone in the class gains a good idea of what software engineering is all about, there isn’t enough time to hone specific skills. In particular, I’m more interested in design and implementation than I am about requirements gathering. I’d like to be able to practice taking a sufficiently detailed description of a project (say a description of the public interface), designing the class structure required and then implementing it into a working program. This would not only give a chance to hone my programming skills, it would be a great way to get more practice with the tools that I am not familiar with (namely the make system and the debugger).

In some ways, it would be good there was a more lab intensive version of my softare engineering course, but since that is not the case, I guess I have to look elsewhere for what I need. The problem is that my searches are yet to turn up anything of real relevance. It seems that most software engineering are geared to giving a rounded view of the subject, teaching tools, techniques and theories all at the same time. As a result even the exercises that I can find online are either exercises in C++ or Java (not what I really need) or else larger full length projects (also not what I need).

I’m going to keep looking around the net to see if I can get what I want. I also hope that some of my many forum postings around the net will turn up something. However, while that happens, I’m trying to design my own mini-projects. For one thing our labs use a simple account management system as an example. I’ll be working to develop a more fleshed out version of the account manager putting into use what I’m learning in lab and in class. If any of you reading this post have any ideas or know of resources that match what I’m looking for, please drop me a note.

Testing private methods (or not)

As my software engineering class progresses I’m gradually bringing back old habits of writing unit tests and carefully designing class methods to be unit-testable. Yesterday as I was doing a lab dealing with pointers (we’re learning C++), I ran into an issue which I think might be a serious problem in the weeks to come. We’re using the CppUnit testing framework and CppUnit won’t let me test private methods. I haven’t seriously looked around to see if there is a workaround because there’s a more important question here lying under the obvious “how”: should private methods be directly tested at all?

A quick Google search reveals lots of opinion both for and against unit testing private methods. The important arguments against are:

  1. Testing private methods breaks encapsulation and hinders the developer’s ability to refactor even if the external interface is preserved. This has effects on the efficiency of your software production cycle.
  2. If testing the external interface (via public methods) doesn’t adequately exercise private code, then why is the private code there?
  3. If you are convinced that the private methods need to be tested, that can be a sign that the private code needs to be refactored into a separate class.

Proponents of private testing will offer the following arguments:

  1. Anything that can break should be tested.
  2. If you’re going through an interface to test something beneath it, that’s not really unit testing, is it? (I actually just thought of that right now, not sure if it has come up before.)
  3. Testing should be fast and give precise feedback. Having to go through intermediate methods can slow down the tests and more importantly can make the source of failure ambiguous.

I’m sure there are other more nuanced arguments on both sides, but I think this gives a fair overview of the situation. As you can see, it’s not a simple case of practicality vs theoretical purity. Both sides have practical and theoretical arguments.

I am mostly a proponent of the practical side of things. I believe that rules and frameworks should be designed to enhance our productivity and at the same time, we need some rules in place to make sure that we are performing as best we can. With such a mindset, a decision isn’t easy. On the one hand, I would like all of my code to be tested at as fine grained a level as is reasonable and I should be able to find errors on an equal level of granularity. The minimum level of granularity I’m ready to accept is the method level. That means that every method should be tested individually and when a test fails it should unambiguously point me to the faulty method. If I need finer detail than that I can pull out a debugger.

But at the same time, I highly value my professional freedom. When I agree to write a piece of code to do something, I should be given maximum freedom within the constraints of working as part of a team. That’s not an excuse to write faulty or obfuscated code because other people will almost certainly be using and/or maintaining it. However, I should not have to go through a lengthy test-passing-approval-getting process everytime I refactor a method into two or more smaller ones. That of course is argument #1 against testing private methods.

Since I hold practicality in such high esteem, I think the need to testing anything that can break is of paramount importance. If your code can break, you need to know about it as soon as possible, encapsulation be damned. It’s not that I’m not outright rejecting against arguments #2 and #3 (I’ll get back to them later) I’m just saying that I hold ‘for’ argument #1 as paramount. With that in mind, unit testing private methods becomes necessary and I need to find a way around the objections.  To solve #1, perhaps what is needed is a slightly higher level look at the problem. Tests that exercise your code fall into one of two categories:

  1. Tests that you’ve written yourself for your own code.
  2. Tests that other people have written for your code.

I know that many large software houses have employees whose job it is to write to test code, but even if you know for certain that there will be other people testing your code, you should write your tests. By doing so you can take a swing at objection #1. Tests written by the team’s testers will verify the public interface and make sure (hopefully) that your code as a whole does what it’s supposed to do. But your own tests will make sure that the internals of your code are safe. Here you can test for yourself any edges cases that the public interface might let slip through (for various reasons). Since you control both the tests and the code, you can decide when some tests no longer make sense and remove them accordingly.

Of course, this isn’t a bulletproof solution to the problem. There are all the potential problems associated with writing your own tests: it takes a certain amount of discipline and dettachment to write stringent tests and it can be tempting to just write tests that you know your code will pass. It’s up to you as a developer to develop the proper mental attitude. Plus there is always the mental overhead of actually writing and maintaining your own tests in addition to your code. You have to decide for yourself if you’re up to the job.

Coming back to the original list of objections to private testing, #2 and #3 are still unanswered. In fact I don’t think they really have to be ‘answered’, because they point to more underlying issues. #2 raises the question of simplicity. If your code does more than it needs to, that opens up the door to bugs that could easily be avoided. If external callers will never actually call some part of your code, you really should consider leaving it out. #3 is a derivative of object oriented design: if you need to be calling code regularly from an external source, make it it’s own class rather than nesting it layers of accessor code. The logic of this argument is undeniable, but every once in a while (and probably more often) you need to sacrifice the purity of OO for something that is more convenient. That being said, I would still very much encourage you to be careful about where your code is and why it’s there. Good design can make your life as a programmer much easier.

So the final verdict (for me at least) stands thus: test your private methods. However you should not use this as an excuse to write ill-designed code in the hopes that testing will catch the bugs. Testing should be applied to catch any errors that have not been eliminated by careful design, not as an end-of-cycle precaution in the hopes that everything does what it’s supposed to. Use private method testing proactively to pinpoint and eliminate hard to see and unexpected bugs, not as a blanket measure against anything and everything that can go wrong. If your code passes public testing but fails private testing (or vice versa) it’s still bad code and everything that can break, will break. If you’re going to use tests at all, respect what they tell you.

Of course getting your framework to allow private testing without badly abusing object-orientation is another matter altogether. And I haven’t even started looking for an answer to that one.