The C++ Shoot-yourself-in-the-Foot of the Week

I think we can all agree that C++, compared to other languages, provides quite a number of possibilities to screw up. Everybody working with the language at some point probably had problems with e.g. its exception system, operator overloading or automatic type conversions – to name just a few of the darker corners.

There are also many mitigation strategies which all come down to ban certain aspects of the language and/or define strict code conventions. If you follow Google’s style guide, for example, you cannot use exceptions and you are restricted to a very small set of boost libs.

But developers – being humans – often find creative and surprising ways to thwart every good intentions. In an external project the following conventions are in place:

  • Use const wherever you possibly can
  • Use boost::shared_ptr wherever it makes sense.
  • Define typedefs to shared_ptrs  in order to make code more readable.
  • typedefs to shared_ptrs are to be defined like this:
typedef boost::shared_ptr<MySuperDuperClass> MySuperDuperClassPtr;
  • typedefs to shared const pointers are to be defined like this:
typedef boost::shared_ptr<const MySuperDuperClass> MySuperDuperClassCPtr;

As you can see, postfixes Ptr and CPtr are the markers for normal shared_ptrs and constant shared_ptrs.

Last week, a compile error about some const to non-const conversion made me nearly pull my hair out. The types of variables that were involved all had the CPtr postfix but still the code didn’t compile. After a little digging I found that one of the typedefs involved was like this:

typedef boost::shared_ptr<  MySuperDuperClass> MySuperDuperClassCPtr;

Somebody just deleted the const modifier in front of MySuperDuperClass but left the name with the CPtr untouched. And because non-const to const conversions are allowed this was not detected for a couple of weeks. Nice going!

Any suggestions for a decent style checker for c++? Thanks in advance 😉

Looking left and right will improve you as a developer

After initial encounters with computers and programming I pretty much settled with Java as my preferred Language and especially platform. Occasional adventures to C/C++ or other languages and tools do happen but not on a day to day basis. We are mostly a Java shop so this seems natural. However, I strongly suggest looking left and right and trying new stuff, be it a programming language, an operating system, an IDE or a programming framework. Similarily to travelling around in the real world™ it will widen your views on your daily work and give you new ideas on how to improve it. You will try to adapt new good stuff from elsewhere and on the other hand appreciate nice aspects of your current environment more.

Let me give some examples to support my point and motivate adventures outside your home turf. I have been playing around with Scala and therefore functional programming in the past months. One major benefit of these experiments was my new appreciation for immutable types and side effect free code. You can carry them over to many programming environments including Java often making your code easier to test and less error prone. Object-oriented programming (OOP) relies heavily on objects with state and side effects but there are many places where immutability reduces tracking effort of objects and their state. A nice example in Java is the Joda Time library with provides immutable DateTime-classes in contrast to java.util.Date et al. Null-Handling in Scala using the Option-Type seems so interesting that some people try to carry it over to Java as an alternative to Null-Objects or null checks. The rich collection classes and implicit conversions in Scala may encourage you write own utility classes for Java collections, nice wrappers or use alternative collection frameworks to make your life easier. In general, I find wrapping a nice, standard OO-technique often underused outside of frameworks.

You do not always have to stray that far. Some frameworks like Fest and EasyMock show nice usages of fluent interfaces. Why not use this technique in own code? I found them especially useful for implementing builders for complex or highly configurable objects. Fluent interfaces can make your code look a lot like natural language resulting in expressive and highly readably code.

Using Mac OS X with Spotlight™ and TimeMachine™ may make you look for similiar features on your Linux Box (e.g. gDeskbar and BackInTime) or Windows (depending on version available through third party software or built-in). Using the multiple deskops of Linux (or another OS with an X11-Window system) may motivate you to try them in your other working environments (they suck on OS X, though).

Trying different IDEs may increase your effectiveness depending on the language and frameworks used. Grails support may be better in IntelliJ whereas you may like Eclipse more for plain J2SE projects. Sometimes you will find some cool feature in one IDE you were missing before. I encourage you to go back to your environment and look for the same or similar features. Often you will find them in many advanced IDEs.

