Rob Williams: More Reasons Why Software is Hard

27. April, 2012

Interesting read: More Reasons Why Software is Hard


When Eclipse Won’t Start

13. April, 2012

There can be a couple of reasons why Eclipse refuses to start: Corrupted workspace, broken plugins or conflicting plugins. This blog post is about the last category.

How do you know that you’re affected? Start Eclipse with the command line option -debug. If there is a huge gap between “Time to load bundles” and “Starting application”, you’re on.

Start Eclipse in a debugger and set a breakpoint in org.eclipse.osgi.internal.module.ResolverImpl.findBestCombination(ResolverBundle[], ResolverConstraint[][], int[], List<ResolverConstraint>).

The interesting information is in the variable bestConflictBundles. This is basically a list of bundles that cause some kind of trouble. Usually, this is a bundle which has the singleton flag set but of which are two versions in the plugins folder (or in the plug-in list, if you started Eclipse from another instance of itself).

If you started Eclipse from itself (using a launch configuration), the solution is to open the “Debug Configurations…” editor, select the “Plug-ins” tab:

This tab has several interesting options: You can type (part of) a plug-in ID into the filter field to narrow down the huge list. If the list isn’t active, select “Launch with: plug-ins selected below only” above.

That way, if you want to disable all of BIRT, type “birt” and then click “Deselect all” to the right.

Next stop is the “Validate Plug-ins” button in the bottom left. This opens a dialog with all the problems the current selection has. This dialog isn’t modal! That means you can keep it open while you (de-)select plugins from the list. If your screen is big enough, you can move it so you can see the list and the “Validate” button. That way, you never need to close the dialog.

Otherwise, Alt+V is your friend.

In my example, the org.eclipse.jpt.jpa.db plug-ins cause trouble. As you can see, I pulled them out with a short text in the filter. Now, I can get rid of them with a single click on “Deselect all”. Validate … okay, things for worse.

But I don’t need anything from JPT for my tests, so I get rid of the whole lot. Validate … “No problems were detected.”

Sweet.


Embarrassing Security Failure at PayPal

26. March, 2012

PayPal is one of the places who really care about security.

But even they were vulnerable to XSS type of attacks using the search feature (see this article for details).

At the moment, I’m not sure if that’s more embarrassing or frightening. Sure, it’s shameful but when even those guys don’t get it right … who can?


Making Daily Stand Up Meetings More Effective

16. March, 2012

Are you doing daily stand up meetings? Feeling like you’re wasting your time?

It’s Not Just Standing Up: Patterns for Daily Standup Meetings might help.

From his post:

The daily stand-up meeting (also known as a “daily scrum”, a “daily huddle”, “morning roll-call”, etc.) is simple to describe:

The whole team meets every day for a quick status update. We stand up to keep the meeting short.

That’s it.

But this short definition does not really tell you the subtle details that distinguish an effective stand-up from a waste of time.

More…


Commenting Code

1. March, 2012

A lot of people way “you must comment your code.”

Kevlin Henney wrote an excellent piece on this topic in 97 Things Every Programmer Should KnowComment Only What the Code Cannot Say

It really boils down to the last sentence: “Comment what the code cannot say, not simply what it does not say.”

There are various reasons why people demand comments:

  1. They are not fluent in the programming language or don’t know enough to read the code. There is nothing wrong with the code – the readers simply don’t know enough to understand it.
  2. The code is broken in some way and you need the comment to make sure people don’t break it even more.
  3. The comment explains something that no one will see from the code.

Only #3 is a valid reason for comments. #1 is just adding noise for people who shouldn’t touch the code anyway. #2 means you should refactor the code to make its intent clear – adding comments will only make things worse.

Related articles:


How I Came to Hate Orbit

29. February, 2012

Orbit is an Eclipse project which contains IP clean OSS code to be used in Eclipse projects.

Why is that important? Well, IP clean means that big companies who consume Eclipse code, can use it safely (their lawyers have to check the EPL once and after that, their developers can use any code they can find on eclipse.org).

Now, Eclipse writes a lot of source code but not everything. commons-io, for example, contains a lot of code which would be really cool to have for Eclipse projects.

Orbit was created to have just that: Copies of OSS code from all kinds of places relicensed under the EPL. Sweet.

Enter stage: maven.eclipse.org

The idea behind maven.eclipse.org is to provide projects outside of the Eclipse foundation a place where they can find Eclipse’s OSGi bundles as Maven artifacts (which are easier to consume when you build your projects with Maven). Sweet 2.

To make the Eclipse bundles available on maven.eclipse.org, I need to convert them. Part of that process is to assign each Eclipse bundle (which has bundle ID and a version) a Maven coordinate (which consists of group ID, artifact ID and version). That’s not always simple but I’ve found a rule that works pretty well.

