Category Archives: Software Development

Write as Little Code as Possible

The Zune Bug

A few weeks ago I heard of this issue where the Microsoft Zune crashes and won’t startup on December 31, 2008. The reason for this? A bug in the software that handled leap years. There are lots of articles on the original issue.

When I heard of this issue, I originally thought ‘How could that happen?’. Sure I could understand not handling things correctly when it is a leap year but causing a crash?

Well, if you like me were wondering how that could happen, you can now find out for yourself. This is a post someone made of the actual code that runs on the Zune. Look at line 249 and on.

If you missed it, there is a bug (obviously) where if the number of days passed in is 366, which is the case for December 31, 2008, the loop never terminates. The code checks to see if days is greater than 365 in a while loop. It then handles the greater than 366 condition but never checks if the days is equal to 366.

Write as Little Code as Possible

The less code you write the fewer bugs you will have in it. Most languages today have built in support for common tasks. One example of this is the Java Calendar object which would allow a developer to do what the zune code does using the platform APIs. Unfortunately, High level languages are usually not an option when writing code for a small embedded device.

Tips for writing as little code as possible:

  • Start with a high level language. Preferably use an agile and dynamic language if possible (Groovy, Ruby and Python etc). This of course depends largely on the requirements of the application.
  • Where possible using the built in platform APIs to do what you need.
  • Use open source software to fill in the gaps of platform APIs. Apache and Codehaus are great sources of open source software that are commercial friendly to ship.

Getting access to SOAP Headers from an Apache CXF service implementation

For one project I was working on, I needed to get access to the SOAP headers of web service call. I am using the Apache CXF services stack. There were quite a few threads on how to get access to SOAP headers from an interceptor. In my case, I needed the contents of the header inside the implementation.

wsdl2java does have the ability to create a java service class that provides access to the headers using the -exsh option. This was not an option for me since even with this flag on, the headers were not added to the service calls. I think it was how the WSDL I had was designed. This meant that I needed to do the work of pulling out the headers myself.

The SOAP headers can be retrieved from the JAX-WS SOAPMessageContext the easiest. Getting access to this was not trivial. I added the resource annotation to get access to the WebServiceContext. Unfortunately the MessageContext this gave me was not a SOAPMessageContext and provided no way to access the SOAP headers.

After looking through the code for the SoapMessage CXF class, I found how it gets the headers out of the Message. I came up with the following to access the headers from my implementation class:


@Resource
private WebServiceContext context;

private List<Header> getHeaders() {
    MessageContext messageContext = context.getMessageContext();
    if (messageContext == null || !(messageContext instanceof WrappedMessageContext)) {
        return null;
    }
        
    Message message = ((WrappedMessageContext) messageContext).getWrappedMessage();
    List<Header> headers = CastUtils.cast((List<?>) message.get(Header.HEADER_LIST));
    return headers;
}

This provides all of the headers available. To get the specific one I needed using JAXB I added the following to my code:


List<Header> headers = getHeaders();
if (headers != null) {
    for (Header h: headers) {
        Object o = h.getObject();
                
        // Unwrap the node using JAXB
        if (o instanceof Node) {
            o = getJaxb().createUnmarshaller().unmarshal((Node) o);
        }
                
        if (o instanceof DesiredHeaderType) {
            // Do whatever is required with the header object instance
        }
    }
}

This way of accessing the headers turns out to be much simpler than writing an interceptor and trying to stuff the results of that into the request.

You Don’t Have to Use it

This past week was the Electronic Entertainment Expo (E3 for short). Most of the major video game console vendors, publishers and developers get together and show the press some of the new stuff happening this year.

This year Microsoft unveils their new and improved Dashboard. The dashboard is the main Xbox interface that is used to navigate the downloads store, games, achievements, friends and media. Initial reactions on it were mixed. Some people felt it tries to dumb things down.

New XBox 360 Dashboard

As a consequence of this new press, Microsoft’s Nelson indicates that a href=”http://xboxfocus.com/news/618-using-new-dashboard-optionable/index.html”>you don’t have to use the new interface. The entire old interface is still present and can be accessed with the press of a button.

