I found an interesting dilemma while working on an open-source project. My asking about possible solutions on Stack Overflow and the LinkedIn Q&A Software Development category didn’t yield any good answers, so had to do some research to find the solution.

But what was the problem?

First of all, the open-source product has two different distributions: downloadable binaries for end users and a source code repository for developers and contributors (and end users who want to peek at the source code!). The repository contains the production code, which compiles into those binaries, and — because it was written in the modern clean-code, TDD manner — a bunch of automated tests. The tests have dependencies on third-party tools. The problem is, can we include those tools in the repository? Is their license text required, no, is it even legal? What is the common practice?

It turned out not many people know the answer or understand this kind of stuff – just read the answers I got.

Before I reveal the correct answer, why do I want to check in those tools? I want to send a message that tests matter and this is how we do things here. At the same time, I want it to be very easy for the potential contributors to check out the code and run tests right away! I don’t them to worry whether they should download NUnit version 2.2.8, 2.4.7 or 2.5.2.

OK, the correct answer: based on my analysis, here, the common practice is to check in such dependencies. A copy of the license must be included if the third-party product’s license requires it. I learned along the way that the Apache license has such a requirement, while zlib and the New BSD License(a. k. a. the “three-clause BSD) do not.

Continuing what I started in the previous post, I want to mention three more articles that quoted me this year.

Degrading Web Apps Gracefully (appeared on the Linux Foundation’s Web site in April) discussed how to build Web applications such that they work on many different browsers in use these days. I contributed two bits of advice. In the Write for the Audience section, I reflected on what we did at WhenU to collect data and know the breakdown of our userbase by the combination of OS and browser. In the following section, Testing is a Must, I described how virtualization technology, VMWare in particular, can be used to test those combinations. I also made a reference to the minor deviation of the HTTP protocol implementation on Chinese- and Korean-localized versions of Windows that burned us at the end of 2005.

While contributing to Convincing the Boss to Pay for Developer Training, I stated my belief that developers get a lot more from books kept on their desks than books kept on a common shelf or a company library that they have to walk to. They simply open the book much more often.

An finally, a great article Gosh, Things Are Better for Developers These Days came out in June. People were asked to name what is important in software development today that didn’t exist ten years ago. We actually found quite a few things that seemed new but existed in the 1990s and several things that seemed old but definitely invented after 2000. Although none of the contributors were mentioned by name, the “LinkedIn friend” in the 4th paragraph from the bottom, speaking about test-driven development, unit-testing and mocking frameworks was me. I also pointed out to the author that the Design Patterns book by the Gang of Four was published in 1994, so it was not 10, but 15 years old. I was very surprised myself when I looked that up and thought that was a good counterexample.

I was quoted in a number of articles this year (software-related, of course). I didn’t participate in the opinion-gathering process for fame, but to practice an important skill: to reflect on my own professional experience in a way that is helpful, not verbose, and makes sense to other people. As a result, my quotes ended up in five online articles.

The first one Running an Effective Code Review appeared in CIO.com. It was actually a series of articles, each dedicated to a different aspect of code reviews. In What to Look for in a Code Review, I reflected on the situation that we had at WhenU at one point in 2004, when one developer was put in a tough spot and had virtually no other way but to write pretty bad code, but criticizing him personally was clearly the least productive way of dealing with the situation. In the How to Lead a Code Review, I made a general comment about reviewers’ availability.

Then there was a humourous Java World blog post about moments when you knew the interview was over (from the interviewer’s or the interviewee’s side). My contribution, a humourous phrase someone actually said to me during an interview, was on the list. I won’t tell you which one; the quotes were anonymous for a reason.

Then there were three more serious articles, but I’ll leave them for another blog post.

I’ve listened to Roy Osherove’s NDC2009 talk on unit-testing and mocking frameworks (link to video) recently and liked his terminology. A fake object is a mock if you verify its call expectations later, otherwise it’s a stub.

But on the other hand…

I have a project with a class named ServiceStub. It is named so because it communicates with a client-side proxy of a Web service. To test this class in isolation, I need to fake a Web service. What should I name the fake web service class? StubService? Great, now I have a service stub and a stub service in the same context and that’s before I tell you that some of my service stubs depend on multiple services. Confusing.

So, I named this class MockService even though it is, strictly speaking, not a mock. All rules should allow for exceptions.

I’m registered for the Toronto part of this conference, which will take place on October 23. The registration tickets were selling out quickly, but my boss approved the time as part of our professional development plan very quickly as well (meaning I won’t have to take a vacation day to go to the conference). The approval of the conference fee and travel expenses had to go though our company’s finance department, taking much more time that it would take the tickets to sell out. Still, I decided it was worth the risk at US$99 (my credit card was charged for Canadian $119).