If it wasn’t for Orbit.

Orbit contains bundles which you can also find on Maven central. One example is commons-io.

And Orbit didn’t simply copy the JAR from Maven Central – they changed it. In this case, the changes are purely for legal reasons (EPL license, moved a couple of files around). Not a big problem here. I could map the two to the same coordinate – except that you would sometimes build software which contains code licensed by Apache and sometimes code which is licensed by EPL. Worse, some other code might be under the viral GPL on Maven Central – linking that could turn your project into open source! Not a problem for most developers but it could be a problem for your legal department and guess which head is going to roll?

But there is more.

Let’s have a look at … org.apache.batik.pdf. This is a fragment of the Batik’s rasterizer JAR from Maven Central. In this case, we have several issues:

  • Orbit has split a single artifact from Maven Central into several Orbit bundles. Which bundle should get the same coordinate as the original Maven Artifact?
  • The Orbit bundle also contains code from commons-io and commons-logging. So it pollutes your classpath with classes that you don’t expect. Worse, someone (not the Eclipse guys) removed “unnecessary” methods from some classes copied from commons-io. So if the compiler sees this JAR on the classpath, you will get errors for many methods in the class IOUtils. Bad.
  • Some Orbit bundles have bugs fixed but the version hasn’t been changed – only the qualifier changed which works if you use OSGi to build your classpath but Maven doesn’t. A couple of bundles from org.apache.batik are among them (bug 329376).

While it might make sense from Orbit’s point of view to do this, it makes my life a bit complicated.


Open Source As Good As Proprietary Software

28. February, 2012

The Coverity Scan 2011 Open Source Integrity Report (registration necessary) says: “Open source quality is on par with proprietary code quality, particularly in cases where codebases are of similar size.”

Which isn’t that surprising considering that it’s the same people who write both.

But there are a couple of hard number in the report which are interesting:

Linux 2.6 has about 0.62 defects per 1000 lines of code (KLOC) which Coverity says “is roughly identical to that of its proprietary codebase counterparts.” They can’t tell names but I guess the counterparts are Windows and Mac OS X. They have 0.64 defects per KLOC.

The industry average is 1.0 defects per KLOC which matches well with my (more anecdotal) knowledge that the best software developers make about 3-4 mistakes per KLOC of which 75% are found during development.


EFF Tries To Sanitize Patent Law

23. February, 2012

The EFF has started a new campaign to clean the patent system.

I’ve blogged about the many problems of the parent system when it comes to software. If you care as well, at least spread the word. If you want to do more, check out the EFF site or maybe  help with the Patent Busting Project.


Code Is Design

22. February, 2012

If you look for reasons why software development is often such a mess, here is an interesting, new angle: Code Is Design by Ryan Brush.


AgileUnit – The Future Of Testing?

15. February, 2012

AgileUnit is a new testing framework which puts the testing code and all your assumptions into the business logic.

The main advantage is that you can make sure that your assumptions are met as the customer uses your product. To drive this home: The tests are running while the code is in production and while real customers use it.

At first glance, this sound reasonable but there are a few catches:

  1. Test code doesn’t stop early when you disable it. This means that the AgileUnit code makes your product slower at runtime. Each added test will make the situation worse. I have a feeling that each test will read the property file from disk – every time the method under test is run.
  2. User input isn’t tested, only the predefined test cases are run.
  3. Only primitive types plus some numeric types (Date, BigDecimal) can be tested. If your methods work with lists, maps or other complex data structures, then AgileUnit is not for you.
  4. Test failures will show you the result of a computation but not the arguments. In the “sum” example, you get an error that the “input” (which is actually the result of the sum() method) is less than 0 but the inputs of the sum() method are not listed so there is no way to know why it failed (just that it did).
  5. Tests are configured with huge property files (which you don’t have to edit by hand) but which are pretty unreadable. This also leads to cluttered test code. Things that I can do in a single line of code in JUnit take 20-30 lines of code and properties with AgileUnit.
  6. The documentation is confusing, outdated and riddled with spelling mistakes.
  7. Test code uses static variables which means you can’t use it in multi-threaded code.
  8. The configuration for the tests is not in the project but in the home directory of the user. All configurations for all projects are in the same folder which means you can’t work on two versions of the same project at the same time and you can’t put these files under version control.
  9. The sample project doesn’t work.

Conclusion: The idea to make sure expectations are met after a product has been deployed to production is intriguing but AgileUnit is not the solution. Some of the issues listed above could probably be fixed easily (lazy loading of properties, replacing the property files with a more powerful DSL) but the overall feeling isn’t promising. The code looks clean but for me, the project has too many problems which cry “this won’t get far.”