Multithreaded Design Patterns – Freezable

The previous post talked about the Immutable pattern. This one is a slight variant.

A Freezable object can be adjusted until it is frozen. Once frozen, it behaves like an Immutable object. Such a pattern is handy for setting up objects that should not be modified once a certain point is reached, but that point cannot occur during initialization (i.e. within the constructor).

Some of the same headaches of the Immutable pattern exist with this pattern as well. I mention it because it works around one problem of the Immutable pattern.

While care needs to be taken before freezing, locking is not necessary afterward, as the data will not (or at least should not) be changing.

Multithreaded Design Patterns – Immutable

I wanted to create a series of posts on multithreaded design patterns. I will attempt to link them together so you can flip between them.

Click here for the Freezable pattern.

The Immutable Pattern

This is one of the easiest to implement. This simply prevents changes to the object once the object has been created. Methods and properties of this object are read-only, and no method calls can modify internal data.

If changes to values are required, a new object must be made.

For lightweight, uncomplicated objects, this may work well. This also works for objects that are created once and are needed to be read from many times.

The only risk here is multiple threads attempting to create a “singleton” that should be used by multiple threads. Think of multiple threads attempting to instantiate a “lazy loaded” configuration file. Both threads see it does not yet exist, both attempt to create it, and both then attempt to make it global (setting it to the same global variable).

Believe it or not, until recent changes, there was no portable way to fix this. The original problem is discussed >here<.

The answer relies on C++ 11 features. A discussion of options can be found >here<.

Comprehensible Code

The largest percentage (by a large margin) of time spent by a software developer is maintaining existing code. A significant (although smaller) percentage will be in code that the same person recently wrote.

As the code base matures, there will be sections of code that the developer does not see for a long enough period of time that details will be forgotten. How quickly will he get up-to-speed on what that code does? More importantly, what is the best way to modify that code to match the new requirements?

This is where a strong programmer pays dividends. While many still do not believe this, clean code, documentation, and tests that exercise the code pay for themselves. Often, by the time a small section of code is complete, the extra time spent doing it right has already been paid back.

Hacking code together works. Placing code where it does not belong will get the task complete. All developers know this. And when you’re only doing a small contract, you’ll be gone before anyone notices the stench floating out of the code base.

Mature developers do not do such things. Not that they refuse to do things quickly. They simply know where to put things, how to make it clean, and make tests to satisfy themselves that the code works the way they want it to. The cost: $0

Developers: Learn to do things the right way. Your desire to do so will be repaid. Strive for quality code that is comprehensible (easy to read) and predictable (easily tested).

Clients: What you see as the final product may work, but modifications may prove costly. Spend a little time up-front thinking of how to find the right person for the job.

Why aren’t more people computer programmers?

Yesterday brought to my attention an interesting article. Well written and I agree with many of the conclusions of the author.

  1. Programming is hard to do correctly. It takes effort to get something done right.
  2. Programming is hard to learn correctly. It takes the right environment, the right student, and the right teacher.
  3. Schools do not teach how to program correctly. They only teach theory. Theory is important, but paid programmers (often) do not rely on theory to complete their work.
  4. Programming is easy to do incorrectly. Plenty of people are trained and continue to work in this industry. Sweat shops continue to crank out code and projects that do not completely work and are impossible to fix.
  5. Sweat shops continue to survive because they are making money. They will re-brand themselves when their poor reputation becomes too wide-spread. NOTE: Some sweat shops are not small and not obscure. If you have been in any part of IT for more than a year, I bet you know at least one.

Here’s the link…


Getting an image size in C++

I was in need of some quick code to get the dimensions of a JPEG. I happened upon this post that inspired me to write my own. I’ll post the results on GitHub (now posted here) when I get a chance, but some fun things came out of such research.

  1. comparing a char to its value in hex requires casting the hex value to char.
  2. Bit manipulation on the low order bit may be required. I will be doing more research on the whys.

Continue reading Getting an image size in C++

Developing Multi Platform Code

My current project includes writing for two different mobile operating systems. I had the luxury of enough time to explore the ins and outs of developing a mobile application that runs on multiple platforms.

At the start, I decided to write an example application for each platform. It was something complicated enough to warrant planning efforts.

I wrote the user interface with Cordova (PhoneGap). But had I not been able to use it, the user interface would have had to be coded for each OS individually. This is a big reason for keeping your business logic separate from the UI.

The real business logic was written in Objective C for iPhone, and Java for Android. It was a true port. I figured out ways to get the same thing done on different operating systems.