There are two fundamental problems I have with how they are approaching this problem. The first is that this is a violation of the DRY principle. Don’t Repeat Yourself. Most of the time we talk about not repeating code sections but I like to apply this to interfaces as well. In most cases, I cannot see a reason to create two interfaces that do the exact same thing. Users can be confused when they are presented with multiple ways to do the same task. From a user’s perspective they want to be instructed how to use the feature correctly and they expect a single answer for this.

The other problem with Microsoft’s approach is that they created multiple ways to do the same thing. I have been working on projects where new interfaces or features were proposed do deal with specific problems. These features were clear improvements over the old way. Inevitably someone asks “Is it possible to keep the old way of doing things as well as the new” or “can’t we have a button to enable the old interface”. These comments should cause you to rethink how good the change is. The new feature always one of the following: better than the old feature, worse than the old feature or neither better or worse than the old feature. If it is better, adopt the better feature. If it is worse or not any better, the feature should be revisited as to why the new approach was taken. Maybe a tweak of the feature could be better. The best option is rarely to keep both ways of doing things.

It is always best to provide a single way to do a single task. This creates a clear and consistent interface for the users. It also creates less confusion for users and makes it clear what is the proper way to use the product.

Customer Issues that are not Reproducible

A few weeks ago my Honda Civic was experiencing an intermittent clunking noise. I am by no means an expert in automobiles but I am fairly certain this noise was not “normal”. I proceeded to let the dealer know about this problem when I had it in for maintenance. I explained how it seems to make this noise sometimes when accelerating or decelerating.

Were they able to fix my problem? Of course not. They were not able to reproduce the problem and consequently did not fix anything. For car problems, we accept this and as a user of the car I am supposed to ignore this until it is either reproducible all the time or something major breaks. They did assure me that they did not see anything major wrong so there was no danger in driving the car.

In the world of software development, this just does not fly. If the user has a problem, they expect it to be fixed regardless of if they can reproduce the problem or even adequately explain it. For example, a support technician brought a customer issue to me where a server product hangs sometimes for no reason. It only happens on one machine and it works fine everywhere else.

The customer wants two things. An explanation as to what is causing the problem and a fix if one is possible. This is not an unreasonable request. I essentially want the same thing for my car. But how can this problem be fixed if it is not reproducible?

There are no coincidences in software. If it happens once, it can happen again. I do not care if the problem was caused by planetary alignment and cosmic rays… the planets can align again and there are always cosmic rays.

Your job as software developer or support technician is to gather as much information as possible to narrow down the problem and to try and find the root of the problem. Find out when it is likely to happen. Try to come up with a reproducible set of steps that will cause it again. With enough work you should be able to figure out what caused the initial issue. Once you find out the cause, then you can fix it like any reproducible issue.

The Customer is Always Right

The “customer is always right” is a typical business saying. In some ways the customer is always right because they choose whether to buy your software or not. But are they always right?

I’ve been watching a lot of the television show called House M.D. It is not your typical run of the mill evening drama. It features a doctor called Gregory House who uses his un-conventional style to solve diagnostic medical cases.

“Dr. Gregory House (Hugh Laurie) – Department Head: Department of Diagnostic Medicine. The show’s protagonist, Dr. Gregory House is a maverick diagnostician with a double specialty in infectious disease and nephrology. Dr. House is seemingly lacking in bedside manner and prefers to avoid direct contact with his patients whenever possible. Due to an infarction in his right thigh, House lost a substantial portion of the muscle in his upper leg and must use a cane to assist with walking. As a result, House is also forced to deal with constant physical pain, which he manages through a dependency on the prescription pain medication Vicodin. Although his behavior can border on antisocial or misanthropic, House is viewed as a maverick physician whose unconventional thinking and excellent instincts have afforded him a great deal of respect and an unusual level of tolerance from his colleagues and the medical world.” – http://en.wikipedia.org/wiki/List_of_House_characters

One of the sayings House has is that “everyone lies”. Often he proves this in the show by showing the dark side of seemingly innocent character who tries to hide information from the doctors they feel is irrelevant. Often times that information is just what House needs to solve the case.