Without seeing what is possible you may never miss it. But beware thinking everything new is automatically better. The grass is always greener on the other side. Try to reflect on the things you learn and encounter. Take the good parts to improve existing stuff whenever sensible. But also do not fear to move on if it is time.

For me and my colleagues this wandering around in this rich software development world has proven very valuable to continually improve our style and increase our productivity. These adventures in foreign waters coupled with reading books, dev brunches and attending talks on and offline keeps our skills fresh and improving. Sometimes it may even lead to own ideas, APIs and tools.

There should be a stakeholder for simplicity

You have stakeholders for your product idea, you have stakeholders for your clients and their ideas, you have stakeholders for clean code, for quality, for object oriented programming, … I think we need also stakeholders for simplicity.

Usually in every project ideas are abundant. Your client has many ideas what features he wants. You and your coworkers have a rich background in the problem domain and the technologies you use so that solutions are not sparse. But often this experience and confidence leads to abandoning an important trait: simplicity.
Most of the time you are focused on getting good solutions for the problems that arise. From past experiences with clients who could not exactly explain what they really need (which is different from what they want most of the time) you tend to include a little extra flexibility in your system. Maybe you need this and that variation some time in the future but at this very moment it’s a guess at best. And often this guess costs you. You could argue that you are investing into your project. But how many times did this investment really pay off? And how many times did you have a hard time just because you did not want to make restrictions? At first it seems like a little work. But with the next feature you have to continue supporting your little ‘extra’. Over time it infuses your system like leaven does it with bread. In the end it is more work to make it simple than to keep it simple.
So with every project you approach there should be a stakeholder for simplicity. Someone who focusses on simple solutions. Sometimes you have to cut a bit away from the feature or you have to view the problem from a different angle. Some other time you have to dig deeper into the problem domain or you need real data from your users (which is always better than what you can make up in your mind). Finding simple solutions is work but it is much more work to support your over-engineered solutions.

Review of the Sensor+Test 2010 Measurement Fair

A review of our visit to the Sensor+Test 2010 Measurement Fair in Nuremburg, Germany. The most suprising discovery was a Java Virtual Machine running on an eight bit microprocessor, offering threading, garbage collection and exception handling.

Two weeks ago, we visited the german Sensor+Test 2010 Measurement Fair in Nuremburg. It’s a central trade fair for the sensor technology sector in Germany and Europe. We as software developers weren’t directly interested in the sensor hardware that was presented to the qualified visitors. We didn’t take part in the technical conference that was held in parallel. Why we were there and what we’ve found is the topic of this blog post.

General impressions of the trade fair

The sensor industry has a strong orientation towards classical technology and engineering. It’s not “new economy”, as you can tell from the exhibition booths and their setup. Most booths look like they have been used for several years with variations only in details. Most booth personal are engineers or managers of the companies presenting their latest products. It’s unlikely to talk to a sales person, several booths even had a paper sign saying “salesman needed” attached nearby. The industry knows very well what it is selling and capable to promise and achieve. We didn’t spot a single “booth bunny” on the whole trade fair, which is in great contrast to some high-strung events of other industries. Instead, you could walk into a booth and talk to the engineers without having to pass several layers of sales representatives.

Impressions of the exhibited technology

Miniaturization is a key trend for the hardware part of the sensors. Some display cabinets would have gone through as empty if there wasn’t a descriptive plate pointing to the dust particles that resemble whole sensor arrays. Energy efficiency and the new trend of energy harvesting, utilizing even minor differences in temperature or other physical quantities to power a device are this year’s buzzwords, too.

Why we were there

Our goal was to find out about the software side of the sensors. We wanted to grasp the software technologies used to drive the hardware and to process the data. We wanted to know what to expect when “technical software products” are exhibited. And we wanted to find out about the depth of knowledge about software development in these companies.