Such a project demonstrated to me that much time can be spent developing the business logic. So if you are going to support multiple platforms, you will want to do it in a platform-neutral language.

Should you write it in Javascript? The answer in my case was no. Many of the things the software needed to do did not fit within the abilities of Javascript. Cordova plugins could have been built, but that was (in my mind) too big of a chunk to bite off. I am not as comfortable with Javascript, especially in the debugging and toolset areas.

Cordova plugins were still built. But rather than doing a small task natively, and the rest in Javascript, these plugins handled a large portion of the “engine” that ran the application.

Such pieces needed access to the file system, XML parsing, and file compression.

Now with the project working on both devices, I can see how the trouble of talking to C/C++ routines should be weighed with the trouble of rewriting Objective C and Java. There is not one answer. This should be decided on a per-project basis.

For this project, writing the business logic in C++ would have been best. Once the link is set between the preferred language and C++, more complicated business logic can be done in one language, and easily ported to both platforms. Ongoing maintenance will be made easier as platform agnostic changes will be done in one place.

Yes, it is a pain to get the links set up for the Android NDK. It is a bit easier for iOS. Windows phone may be on the horizon as well.

Even with C/C++, you are forced to think about platform specific and platform agnostic code. The problem does not go away completely. But even with small projects such as this one, a “toolbox” starts to form. Some of the platform-specific code gets pushed down and hidden in some libraries that could be used on other projects.

In all, it was a great learning experience, and one with assets that I will carry to future projects.

Resource: Click here for a good article to read about writing for multiple platforms.

A flexible mobile stack

My team and I have been working on a mobile application. The application is being built for Android devices, but with the aspirations of being ported to the other popular mobile platforms.

The application is mainly a CRUD-style app, with the eventuality of the data being displayed in a MS Word document.

Below is some of the details of our stack…

HTML5/CSS/JavaScript: Software purists may scoff, but an application can be written where the UI is developed in HTML5, CSS, and JavaScript. Portability of the user interface becomes a non-issue.

Cordova (PhoneGap): This has come a long way from its early days.  HTML5 does not know everything. How do you take a picture in HTML5? How do you generate a MS Word document in HTML5? You write a Cordova plug-in to interface your JavaScript. Portable? No. But I would rather port pieces of an app than an entire app.

MS Word: Why have the report come out in MS Word format? Because that way the user can edit it easily without needing a phone. Yes, there are alternatives. But do you want to support them?


Eclipse: Boy does it have its warts! But it also is much easier to handle than vi and emacs. Integration with the Android SDK and Git is nice. It works on Windows, Linux, and Apple PCs. Google is pushing their IDE, and it may be worth a look. But for now, we appreciate the fine developers of the Eclipse IDE.

Git: How can you have a distributed workforce without stepping all over each other? Get them trained on the ins and outs of Git. A nice-to-have for a single developer. A must-have when there are two or more.

JUnit / Appium: Testing your code is part of developing it. Yes it is painful. But it pays huge dividends. Spend the effort up front. Please believe me on this one.

What should my child learn for a career in software development?

A concerned parent approached me recently. Their child has pursued a path in game development. The bit of research the parent did (not sure how much) indicated to him that there were some big downsides to this. Long hours, low pay, demanding schedules and the like. How should he direct his son?

Well, I am no parent. But I was a beginner once. And I have seen plenty of beginning programmers fail.

Of the programmers that fail, I would say the greatest majority of them failed because they did not dedicate themselves to programming. Many found they didn’t even like programming. Like many other careers, people see the high demand and high pay of some developers, and jump in expecting to make big bucks after a few years of education. Not in this industry, nor any other that I can think of.

In my opinion, if you are going to fail, fail early. Consider it a learning experience, and move on.

So what advice would I give to a concerned parent? Coach and support.


What if your child wanted to pursue a career in game development? Perhaps show them the good and bad points. Show them the outlook for such a choice, and remind them that their decision now can affect their future.


Once the decision is made, encourage them as much as possible.

Are they keeping their eyes opened to different opportunities? Encourage them to explore, as well as be focused on a goal.

Are they narrowly focused on their goal? Encourage them to continue to learn all facets of their chosen path, as well as explore other opportunities.

If failure comes, show them that it is not the end of the world. It is part of the life process.

Does that not sound like positive reinforcement? It certainly sounds better to me than waiting for failure and saying “I told you so.”

As in all types of advice, YMMV.