I would not go as far as to say that I believe everyone lies but I would say that most people lie. In particular, customers lie. Often the lies are more subtle like in the show. Customers try to protect themselves by hiding information they feel is irrelevant, such as un-related changes to the system that they may not be aware effect your software. They also feed you disinformation based on how they understand your software works.

Every computer savvy user gets frustrated when you call tech support for your DSL line and you have to go through a huge list of steps to prove the problem is exactly what you told them it was. Why do you have to go through this? Because you lie! The support process requires that they can verify you have diagnosed the problem properly. This requires that you follow a long, boring series of baby steps.

So how should we handle customers that lie? We need to realize that they lie and walk them through each step. If they say “your software crashes”, walk them through the process and verify the steps they took to cause the problem. If they say, “nothing has changed in the configuration”, verify this for yourself. Something could have change without them realizing it.

Remember to always be respectful. Often customers lie without knowing it. You need to keep them happy.

The customer is always right but the customer lies.

Software Development Philosophy and Performance

Recently I have been working a lot with some people I would call “Old School Developers”. They were brought up in the “glory days” of the pre-internet era of development. I have been tasked with teaching an old dog new tricks. In this case, I am teaching Web Services development using Apache CXF and the Spring Framework to a few C++ developers of 20+ years. These people are really smart and have a good understanding of software development. What they need is a paradigm shift.

When working with these people, I constantly hear concerns about performance. This seems to be the number 1 issue on their mind. They need to be careful that they always achieve the best performance possible no matter how much extra complexity it adds to the code. These constraints even influence the design of the code where fundamental design changes are made for the sake of performance alone.

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.” (Knuth, Donald. Structured Programming with go to Statements, ACM Journal Computing Surveys, Vol 6, No. 4, Dec. 1974. p.268.)

Programmers are notoriously bad at knowing when to optimize code. We end up focusing on the little things when we really should be concerned with reducing more broad performance issues. Is shaving off a few milliseconds a priority when you are dealing with remote web service call over the internet?

My philosophy on software development is to focus on the most important aspects first. As you might have guessed, performance does not make that list. The most important criteria for

  • Readability – Write Code that is readable. You or someone else will appreciate it when you have to come back to it at a later point in time.
  • Simplicity – Keep it simple. Only build in complexity where required and only to the degree required. You can always refactor it later.
  • Say Less – Less code is more. If you can leverage something that exists, do so.

Do not take this the wrong way. I am not trying to say here that performance is not to be considered or that it is not important. I am simply saying that it is not the most important issue. Once you have good readable and simple code, you can go back and optimize it where it needs it. If you start out with performance as a goal, you will never end up with readable and simple code. No one goes back over working and fast code with the intent to make it slower and more readable.

Commercial Software and Open Source Licensing

There are many different types of open source software licenses. These range from the Apache License which is very commercial friendly to the GPL License which is not. In a nutshell, the reason the GPL is not friendly towards commercial software is because of the requirement that anything using the GPL code must in tern by provided under the GPL license and also open source. It is understandable that a company creating commercial software would not want their source code to be open.

In many cases the commercial software just wants to use an existing open source library within the product. For this case, the Lesser GPL License (LGPL) exists. This is a lesser form of the GPL that is supposedly commercial friendly. It does not require the source code of the commercial application to be opened nor does it restrict the licensing.

Even though the LGPL was intended for this type of use, many companies are required to stay away from any LGPL libraries. This is because of the following clause in the LGPL:

You may convey a Combined Work under terms of your choice that, taken together, effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications, if you also do each of the following…

http://www.gnu.org/licenses/lgpl.html

The license clearly indicates that reverse engineering is only permitted for debugging the LGPL licensed library. The problem is really what is the definition of “reverse engineering for debugging”. Many companies do not want to put themselves in a situation where a customer could reverse engineer their code for “debugging” and also manage to get any trade secrets from that process. That type of a legal battle would be difficult and costly to fight. If someone maliciously reverse engineers your code and you bring legal action against them, you do not want to give them any resources they could use as a defense. It is far simpler to avoid the LGPL license all together then you never have to worry about this reverse engineering clause.