What am I looking forward to at this event? Getting the gist of some new technologies I know little about, meeting interesting people in my profession, finding out what they work on and what interests them, and identifying industry trends.

I’ve recently connected various hardware to our new home PC, which is a 64-bit Vista laptop. This task involves downloading and installing 64-bit versions of device drivers for every device and gadget you own, because 32-bit drivers no longer work. 64-bit drivers didn’t exist for every device in the early days of Vista, but you can easily find them now.

Did anything bad happen? Yes, but not what you think and it had nothing to do with Microsoft. And let’s start with what went well, so which hardware vendor gave me the best user experience with their driver software? Seagate. I searched their site, found the driver, click-click and the external hard driver started working.

And who was the worst? Canon and Epson. Canon’s installer refused to install anything because my brand new PC didn’t have an older version of their software, which was installed from a copy-protected disk that came with the camera! Their software is obviously compeletely useless unless I have also bought their hardware and this fact seems completely lost on their product designers.

So, buyer beware! The price Canon and Epson are willing to make you pay for their copyright peace-of-mind is that you go to your storage room, rummage through several boxes and find that dusty CD. The old software won’t even work on the 64-bit Vista, but you need to have it installed to prove that you are not a thief. Installing it will also replace your Adobe Acrobat 9.0 with 7.0, which is bundled with the camera driver for your convenience and some PDFs will no longer open, but you can fix that later. If you’ve somehow lost the disk, you’re in the same boat as pirates and that’s your problem.

There is a better way and, evidently, I am not the only one having this opinion.

One of my colleagues mentioned in a recent meeting that many developers perceive unit tests as not fun and that is a real challenge in the adoption of test-driven development (and, of course, agile development, which includes other things besides TDD).  My answer to that was to bring the fun back into this activity by writing better tests.  I recommended a book that I believe can teach software developers how to write better unit tests, “xUnit Test Patterns” by G. Meszaros.  I have recently posted a review of this book on Amazon.

Imagine the following conversation between two developers that could have taken place years ago.  Developer A wants to make a transition to object-oriented programming and asks Developer B for advice.  Developer B simply says, “just use C++.”  This doesn’t make sense, does it? We all know now that there are things like object-oriented analysis, design patterns, refactoring, and that the knowledge of the syntax of an object-oriented programming language is by far not enough to produce good object-oriented designs.

Yet how many people would take a simple “we just use nUnit” (or JUnit) for an answer to the complex question of how to write unit tests?  What often hides behind this simplicity is a development culture where tests are an afterthought, poorly designed and hastily written.  When the design of the system under test changes, or something changes in the system configuration, or different test data sets are loaded into the database, these test begin to break and require a lot of work to keep them working.

Fortunately, it doesn’t have to be that way.  Someone has done the work on the automated unit testing similar to what the Gang of Four did on the object-oriented programming, identified the “design patterns” and the best practices.  Now is the time for the developers to take advantage of this research and start writing better tests.

Well, let’s first talk about the right way to get configuration settings for your application (or a Web application).  The settings are usually stored in the file named Web.config (for Web applications and Web services) or App.config (which is named app.config in your source code project and is given a name derived from the name of your program after the compilation).

You can use the class System.Configuration.ConfigurationSettings (in .NET 2.0) or System.Configuration.ConfigurationManager (.NET 3.0 and later) to get the application settings, for example:

using System.Configuration;
...
string version = ConfigurationManager.AppSettings[ "version" ];

And you can use System.Web.Configuration.WebConfigurationManager to get your web.config settings:

using System.Web.Configuration;
...
string version = WebConfigurationManager.AppSettings[ "version" ];

Are you still with me?  Why am I writing about this trivial stuff that you can easily find on MSDN (http://msdn.microsoft.com/en-us/library/default.aspx)?  Because I’ve seen a less boring way to do the same things.  You find the file, open it, parse it (you write your own XML parser to do that), and find the element that contains the setting you are looking for.  Don’t forget to close the file.

With each new technology, developers find new ways to break the KISS (keep it simple, stupid) principle.

I resisted it for a long time.  Does the world really need another me-too collection of musings?

I have come to realize, through my use of the social networking sites LinkedIn and especially Twitter, that I do need a place to record my thoughts.  Without aiming for high traffic or fifteen minutes of fame, I could point the right people to the right content at the right time if I had the content ready.

What will this blog be about?  Software, computers, Internet, technology, and other things that are central or close to my professional activities.  I write software for a living, I’ve been doing it for many years, and I enjoy writing it.  I am motivated by feeling connected to users who use of something I wrote.  I’ve produced many different kinds of software over the years for established companies and startups on a variety of platforms using a variety of programming languages and learned various things along the way.

I also have a number of interests away from work, and I feel I need to write about them and share them as well, but they belong in a separate blog.

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!