What we found out

  • Technical software products aren’t pretty. We’ve known this before, but had some hopes for stylish new user interfaces with Apple-like multitouch screen gesture controls and graphical effects. Instead, we’ve seen the same old 16-color line charts oscillating on a screen that contains all the buttons and handles that the program can offer. The graphical level was comparable to plain Windows 95 dialogs. Even when new-era Office ribbons were used, the main content stayed the same, posing an even bigger contrast. One thing that bugs me about technical software is the common existence of a big red “exit/quit/leave/stop” button on the main screen. I wonder where that might come from (see picture for hints).

  • The software platform in use is legacy Microsoft products. That’s not a problem for us, we are polyglot programmers. But only a few booths had other operating systems booted or an Apple in use. We asked one of them for visitor feedback on the Apples, they got told that their choice of hardware was “exotic, but likeable”. We didn’t find any Windows 7 in use on the whole trade fair.
  • Most sensor companies know a lot about software development tools. Anticipating the level of detail the engineers know about specific programming languages or tools from their rather monocultural choice for their products fails. Topics like Java, Eclipse, Smartphone programming, Android, etc. aren’t news to them. For example, in the recent professional journals of their sector, they discuss the different languages and platforms for smartphone software development.
  • Most sensor companies are desperate for embedded device programmers. We didn’t find a booth that wasn’t interested in finding conventional embedded device programmers (mostly a domain for C language experts with a good grasp of hardware design). So if you happen to be one, scan the exhibitor list and make some phone calls.

What we discovered

Somewhere in a corner of the second hall, in one of the last booths before the press center, there was a stand with big posters stating “Java on an 8-bit microcontroller” and “Exceptions, Threads, Garbage Collection within 60 kByte”. The whole buzzwords seemed a bit out of place, given that the booths around were announcing “better energy efficiency” or “greater effective range”. But it was a pleasant surprise for us. The german company calls itself Virtenio and is a new-founded spin-off of the Technische Universität Berlin. They achieved to develop a Java Virtual Machine that fits the teeniest ARM processor while still offering some performance and a good level of comfort for the programmers. It’s a very promising combination of embedded device and platform for “normal” software developers.

Summary of our visit

Our visit of the Sensor+Test 2010 Measurement Fair did pay off in many directions. We good our questions answered, discovered some new technologies and got very much inspiration about what’s going on in the embedded device sector. We are looking forward to be there again next year.

Blog harvest, May 2010

Some noteworthy blog articles, harvested for May 2010. You’ll hear a lot about Java, a bit about Clojure, a fair share about Pair Programming and some thoughts about the advantage of employee exchange programs.

You can tell from the frequency of recent blog harvests that we are slightly overloaded with work at the moment. This is a rather preferred state to be in as a small contract development company, but everything not ultimately necessary is reduced during those phases. We consider blog reading as indispensable, but reporting the best of articles (our blog harvest) isn’t. So right now, we have a very long list of articles in our harvest barn. Here are some articles of the last two months:

  • Does Groovy Know You Are Seeing Clojure? – A real world story of learning Clojure, the Functional Programming language on top of the JVM. I can wholeheartly agree with the sentence “In the intervening 30 years since starting out on a TRS-80 Model 1 nothing has been more difficult in terms of solving even the most trivial of problems than learning Clojure.”, but in my case, it has been a little more than 15 years of real experience. After a year trying to “get” Clojure, I deferred it for more productive work.
  • Don’t return null; use a tail call – A blog entry about the billion-dollar-mistake (null pointers) and API design. It got inspired by Steve Freeman’s book “Growing Object-Oriented Software” (see next section for more content by Steve Freeman). The idea of “tail calls” or callbacks isn’t new or revolutionary, but widely underused. Personally, I found the idea of returning empty Iterables (as an abstract commonplace of Collections) useful in some scenarios.
  • Practical Styles of Pair Programming – First hand experiences of a pair programming enthusiast (Iwein Fuld). His scenarios seem familiar and the advices given reasonable. Reading the article sharpened my awareness about pair programming. There is only one complaint about the article from my side: Using headphones while programming doesn’t turn you into a zombie, it just eliminates the outer world for some time. That’s Alone Time, and it’s there for a reason, too.
  • Java1.6u18 and double array creation – A little story about flawed unit tests, recent java improvements and the value of nightly builds. Thanks for sharing this with the world, David Shay.
  • Do You Like Pain? – Jared Richardson shares his story and advice about getting used to the “pain” in any environment. I like the idea of the “prisoner swap” to identify pain points a lot. But from my own experience I can tell that the messenger might be muted by labelling him “not fully aware”.
  • Exploring Google Guava – Google Guava is the new Apache Commons. There are some neat features, though. Definitely worth the 20-minutes-read this article by Dan Lewis provides.
  • Java Post Mortem with Gilad Bracha – A post mortem should only be done on “dead” people/projects. So the title alone is a harsh statement. But the summary of the talk contains some valid points and a lot of opinions to think about. I particularly like the term “cottage industry” for DI framework vendors.