That clause was added to protect the integrity of the LGPL library but it has the effect of turning many commercial companyies off the LGPL totally.

New Job, New Company, Same Desk

The last few weeks have been quite busy for me. I’ve taken a new job with IWave Software, LLC. IWave is a subsidiary of Skywire Software who I previously worked for. So basically I work for a different company in a completely different field but I still have the same desk.

I was not really looking to move to a new job but this position had some definite benefits. I have a bit more job security than moving to a brand new company because I know the state of the company as a whole. Also, I still maintain all of my benefits and do not have a probation period. HR and IT are shared between IWave and Skywire so it makes the transition very easy.

IWave is a small company that has a real startup feel to it. They have been around for quite a while but are just starting a new series of products. If you are interested in learning more about IWave, you can check out the latest press release that explains some of the recent company changes.

My job position is a bit different. I have moved from a Team Leadership role to a Senior Software Engineer. It is really more of a lateral move with no more or less responsibility.

IWave is based out of the office in Frisco, Texas. I have already had a chance to get down there and see that office and meet the other people I work with. Since I am working remotely, it also gives me a bit more freedom to work from home as needed. This will help a lot when our first baby comes in the next few months.

With all of the business I have not had much of a chance to do any blogging. I’m hoping to pick it up though when things start to settle down a little bit.

Software Licensing (Part 2)

In Software Licensing (Part 1), I wrote about the issue concerning PC game piracy. This is not only an issue for the gaming market, but also for commercial software. Consider, Microsoft Windows. They took a lot of flack over their Windows Genuine Advantage system when they first rolled it out. The system took a “guilty until proven innocent” approach where it suspected all users of being pirates until they “validated” that their copy of windows was genuine. Microsoft took this system one step further with Windows Vista. After your Windows CD Key has been used twice (once to install the first time and once to allow for a reinstall), the key is locked and will not allow further validation against Windows Genuine Advantage. If you are in the habit of regularly reinstalling your operating system, you still can do this but it requires an extra step to call Microsoft and request that they reactivate your key.

At first, this validation mechanism seems similar to what Valve Software has done with Steam (discussed in part 1). The key difference here is that the software validation only works one way. Microsoft can verify that each CD Key is used once and only once for authorizing a copy of Windows Vista. What it does not do is authentication. The user has no way of proving to the Microsoft Genuine Advantage Servers that they own the CD key entered. Instead, the first person to happen to come along with that key is taken in as the rightful owner with no questions asked. If for some reason, you need to reinstall Windows Vista (more than once), Microsoft has to allow your CD Key to be used on additional computers. Since this is a common task for many users, this type of procedure is a common request of Microsoft Technical Support.

This type of request has become so common that you can even get a CD key reset without even giving your name. A friend of mine was telling me that it is possible to get Windows Vista Ultimate that is Windows Genuine Advantage validated without even owning a copy of the software.

  1. Download Windows Vista. This should be pretty easy to come by. I do not think Microsoft cares too much if you pirate the CD because you cannot use it without your copy being validated by Windows Genuine Advantage.
  2. Download a CD Key generator for Vista OR borrow a CD Key from a friend
  3. Call Microsoft support and indicate that you need to reinstall your computer but your CD key did not work. Microsoft will unlock this key to allow it to be used on more computers.

For all of the work Microsoft put into their new Anti-piracy system, a pirate can now easily get a “genuine” copy of their product simply by calling their tech support. I doubt this was what Microsoft had in mind when they implemented this new security scheme.

Licensing in Software Development

Make licensing easy. Do not treat your customers like criminals. Instead make the licensing process simple. For a long time PC games have required the physical CD to be in the drive in order to play the game even if the entire game contents are on the hard drive. This sort of a thing is more of an annoyance to paying customers rather than a deterrent against piracy. A pirate will crack the software so that no CD is required. Requiring the CD restricts the user more and actually makes the pirated way better. I knew a friend who usually purchased games legally and used cracks to allow him to play the games without the CD in the drive.

