Bullet Bros. Kickstarter

I normally don’t post stuff about Kickstarter stuff since they seem to get enough press as it is and I’m not exactly a high traffic site by any means but I just feel ashamed that the Internet as a whole hasn’t jumped behind a game as ridiculously awesome as Bullet Bros.  It’s Contra with a bit more craziness thrown in.  Here are a few videos, first the Kickstarter video and then an extended gameplay video.


Be a bro and support the game. It’s time we had another game that has the spirit of the original Contra and not all these terrible rehashes that get thrown at us every few years.

The danger of a poorly written equals in Java

Recently, I was refactoring a system at work and ran across a rather hard-to-track down bug after writing a unit test.  The data structure was an ordered list of what were essential ordered 3-tuples.  At first, the goal of the refactoring was to move classes into new packages then verify that nothing was broken.  Along the way of doing the testing I was alerted to the fact that the default set in the ordered set had changed and that needed to be updated as well and this is where the problem reared it’s ugly head.

I made the changes to the default set to mimic those on the server and then when I compared the new set to the set on the server, I was coming up short on the number of tuples.  Doing a diff of the rules showed two cases:

  1. Incorrect tuples
  2. Duplicate tuples
  3. Missing tuples

I quickly compared all the tuples I created to the tuples on the main list and verified that they were correct.  Once these were verified, I set a break point to see why tuples were missing.  As I stepped through the code I noticed that there was a point where the list stopped growing and items were being replaced when they shouldn’t have.  Obviously, this means we’ve got a problem with the equals.

Looking at the equals, the error was subtle, they attempted to use an != command on two Integer classes expecting it to compare the integer value of the class and not the hashcode.  I made the appropriate change to the equals method and re-ran the test and it passed without problems.

Of course, here I was able to write up what was basically an entire day of work in a few paragraphs… you’d think it’d be easy to spot a poorly written equals or even figure out that is the problem when you begin to see issues in production code.  However, the nature of production code and the complexities of the systems often lead you down rat holes in the search for the true problem.

Update on @Autowired considered harmful

After writing my post about the pox of @Autowired, I’ve been doing a lot of things with Spring and have softened my position a little bit.  Spring is a very powerful tool and, unfortunately, with anything that is powerful you need guidelines and constraints to keep from doing something stupid that will cause a lot of pain down the road.  Perhaps my hardline on @Autowired to not be used anywhere was a little short-sighted, however, I’m still weary of it in many cases (due to the experiences I’ve had using it).  Anyway, the new stance I have is that @Autowired should be used purely on constructors and kept away from injecting dependencies any other way.  As a wonderful side effect, this is allows you to hold true with Josh Bloch’s Effective Java rule to prefer immutability over mutability and fail fast.

@Autowired considered harmful

I guess I’m on an opinionated roll, after declaring my dislike of the Singleton design pattern, I’m taking a swing at @Autowired.

Spring is a great framework for application development for Java and even though it’s now arguably more complex than Java itself, it’s advantages far outweigh the problems.  The best part of it to me is the IoC container however, it has introduced one of the largest poxes (next to Singleton :)) to Java coders everywhere: @Autowired.  I’ve seen more problems occur in code due to the use of @Autowired and package scan.  In fact, Colin Yates of Expert Spring MVC + Webflow fame, has this to say about autowiring:

If you insist on sticking with autowiring, there are three different types of autowiring … bad, dangerous and terrible.

And I don’t think I can say it much better than that.

Musings on Career Improvement: Switching Jobs

This isn’t so much a programming post or even a post on how to make yourself better.  It’s a post musing about switching jobs and how people look at switching jobs.  The idea that you’ll stay with one company for your entire career is an idealism best left in the 1950s since it in no way matches how business is done today. It’s now up to you to guide your career. A career is a succession of jobs that move you toward a goal. In some cases, it might only take two jobs to make someone happy or feel that they’ve reached where they want to be. For others, it could be various jobs with multiple companies or a few jobs with one company and then a few more jobs with another one still. Point being, you can’t count on a company to be your career.

Singleton: A Design Pattern Past Its Time?

I recently had a conversation with someone and in passing I said something along the lines of singleton being a pointless design pattern and something that I’d try my best to not use. They said there were lots of reasons for a singleton, then we moved onto a different topic.  However, it’s gotten me thinking, is there really a reason for the use of a singleton?  I did some digging through StackOverflow and found a few reasons as to why to use one — but even then, it wasn’t a glowing endorsement.  Nothing I’ve seen has really made me change my mind from the fact that the singleton pattern is something with very limited usability and most people seem to view the singleton pattern as a pox on the programming world.

Personally, I’d stay as far as way as possible from them unless absolutely necessary.

What do y’all think?  Is it now an anti-pattern or is it something that is still useful?