Next comes the video section of this blog harvest. I’ve found the time invested in these talks worthwhile:

  • Threading is not a model (35min) – Joe Gregorio presents the lack of advanced multiprocessing tools in most programming languages. His talk covers a lot more than just that and gives some appetizers on Python. The solicited lack of MP support was my reason to learn Clojure (see first entry in the list above).
  • Sustainable Test-Driven Development (55min) – Steve Freeman gives a whole bunch of advanced tips to write unit tests. The talk is given from the TDD/BDD point of view, but mostly applies to unit tests in general. You should be familiar with JUnit to fully understand this talk.

And at last, there is a tool I want to present you (this kind of resembles the fun section, too):

  • Dollar – An experimental java API that shows how much you can bend the java syntax to suit your personal taste. Through inspiration by this project I’ve come to some unique ways to make my code more expressive – without using funny signs. Thanks to Davide Angelocola for his unique approach.

Open Source Love Day May 2010

Our Open Source Love Day for May 2010 brought love for Netty, Launch4j and RXTX. Everything went smooth again this time.

Last friday, we held our Open Source Love Day for May 2010. After the excessive yak shaving of last month’s OSLD, this one was more productive. We got one feature right nearly instantly and several others throughout the day. To keep us from feeling depressed, we allocated dedicated “research time” to get to know a project before starting to develop on it. So one point on our current list of accomplishments is only research work that should be counted as “thought investment” for further improvements.

The Open Source Love Day

We introduced a monthly Open Source Love Day (OSLD) to show our appreciation to the Open Source software ecosystem and to donate back. We heavily rely on Open Source software for our projects. We would be honored if you find our contributions useful. Check out our first OSLD blog posting for details on the event itself.

On this OSLD, we accomplished the following tasks:

  • Netty is a java framework to perform network communication, transparently using different transport mechanisms. We use it in a customer project environment and it worked mostly well. But we noticed some issues that might have to do with the framework, so we decided to put it under development. But before hopping in right away, we invested some hours to really anatomize it. Our achievement isn’t noticeable yet, but might be in the future.
  • Launch4j is a java application launcher for Windows, handling all the stuff a startup script (the infamous start.bat) would do, too. One thing that’s easy to perform in a batch script is to restart the application if it went down with an error. We wanted this feature in Launch4j and we succeeded. Before releasing the changes to the project, we need some rethinking of our approach, as it is very special to our case, but if you are interested, we send you the patch on request.
  • RXTX is a project to perform serial (RS232) communication. Over the course of the last OSLDs, we worked on an issue that appears in combination with serial converters. See the OSLD posting for march 2010 for details. This issue seems to be completely fixed now. We will run some longterm stability tests with it and then release a patch to the issue tracker of RXTX, issue #144.
  • Our internal tool for business administration was greatly improved this time. The tool isn’t open sourced yet, but we are not afraid to publish it in the future. The new features will directly decrease our administrative overhead and give us more time to perform our main duty – developing software.

A sidenote regarding the yaks (see last month’s OSLD posting to understand this one)

Our monthly “Homepage Comittee” meeting went smooth this time. The setup pain of last month is now paying out and we got our homepage updated. It seems the yaks haven’t grown beards again yet.