Long product keys are not the most friendly form of licensing. I work with business software and prefer using license files as opposed to a simple key. I also believe that these license files should be in plain text with a hash signature. The benefit to this is that you can store lots of information about the customer inside the file. The hash protects the file from tampering and the file can be read by a user.

For example, consider the following license file format:

<?xml version="1.0" encoding="UTF-8"?>
<license>
   <product>Product XYZ</product>
   <version>1.0</version>
   <customer-name>Jane Smith</customer-name>
   <key>647608973E40E3D2A31A886DC1AE3092</key>
</license>

A simple utility can be created to create this license XML file and generate the “key”. The key can be simply the content of the license file with a little salt thrown in. The salt can be secret predetermined random string that is added to the content before hashing. Unless the secret value of the salt is known, the hash can not be recreated with new values for the content. This protects the license from tampering.

To use this license file, the key can be checked to verify that the license has not been tampered with. After that the XML can be read with a standard XML parsing library to extract the license data. The software can store whatever information required here with no restrictions on length or type of content.

Piracy Protection

Licenses do not guarantee that the software will not be pirated. They provide a deterrent so that it is not as easy to pirate the software. So what should a software developer do to protect your software from piracy?

The simplest and probably best solution is to provide a service that accompanies your software. In part 1, Valve Software only allows users access to their online multi-player if they have an authorized account. If you are in a situation where you can provide services along with your software, it may provide an incentive for an otherwise pirate to purchase your software.

When it comes right down to it, if your users want to pirate your software, they will find a way. You can take whatever measures you want to make that harder for them, but they will inevitably find a way around them. Look at things like DVD encryption. Broken. HD-DVD and Blue-ray were said to be impossible to break within the lifespan of the media. Also broken. Providing security mechanisms is a good deterrent to casual pirates but even the best security can be eventually countered. The key is to not make the security too strict that it creates a hassle for paying customers.

Software Licensing (Part 1)

I read an interesting article today at gamepro about PC game piracy. The article quoted from Call of Duty 4’s game blog:

“On another PC related note, we pulled some disturbing numbers this past week about the amount of PC players currently playing multi-player (which was fantastic). What wasn’t fantastic was the percentage of those numbers who were playing on stolen copies of the game on stolen / cracked CD keys of pirated copies (and that was only people playing online).” – Robert Bowling

It was not the fact that PC game piracy was rampant that surprised me but the fact that the pirates with stolen copies of the game are permitted to play online. To me, this seems utterly ridiculous. To understand why this is ridiculous, it is necessary to understand how online gaming works. A typical multi-player PC game allows users to do two basic things, host games for other people to join and join a game hosted by someone else. This service is sort of like a directory listing for games that are being played. Since the listing is controlled by the software publisher’s service and not the game itself, it can validate users and only allow users who purchased the game to use the service.

I believe that no matter how difficult we make the software protection process, pirates will always find a way to break the simple protections put in place over software. When you ship a piece of software, it contains the complete working product. Even if we had 1024 bit encryption keys with 256 character long CD keys for users to enter, when it comes right down to things, the software product knows how to validate that key. All a hacker needs to do is figure out how the program does that validation.

The only way to protect this is by having the key validation done by something other than the software product given to the user. This way they could not modify the product to get around the problem. Games like the Orange Box from Valve Software do this very well. When you purchase the game (either physically or electronically), the game is linked to an account on the Steam service that Valve provides. This service authenticates users and only allows them to play the game if logged into the service. Essentially it provides both the authentication of the user and the game listing services for users.

When you move the validation to a third party system, a pirate would be required to simulate the entire third party system. If a user had a pirated copy of Orange box and a service that “emulated” the steam service, they would still not have access to the game listings that valve provides through the legitimate steam service.

Essentially what this gives is an incentive to users to purchase the game instead of pirating it. Pirating games is simply too easy today. A 12 year old kid can more easily download a cracked copy of a game than to go through the process of acquiring 60$ from their parents and a round trip ticket to the mall. Now, if suddenly you told that 12 year old kid that they will not be able to play the game online with the pirated version, it may provide them with an incentive to go with the more difficult process.

In part 2, I look into the piracy issue with Microsoft Windows.