What were our lessons learnt today?

  • Pure C code tends to produce endless code blocks. Simple refactorings like extract method/function take a long time and aren’t supported by the IDE. The sentence “there is no boolean!” left some of us impressed, too.
  • The C/C++ Eclipse workbench (in fact, a bunch of plugins for Eclipse) was a joke instead of a help. It didn’t exactly prevent us from doing our work, but that’s all it did. Launch4j came along with project files for the Bloodshed Dev-C++ IDE, which – besides its bloody name – seems to be up to its tasks. We decided to use Dev-C++ over Eclipse for development on Launch4j.
  • Hpricot is a very versatile HTML parser/manipulator. It is just pure joy to work with. (Ok, we knew that one before)

After the fruitless OSLD of april, this one was a great relief for us. The new restart feature for Launch4j worked out instantly and will solve many of our current immediate problems (and some of yours, hopefully). The solution for RXTX got us out of trouble, too. All in all, this was a successful OSLD.

Follow-up to our Dev Brunch May 2010

A follow-up to our May 2010 Dev Brunch, summarizing the talks and providing bonus material.

Last sunday, we held our Dev Brunch for May 2010. It was a small group of developers brunching together this time. One reason was a communication failure on my part, as a crucial email announcing a change in the appointment didn’t reach everyone interested in participating. Sorry for this one again! The other reason was more of a pleasure: Two of our regular brunch attendees are turning into parents. But a core group brunched and talked in the office roof garden, discussing the topics listed below.

The Dev Brunch

If you want to know more about the meaning of the term “Dev Brunch” or how we implement it, have a look at the follow-up posting of the brunch in October 2009. We continue to allow presence over topics. Our topics for the brunch were:

  • Options in Scala – If you are used to traditional programming languages like Java, you might be surprised that you can’t nullify a reference in Scala. There is no concept of “null” in Scala, therefore avoiding the so-called billion dollar mistake (you might want to listen to the guy who invented the mistake, too). If you want to use “uncertain” references, you should look into the Option type of Scala, which was the main topic of this talk. With some code examples, this was a decent introduction into the concept.
  • Summary of the Sensor+Test trade fair – This talk was a short report of the recently visited german Sensor+Test measurement fair in Nuremburg. Details may follow on this blog, but the overall summary is that the measurement industry in Germany and neighbours is mostly self-confident and down-to-earth.
  • The Modbus protocol – This talk was a short introduction to the ancient (but still useful) Modbus protocol and the possibilities to access it in Java. There are at least two projects that provide full coverage of the protocol: jamod and modbus4j. The protocol itself is rather low-level, but sufficient for simple control and data query tasks on an embedded device. The possibility to be mostly agnostic over the physical transport layer is a strength of the Modbus protocol and its implementations.
  • Usage patterns for mocks – Most of us had to confess: we are mockists. But there are many different flavors of using mocks in tests. Inspired by the book “Growing Object-Oriented Software, Guided by Tests”, this talk was an open discussion round about personal mock usage preferences.

As usual, the topics ranged from first-hand experiences and impressions to literature reviews and research. For additional information provided by the talk authors, check out the comment section (or leave a comment to request further content). Comments and resources might be in german language.

Retrospection of the brunch

The usual brunch setup is nearly perfect. What was lacking this time was the coordination of the appointment. To further improve on that point, we introduced a new mailing list, containing everone that is currently interested in participating the brunch.

Improved Version of CMake Builder for Hudson

Introducing version 1.5 of cmake builder plugin for Hudson.

Today I just want to give a small round-up of the improvements made on the cmake builder plugin since my last blog post. Back then, version 1.2 was released to support master/slave configurations. As of yesterday, we are at version 1.5 which contains the following improvements/bug-fixes:

  • Bug: The drop-down box for selecting the build type didn’t remember its value. This was fixed with a patch by Atte Timonen.
  • Improvement: Also included in Atte’s patch was the propagation of environment variables to the cmake command which now allows to do parameterized builds. A big thank’s to Atte!
  • Improvement: The install command gets only executed when install directory and install command is given. Before, the build was either broken or $WORKSPACE was used automatically as install directory. Thanks to Dat Chu for his feedback.
  • Improvement: The one-line ‘Other CMake Arguments’ field can get full pretty quickly, so it was changed to a multi-line text-area.

Thank’s again for the feedback, and have fun with the new version!

Step-by-step tutorials and manuals are priceless

Writing documentation in and outside of code annoys most developers. I am no different but after several years in the software development business I have come to value one type of documentation a lot: step-by-step tutorials and manuals. Surprisingly, they are often missing. I want to depict some common use cases where such documents have proven valueable many times:

when learning new tools and frameworks

Most people I know learn best by example. A tutorial with step-by-step explanation of how to setup the tool and then some good examples brings you up to speed quickly. The Lift framework has such a thing and gets you a webapp running in minutes. But when you dive deeper you may find much documentation and how-tos are missing. Books may help but most of the time it is faster and easier to look for examples on the web and in project wikis.

Also beware, that bad examples may cause a lot of frustration (typos are poison for newbies) and teach bad style or obsolete techniques. Keep the tutorials up-to-date (I know, thats one problem of documentation….) and as accurate as possible and many people will have a better time working with the tools and frameworks.

The same is true for developers in your team: Many will look for examples in the existing code base and learn from them be they good or bad. So keep the code clean and full of good examples. Let your seniors spread them in the teams. Do not forget to provide good examples and best practices in your wiki or other documentation system.

when performing manual tasks

We often have to manage and deploy production systems for our customers. Even though many tasks are automated by scripts and other tools you sometimes need to perform manual tasks. Especially in an stress situation at customer site or when otherwise dealing with production systems it is extremely helpful to have a simple and precise guide for the task at hand. There are enough unknowns and problems that may need brain power so the basic tasks and procedures should be well documented. That way you have one less thing to worry about and are ready to face potential upcoming problems. A good guide gives you much needed confidence.

when trying to work on an open source project

We regularily (see our OSLDs) dive into some open source project to improve it. Nothing is more frustrating than spending more than half a day with setting up the development environment. Overboarding dependencies, works-on-my-machine-style build scripts and missing documentation and tutorials prevent a productive experience. That hurts the themselves projects by driving away potential contributors. We had several such experiences but also many positive ones like Hudson plugin development or EGit where you can get up to work in minutes and perform your first monkey see – monkey do experiments.

Conclusion

Much documentation generated or written nowadays is not worth 2 cents. API-Docs which list the classes, methods and fields and no additional info and descriptions provide no use and just waste the time of people trying to find information there. Highlevel blabla or theoretical dissertations are all nice but do not help much getting the job done (at least not in the beginning). But small guides and tutorials written to the point really do make a difference regardless if they are written for inhouse work and development or for openly available projects. Choose the kind of documentation you write wisely.

Responsibility reduces waste

Most of the waste comes from being irresponsible. Over time waste becomes even harder to remove. So be responsible now.

Recently we participated in a local effort (site in German) to help making our environment cleaner by removing waste which was left by other people. When you take a look at your environment you may come to the conclusion that many people are irresponsible. Waste on the streets and in the parks, prohibition signs everywhere which name things and actions you wouldn’t even think of and when did people forget to flush the toilet?. And it doesn’t stop in the material world, you even find waste in your code. Allowing waste and not removing or preventing it leads to two effects:

  • even more waste (according to the broken window theory)
  • over time the waste becomes more and more intertwined with the environment

Imagine a plastic cup in a forest: When first thrown there it is clearly distinguishable from the mud, the leaves and its surroundings. Easy to see and easy to remove. But over time it is trampled over, crushed, hidden under leaves, wash over with mud, … in the end you may not even spot it when you look at the place where it was left.
The same happens to your code: You start with a small clearly defined part of bad smelly code and leave it alone. Now the first additional features come in, you add code, there and elsewhere. The surroundings change. You refactor. You move code. And in the end the once good known waste is littered all over your code and hard to remove.
So be responsible now! And don’t wait until the waste is hard or impossible to remove. Collective ownership (of code or of your environment) does not mean nobody is repsonsible, it means you are responsible.