Blurry Words

Grey Matter Exploration...

2011-01-12T00:00:00-05:00

I’ve started an exploratory writing process; a timed exercise as it’s called in Natalie Goldberg’s book, Writing Down the Bones. I bought this book after it received high praise in the latest post on Rands In Repose. Rands mentioned that he’s on his third copy, mainly due to over use. After finishing it, and agreeing with Rands opinion of the book, I’ve permanently allocated a spot for it on my Kindle - to avoid the unneeded deforestation.

Every morning, for about 10 to 20 minutes, I just write. Punctuation doesn’t matter. Grammar, spelling, it all goes out the window as the task requires you to keep writing no matter what. The goal of this process is to reach what is described in Writing Down the Bones as “First Thoughts”. First thoughts are raw material spouted by your brain. Usually these thoughts are polished up and censored before being released from the shackles of your mind, if released at all. An internal editor handles the polishing. The editor must be overthrown during this process; keeping the output flowing renders it incapable of locking things down. Any hiccups in that flow - fixing punctuation, typos, grammar - will allow the editor to jump in and shut down the first thoughts jail break. At least that’s how I understand the reasoning for the process.

I’ve been doing this for only a couple days now. I haven’t been doing it long enough to see the benefits of the process. But common sense tells me that of course this process will be beneficial to my writing. There’s no doubt. If you want stronger muscles, lift some weights. If you want to be good at Super Meat Boy, then play the damn game until your thumbs bleed. And if you want to be a better writer, then write. Simple.

One thing I have noticed so far during the exercise is that my fingers aren’t comfortable with it at all, at least not at this point. I think it makes them nervous. Being a software developer, I type a lot. Whether it’s writing code, emails, technical specs; it’s never ending. And with all that typing, there’s a certain level of accuracy I’ve come to expect from my fingers. They know what’s expected from them and they’re very good at producing at that level. Without the safety net of editing in place though, and being required to keep writing no matter what, that accuracy level has gone to shit. I stumble through my thoughts, becoming preoccupied with the train wreck taking place just beneath my nose. My fingers plead with my brain to allow them to just fix one typo. Just one little typo. The right pinkie starts his sneaky ascent up to the back space. “It won’t hurt anyone, just one little correction.” the fingers explain, “It’ll make us all feel better.” The brain does its best to keep everything flowing, but those ten little digits are persistent. The battle rages on. The typos pile up.

I’m interested to see what I can produce once editing and finger nerves take a back seat to first thought production. I recommend you give it a shot yourself. See what uncensored thoughts flow out of you…if you dare.

When Fax Ruled the Future...

2010-12-31T00:00:00-05:00

Between last night and this morning I’ve consumed a lot of Back to the Future content. In celebration of the 25th anniversary, and to take part in the marathon television rituals associated with bringing in the New Year, AMC has been showing the trilogy every night this week. I took in the second one last night, which is my favorite of the bunch. It’s not the best of the trilogy, part one reigns supreme. However, two’s a much more endearing movie, mainly due to the future sequence that the film opens with. Looking at where we can go, what could be possible is far more interesting than looking back at what once was. Sure, being able to see your parents before they were your parents is somewhat intriguing. And sure, being able to experience a time that you’ve only heard about through twisted, idealized stories of yesteryear would be… I guess eye opening is a good way to describe it. Maybe disappointing, depending on how skewed your elders’ memories of the good old days are. No matter what the experience, I don’t think it ranks even close to what it would be like to experience a time yet to even be conjured up.

One of the fun parts of watching Back to the Future 2 is looking at how close our world resembles the imagination of the late 80s. We’re now a matter of hours from being only four years from the future that Doc, Marty and Jennifer visit. AMC did a great job of prefixing each of its commercial breaks with a look at the predictions made in the film, and which of those predictions came true so far. What I found interesting in my latest viewing was the technologies and everyday items that the people in the 1980s thought would stand the test of time and still be an integral part of daily life in 2015. Let’s take a look.

Laser Discs (trash piles near the landing site of the Delorean)

Growing up, my experience with laser discs was brief, but memorable. One of my parent’s friends had just bought a new laser disc player and we went over there to allow them to show it off. We watched Terminator 2. I remember the sounds booming. I remember Arnold ripping around on his motorcycle. The T1000 latching on to the back of their car as they sped away; all this in picture quality I had never seen before. It was awesome. My 10 year old brain nearly exploded.

It’s easy to recall why in 1987 LD seemed like the wave of the future. But it’s bulky, awkward size and high price tag made sure it would never catch on. Being the predecessor to DVD and Blu-ray is an ok consolation prize though…I guess.

Phone Booths (clusters are seen throughout the town square)

This one’s a little more baffling to me. The first generation of mobile devices was already in existence at the time this movie was being penned. They were nowhere near the mainstream yet, but they were there and by the early 90s, the down fall of phone booths was already under way. Can you remember the last time you saw a phone booth? No? Me neither.

Newspapers (Doc’s future predictor)

It’s no secret that newspapers and magazines are in serious trouble. Making it through 2011 alive is the goal of the industry right now; forget about making it to 2015.

The Internet was there in the 80s, but it wasn’t until the 90s when it started its meteoric rise. But still, a median like the newspaper that requires massive consumption of a natural resource should always be considered in danger of being supplanted in the future.

Fax Machines (Future Marty and Jennifer’s house)

Fax machines are still part of the business world in a diminished capacity. It has a slim chance of existing in 2015, but it will never be, and never was, at the prevalence depicted in part two. Marty gets fired, he has fifteen different faxes going off to tell him about it. I don’t think I’ve even seen a total of fifteen fax machines in my entire life.

The fax machine had its placed, and still does. Unfortunately for the fax, not for us though, another technology (email) was lurking in the dark, primed for the head shot and exclamatory tea-bagging.

So, what can you take away from this post? I didn’t write this post to nitpick at the movie. Don’t get me wrong, it’s fun to pick this stuff apart, but it’s not the point here. I’m using the flick to make a point about the perils of an ever evolving world. Paradigm blindness. “This is how we’ve always done it”-syndrome. It’s a defense mechanism against the laser discs and fax machines of the world. But, it cripples you to being open to the planet shakers and world shattering advancements. If you’re a consumer, this isn’t a huge deal. It’s the difference between being an early adopter and catching on once the new technology is in the mainstream. Not a big deal; it probably saves you a bunch of cash and heartbreak when a new product doesn’t catch on. However, if your in the business world with this mindset, it’s a much bigger problem. You’ll always be playing catch up; no way of getting ahead, no way of hitting it big if you aren’t at least willing to explore new ways and new developments.

When We Last Spoke...

2010-10-31T00:00:00-04:00

Blurry Words has long lain dormant while dust and comments of porn links and penis enlargement offers settled on its inanimate frame. The posts have grown stale, and an overwhelming stench hangs in the air. It’s either decay, or…no, it’s definitely decay.

Deep in the bowels of the site a furnace roars to life. Blasts of heat and power roar through the outer extremities. Lights begin to flicker. An old timey record player can be heard in the distant as it slowly begins to play NSync’s, “Bye, Bye, Bye”. Blurry Words arises from its indefinite slumber.

Welcome to the Halloween relaunch of Blurry Words. It feels good to be back. I hope you didn’t miss me too much. The archives say that the last time I posted it was October of last year. Younglings have this innate capability to torpedo pretty much anything; all with a smile, or a laugh, or a steaming pile of unmentionable in their diaper.

Beyond that, I’ve been extremely busy. Work. School even. Some play. A good video game will trump a new blog post nine times out of ten. But now I’m recommitted. I have my wife to thank for that. She threatened to disallow the auto-renewal of my server space to take place. This immediately awoke the five year old version of me inhabiting my subconscious. Because, even though I’m not interested in it right now…actually, I am interested in it right now. Give it back.

It’ll be good to get back to writing posts. I really enjoyed scraping them together back when I was actively spewing. I found it fulfilling and surprisingly beneficial. My writing skills got better; something that was noticeable at the day job. My fingers were able to express ideas that my mouth just couldn’t. That mouth of mine; it’s pretty horrible at the whole communicating thing.

But lately, I’ve felt the writing skills slipping. Composing technical specs and impact analyzing was becoming a less fluid process. My writing muscles have digressed in to a soft, mushy mess around my mid-section. It’s time to hit the gym.

If you’ve been to BW before, you might’ve noticed that the site got a bit of a redesign. I’ve spent the last few weeks banging the dust off, hanging up some air freshener, and basically just revitalizing the ol’ stomping ground. I ripped out her previous engine (WordPress), which was more of a hindrance to my process than anything else, and replaced it with a kick ass little tool that does everything I need in a way that I seem to enjoy (Jekyll).

As I said, the layout and visual design is completely revamped. My goal was to simplify and have a clean reading area for the posts. I recently read through Chuck Klosterman’s Esquire archive. The thing about Esquire’s site is that it is horrendous for reading articles. There’s animated ads flashing away on the right, a noisy side bar to the left; it’s a horrible experience. So, I started opening up the articles in their provided Print view. Much better. That’s how articles are meant to be read on the internet. And even though the old BW design was nowhere near the travesty that Esquire’s is, I feel really good about this new one.

So there you have it. Blurry Words, back in action. Hopefully I can avoid all this Meta conversation in the foreseeable future and just bang out some interesting posts. Until then, enjoy Klosterman’s Esquire articles, if you haven’t already.

Partial Functions and Enforcing Extension

2009-10-10T00:00:00-04:00

I like playing around with other programming languages from time to time, just to see how or what they do differently than the core languages that I work with every day. So this morning I was spending some time with C#. I’ve actually done some development in C# in the past. About three years ago now, I think it was that long ago…maybe longer, I used it to develop both a Sprite Editing tool and a Level Designer. So I’m “familiar” with the language, but basically have etch-a-sketched what makes it unique from Java.

My rediscovery of C# got me thinking about function modifiers, mainly because C# and Java have countering approaches to handling virtual functions. In Java your a virtual function unless declared otherwise by using the final modifier (private methods are probably not considered virtual either). But in C# it’s the exact opposite. Your virtualality (is that a word?) needs to be explicitly declared by using…wait for it…the virtual modifier.

Another difference is in the subclasses. Again, C# seems to be much more explicit about this kind of stuff. You must use the override modifier to declare that your overriding a virtual function. In Java you really don’t have to do anything, just make sure you have the same name and parameters. Sure, that @Override thing’s been tacked on to newer versions of Java. This helps the compiler make sure that the virtual method actually exists in the superclass, but you don’t have to use it if you don’t want to. C# makes you use it, which in turn ensures of your intentions.

Are these differences a big deal? Not really. My preference would probably be with the way C# accomplishes it, as it allows you to be more explicit in your intentions without being anymore verbose about it, which results in clear, easier to maintain code.

But the purpose of this post is where my mind went when considering the way virtual functions are handled in both languages. There happens to be a big hole in the amount of control that the superclass can take over its virtuals. In both languages, actually any language I’ve worked with for that matter, the superclass has little to no control on whether or not the subclass inherits the functionality provided by a virtual function. If the subclass feels it needs the superclass’s implementation as well as some additional stuff, then it can easily call upon the provided code by doing super.FuncName() in Java or base.FuncName() in C# within the overridden function. But, what if the superclass wants to force the subclass to use the code its virtual function has provided? What if it just wants to provide the subclass with the ability to extend a method and not completely override it? Both languages need what I’m calling, the partial function modifier.

For those that haven’t stop reading, a partial function would be a function declared and defined by the superclass that provides some functionality that needs to be a part of every subclass’s implementation of that function. The subclass would only be able to extend, using the extend modifier of course, the function and provide further logic that is specific to the subclass’s needs. Similar to an abstract class, the partial function would be required to be extended, or have its class marked abstract, as by marking a function as partial the superclass is basically saying, “Hey, this method, the code it implements…it’s required but the function is still unusable unless you provide the functionality needed to complete it.”

Here’s a usage example to show…what else, it’s usefullness. Let’s say you have an abstract GameState class. This class should be inherited by every different game state that your game has. You’d probably have a subclass for the main menu, gameplay, submitting highscores, and so forth and blah.

The GameState class will need to define methods for loading, drawing and updating. Each method will need to be implemented by every subclass. You start off by making all three of the methods abstract. But then you start creating some subclasses and realize that each and every call to Update should query for actions by the user. Did they press a key, did they select something…stuff like that. So you turn the Update method into a virtual method (lets think in C# on this one) and implement the querying functionality for the user’s actions. Now each subclass just needs to override Update and call base.Update() within it in order to take advantage of the functionality provided by the superclass.

That seems like a perfectly acceptable way of implementing the Update function. But what ends up happening from then on is that every time you create a new game state and go about setting up your Update method, you forget that you need to make the base.Update call. So you start testing the new state, no user input works and you smack yourself in the head for forgetting that same stupid call once again. Now if you had a partial function, the burden is on the superclass to make sure that that part of the code is implemented every time. And the superclass has no problem with that…mainly because, well, it’s SUPER. Sorry, that’s lame but I’m leaving it in.

Anyways, would a partial method modifier really save you oodles of time…probably not. But the point is more that the superclass should be able to control this kind of circumstance, not the subclass. And right now the subclass is piloting the ship. Partial methods ensure that the vital code of a method, and we can assume that it is vital because otherwise there wouldn’t be a reason to force the subclass into using it, is being run before anything else the subclass might tack on to execute. A little more complexity can be hidden and a little less burden can be put on the subclasses, neither of which are ever bad things.

The BlackBerry JDE Can't Find javac...

2009-09-19T00:00:00-04:00

The overall process for installing the JDE is straight forward, just download and follow the installation instructions that follow. However, after you create the de facto “Hello, World!”” application and you attempt to compile, you may run into the following error:

I/O Error: Cannot run program "javac": CreateProcess error=2, The system cannot find the file specified
Error while building project

Not a great way to start, but not a huge problem to fix. Most modern day IDEs now ask for the installation location of your Java Development Kit (JDK) during the installation process. However, the JDE relies on the system to inform it of where the JDK is located. This means that you need to make sure that you specify your JDK’s bin directory in your PATH variable. You can do this permanently by opening up the “Systems Properties” dialog and under the “Advanced” tab clicking on the “Environment Variables…” button. Now find the PATH variable in the “Systems Variables” list and add <PATH TO JDK HOME>/bin to it.

Once your done with that, reload your JDE and compiling should commence with only issue that are of your own doing.

Bing vs. Google...The Results Show!

2009-09-12T00:00:00-04:00

Let’s be blunt about this. No reality competition cliff hangers. No right after this commercial break. Let’s just dive right in for those that have no interest in staying ‘til the end.

Basically, from my perspective…Google’s still king!

As I stated in my previous post to set up my intentions for this comparison, I made Bing my default search provider in Chrome for what I consider a “significant” length of time. That turned out to be a couple of months. If Bing gave me search results that were useful relative to my needs, then it got a tick mark. If it didn’t, I jumped over to Google to see what its take on the same search would be. If Google came up with something useful, it got the tick mark.

It should be noted that I realize this isn’t a very scientific process. Trust me, I’ve had it pointed out to me several times by those that noticed the accumulation of tick marks on my whiteboard. I get it, it’s a bit hack. But at the same time, determining which search engine provides better results is a completely subjective process that could never truly be scientifically analyzed anyways. So, I deem my process good enough for my needs and good enough to blog about.

As you might have guessed from me giving away the punch-line at the start of this post, Bing was a bit of a disappointment. It turns out that about 30% of the time Bing gave me an answer that I didn’t find useful and Google was able to provide something better. That’s a fairly significant amount of the time, certainly not good enough to be named my default going forward….or to even give it a chance at a one to one comparison with Google. It just didn’t cut it.

Beyond the 30% fail rate though, what really started to bother me about Bing was its rigidity and inability to cope with my mistakes. Mistakes like me making a typo. Where Google seamlessly adapts to such a mistype by its users, Bing responds with something like so:

Not being able to adapt and push forward through such a typo is just not acceptable anymore. Google handled it perfectly without any further effort out of me. It recognized that there was a 99% chance that I was talking about checkstyle, a software development tool for adding code convention checking to your build process, and gave me the results for its assumption. While on the other hand, Bing just stood there with a dumb look on its face like it had no freaking idea what the hell I was talking about.

So Google’s officially back as my default browser. Though this comparison was enough to convince me of its superiority, you shouldn’t let it convince you. As I said, I had this test on my whiteboard for two months. Anyone that saw it had an opinion on this and some of those opinions were that Bing definitely supplied more natural, useful results than Google. You basically just need to figure out what works best for you and go with it. Bing has a lot of functionality and is far superior than all past challengers of Google’s space. But for me, it still falls short.

Blur #00012

2009-09-07T00:00:00-04:00

I’ve reorganized Blurry Words again. Now all Blurs will be inline with the rest of my post. I’m mainly making this change as I’ve had a few blurs that went unwritten due to the fact that I had no space to include an image or another type of media. Though I liked having the blurs on the left sidebar, this should allow a little more flexibility, which is the main reason for having the blurs in the first place.

Also, I hope to have some new useful content up here in the near future. My wife gave birth to our daughter four weeks ago today. On top of that we just bought a house as well. So, it would be an understatement to say that I’ve been preoccupied.

But, I do want to get back to it. I have the conclusion to my Bing vs. Google comparison and I plan to add a new subcategory to the BlackBerry category called, BlackBerry Gotchas. These will be shorter posts that allow me to document quirks and other nuisances of BlackBerry development that are not always so obvious and may cause developer some undesired grief (and possibly already have for myself).

Blur #00011

2009-08-06T00:00:00-04:00

There’s something about Xbox achievements that drives the way I play. Chasing achievements is part of the experience and definitely extends the life of a game. The whole system has been a huge success. With that said, the point of this Blur is to bitch about how the achievement system is wrecking Horde Mode in Gears of War 2.

With the latest Dark Corners downloadable content, tied with a great deal to bundle it with the rest of the released map packs, I jumped back in for some more Gears this week. I was done, I put it a way to spend some more time with my other neglected games. But, now I’m back…damn you Epic.

Horde mode has been my focus. And, because I’m hugely driven by achievement earning, my decision on which map to play is completely driven by Gamerscore Greed. And, it’s not just me. It seems like the whole community is thinking the same thing.

Getting a complete 5 man team of randoms is now officially impossible. Players don’t get the map they need, they drop. You usually end up with 2 or 3 guys trying to take on the horde, which becomes nearly impossible around level 9 or 10 (yes, playing with friends that you communicate with makes it less impossible, but with a bunch of silent randoms…no way).

Since most achievements revolve around reaching level 10, this turns into a pretty frustrating experience. Quite a waste of time. I’m sure this wasn’t the intended behavior, but it surely has created an annoying monster.

Blur #00010

2009-07-26T00:00:00-04:00

I finally remembered to take in a live 1 vs. 100 last night. It took sticking a big orange post-it to the tv for me to remember, but I remembered. And it was worth the effort, even if I didn’t get to be THE ONE, or in the Mob, the audience is still a pretty fun experience. You’re paired up with three other randoms and you compete against them for fun and pride, but you’re also striving to be one of the top scorers in the audience for the round. This results in prizes…free XBLA games!

Anyways, it worth checking out. Hopefully I’ll make it to the mob next time, but even if I don’t it’s still fun to answer some trivia questions, yell at The One to take the money and get your avatar dancing (hint: pound the shit out of Y).

Blur #00008

2009-07-19T00:00:00-04:00

Limit the width of your posts. The blogs that dynamically adjust the width of their posts to match the window resolution usually results in me not reading them. Sorry, but it’s unpleasant to read a 700 word post on one line. That’s a bit of an exaggeration, but with larger resolutions you can still end up having horribly formatted posts.

Supposedly 70 to 80 characters per line is optimal. I don’t think you have to go that narrow, but have some kind of max boundary.

Java's Coding Convention Hmmms...

2009-07-11T00:00:00-04:00

I spent an hour or so the other night refreshing my knowledge of Sun’s official coding convention for Java. Obviously these are just suggestions and you don’t have to follow them at all, though I’ve made it clear that I would be in full support of a language that did enforce such a standard in my post standard style post. Nevertheless, there are a few suggestions in the documentation that make me wonder why support wasn’t just built into the language for them even if they didn’t want to completely support a coding convention through the compiler.

The fact that these are part of the convention says to me that someone at least considered these items possible problem areas. Were they banished to the convention in order to avoid building any barriers that might deter C/C++ programmers from adopting Java in the early years? Maybe the convention just came later. Or maybe it has been edited several times since the language was originally developed and these items were just oversights that can’t be fixed at this point. This is certainly a possibility considering how easily a convention can be changed compared to the language itself.

/* falls through */

I think switch case statement fall-through is a bad thing in its only supported form, as I mentioned in my simple rules post from a while back. It shouldn’t be allowed without the compiler being able to have some kind of control over it, and I think Sun knows this. The switch statement below is directly from the coding convention.

    switch (condition) {
    case ABC:
        statements;
        /* falls through */

    case DEF:
        statements;
        break;

    case XYZ:
        statements;
        break;

    default:
        statements;
        break;
    }

In my opinion the /* falls through */ comment is just hack. Imagine you have a wall in your house where a 2x4 is missing. So, at one position on the wall there is a span of 32 inches without a beam and the wall is a little less stable in that vertical strip, a little less likely to support weight. So, to avoid a drunken idiot, or just a normal idiot, from breaking through the wall, you write in big red letters, “Weak Spot” in the problem area. Problem solved, unless the drunken idiot didn’t notice it, as he was too busy crashing through your new lamp that you just picked up at IKEA over the weekend.

An open manhole cover is another, possibly more realistic analogy. It’s likely that an open manhole cover will have some kind of visual warning similar to the /* falls through */ comment. Possibly orange cones. The only difference is the manhole is only open temporarily, it’s not a permanent situation. Also, they use bright orange cones, an object out of the ordinary. Comments are usually all over the place in code and quickly are filtered by your SEP field.

There might be nothing they can do about it now considering that there are way too many applications out there developed with Java that might just stop working if they made such changes to the language, but it is still a pretty hack solution to the issue. They would serve new developers better by just telling them not to use case fall-through.

In the most hindsite, snooty, Monday morning quarterback way, they should have done something like this.

    switch (condition) {
    case ABC:
        statements;
        continue;
    case DEF:
        statements;
        break;

    case XYZ:
        statements;
        break;

    default:
        statements;
        break;
    }

Use the continue keyword to allow case fall-through. Or they could’ve created a fall keyword; maybe even, gasp, a goto <case> type of implementation. Anything that gives the compiler control over case fall-through is better than nothing…er, having a /* falls through */ comment.

Statements Always Use Braces

I always use braces…always. I can’t stand the look of of the following in my code:

    if(condition)
        doSomething();

It just comes off as messy to me, not uniform with the rest of the code. I think it’s perfectly acceptable in a language like Python as code blocks are defined by indentation, not opening and closing curly brackets. But, in languages that rely on braces, you shouldn’t be allowed to define a code block any other way. And again, it seems the developers of Java agree with this. Section 7.2 of the coding convention states:

Braces are used around all statements, even single statements, when they are part of a control structure, such as a if-else or for statement. This makes it easier to add statements without accidentally introducing bugs due to forgetting to add braces.

I’m going to chalk the decision to not put this in the language up to staying inline with the supported syntax of C/C++. Programmers are fussy prima donnas. You don’t mess with their preferences, even if there preferences are completely wrong.

The fact that this isn’t a part of the language isn’t a big deal, but if I see an if statement missing curly brackets in code I’m working on, I’m compelled to add them. And you should be too.

Public, Private, Protected…why not Package?

Recently I’ve been seeing this a lot in code I’ve been working on.

    /*package*/ class SomeClass {
        public String someVariable;
        /*package*/ Object someVariable2;
    }

It irritates the shit out of me. If you spend ten freaking minutes working in Java it’s likely that you will learn, or figure out that the absence of an access modifier makes the member/class public to the package, but private to the world. But, it does make me wonder why they didn’t just go the extra step and make a package access modifier. It neatly falls in line with the length and first letters of the other access modifiers; it seems like it would have been a natural part of the language. Also, it would keep my code looking slightly more uniformed. The variable name for private, protected and public variables all start in nearly the same location. Then you have the package variables that start way before anything else…or at least a couple of characters.

I know, this one’s a bit nitpicky. Unlike the other two, having a package modifier doesn’t help fend against introducing defects. It’s completely a visual preference of mine. It doesn’t matter. However, putting the /*package*/ is way worst than just having nothing at all, so just don’t do it. All that says to me is that the programmer was too stupid to remember that the member would only be able to be accessed by other members of the package. You don’t want me thinking you’re stupid, do you?

Anyways…

I understand that creating a flawless language is hard, if not impossible. I also understand that this stuff is subjective and you may not agree with it. And I also realize that even if Sun now believes this stuff should be enforced by Java’s compiler that it will never happen due to the fact that many companies and developers rely on their shit being consistent with what is already available. But, that doesn’t mean I can’t point out their flaws from atop my safe little mountain of hindsight.

Blur #00008

2009-06-27T00:00:00-04:00

I’ve been experimenting with Linux over the past month. Linux Mint to be precise. Just Quickly, it’s been five years since I’ve used Linux, which happens to correspond with graduating from college. So, I figured I would take my now not used desktop and do some exploring. I’m very happy with the experience so far, but that’s for another post.

What I wanted to mention was that even in its pre-release developer state, Google Chrome Linux is still the best internet browser I’ve fired up. Firefox is solid but feels a bit sluggish, and Opera’s page rendering is embarrassingly slow. I was starting to think it was my connection, or something with Linux…not true. Chrome friggin’ rips, just as you may have come to expect from it on other platforms. Being pre-release you run the risk of it being a bit buggy, but I haven’t had any issues to this point and I certainly wouldn’t let that stop you from giving it a try.

The Bad of Warnings as Errors

2009-06-24T00:00:00-04:00

I’m going to go out on a limb here to make a point that treating warnings as errors can be a bad thing. I think there is a place and a time for such requirements. When code has reached the testing or maintenance part of its life-cycle, treating warnings as errors makes a lot of sense. It results in higher quality, more accurate code, cleaner build results and possibly a better overall product (though I don’t see how a rogue unused import statement would make any difference when it comes to the perceived quality of the product).

With that said, it has no place in the implementation process. Instead of a tool for writing better code, it has the ability to manifest itself into a big waste of time and a destroyer of the elusive “flow”.

Recently I’ve been working on a feature that requires communication between a couple of different layers. In one layer I’ve set up an event listener/dispatcher to listen for events from the other layer. The dispatcher then calls upon an event processor that does what is needed for each event and passes the results back to the other layer through a callback function. I created an interface to wrap the callbacks so I can set up a test environment that points to some fake callback functions until the other layer’s actual callbacks are in place. I then created a variable for the callbacks within the event processor with the intent on using it later, but before that it was just to define my class design a little more clearly within the code.

Before getting the callback stuff working, I needed to get the event communication between the two layers working properly. I spent about an hour working out the details before I attempted to build and see how well I had progressed. All my syntax seemed fine, thanks to the power of the modern IDE. So I was pretty sure it would at least compile. Running properly was a completely different story, but I thought I would at least have a build that I can get on the device and start debugging. I fired off the build and about five to six minutes later…

Compiler “You dumb shit. The variable callback is never used. I could just keep building and let you off with a warning…screw you, bitch. Error!”

Okay, so my compiler isn’t that big of a douche, but it might as well be as it just puked on a warning during a build process that takes around 10 to 15 minutes to complete, depending on what you changed, all because of a variable being unused. A variable that I expected to be unused at this point as it is just there as a place-holder for me to visually see the design of my future implementation. Any flow I had going is completely shot at this point, as you might have expected. There’s nothing else for me to do but let out a sigh, comment out the variable, start the build again and go get some coffee.

When I returned the build had aborted…again! This time it’s due to a package being imported that isn’t being used; the same package needed for the callback variable that I just commented out.

Compiler “Hey idiot, you don’t use this package. Error, bitch!”

Now that’s twice the compiler has called me bitch. Twice! All I can do is go the rout of Jim Carrey in Liar Liar; piss, moan, bend over, take in tailpipe. Comment out the import statement, start the build process and make some notes in my notebook to write a post complaining about warnings as errors.

So, you can see my point about it being a bad thing. Anything that decreases your productivity needs to be considered a bad thing. The question that I’ve been pondering though is, is it worth turning warnings being treated as errors off in my local environment during the implementation stage of a new feature? Do I dare risk becoming the ass hole that broke the nightly build because I didn’t turn warnings as errors back on before submitting my changes to the depot? Yeah, that’s all I want is to be the jerk that thinks he’s better than treating warnings as errors. I don’t think so.

So, I’m dealing with it. I’ve made some adjustments in my IDE to make it more obvious that I have potential warnings that will break a build process. Mainly, I’ve adjusted the color of the squiggly line color from a barely visible whiteish yellow to the blazing red of the error messages. I’m thinking this might need to change to a different color to avoid me having to decipher whether the marked code is actually an error or a warning, but “you’re freaking screwed” red is fine for now.

I also use a lot of “// TODO” comments now to layout the skeleton of classes. It’s not as pretty, but at least the IDE generates a nice task list based on them for me to reference. All and all I’m still not for treating warnings as errors so early in the development process, but sometimes a slightly less productive setting for yourself can be much better than possibly slamming your whole development team’s productivity against a brick wall.

Blur #00007

2009-06-16T00:00:00-04:00

Even if Bing falls short in my search engine battle to the death with Google, you should check out its map utilities. Here’s a link to the Empire State Building in Bing’s Maps. I’ve heard this isometric view described as SimCity-ish. It’s a fun feature, worth the time required to give it a look.

Bring It On! Bing vs. Google

2009-06-15T00:00:00-04:00

My wife asked a question the other night after seeing one of Microsoft’s new Bing commercials. You know the ones; the commercials that really don’t tell us anything useful about Bing, but reflects how awful all other search engines are and how they leave their users interpretting rambling non-sense.

She wondered, “How is it a decision maker? What does it decide for me?”

The question is a valid one. How is Bing being a “decision maker” any value to me? What a completely freaking useless description of this new service. It doesn’t reflect whether the service does anything positive for its users, it just makes decisions; good or bad, useful or not, it decides stuff. BING!!!

Even though Microsoft’s marketing campaigns continue to bite the big one, Bing still deserves a crack at taking Google down. Google’s been great, but every champion needs to defend its title against legit challengers in order to retain its status. So, last week I set Bing as my default Browser in Chrome; you’ve gotta love the irony in that. I’m going to keep it set this way for the next month or so and then report back on how I feel about Bing compared to Google.

Since it’s the new guy, Bing will need to prove itself. And because of that, Bing gets first crack at each search. If it can’t supply a result that I’m satisfied with, then I’ll jump over to Google to see what its take is on my query. It’s Bing’s job to avoid this from happening, not Google’s job to prove that it can match or better every search that Bing gets right. The number that Bing gets right is not the challenge here; it’s how often Google can successfully swoop in and provide a relatively correct result to my query. I define correctness as a result that is useful within the top 5 to 10 results.

This isn’t a very scientific approach, but it will surely answer for me whether Bing stands up to what we all know Google can do. After I’ve reached a personal conclusion, I’ll report back with my findings and opinions. Let’s get it on!

Blur #00006

2009-06-14T00:00:00-04:00

The 2009 BlackBerry Developer Challenge has been announced. Being unable to legally participate myself, I thought I would pass the data along. There’s a chance to win $100,000 in cash and prizes, and to get your work some exposure at the BlackBerry DevCon in November, certainly seems worth a couple of months of effort if you have the idea and the time.

Blur #00005

2009-06-03T00:00:00-04:00

I thought about having a full post about the E3 console manufacturers’ press conferences. I planned to talk about what games looked awesome, what new tech looked interesting, maybe make fun of the unprecedented, historically significant ability for every talking head to monumentally over sell everything. Hey Don Mattrick, the sequel to World War I is considered historically significant; the sequel to Modern Warfare, another rev of Rock Band, some more use of the Halo property…not so much.

But, after watching them all it just didn’t seem worth it. Between Natal, which I’m pessimistically optimistic about, Wii Motion Plus and Nintendo’s other interactive gizmos, and Sony’s wand thingy and camera, which looked frustratingly painful to use, all consoles have now officially adopted motion control. The problem is that the new car smell of what the Wii brought to gaming is gone and copies are not that exciting.

Anyways, this is what you need to know. There will continue to be awesome games coming out around Christmas. All consoles will soon allow you to wave uncontrollably at your television. That’s about it, not worth the five hours of viewing.

Marvel's Digital Comics Service Reviewed

2009-05-30T00:00:00-04:00

About a year and a half after its launch, Marvel is graced with a review of its digital comics service from none other than Blurry Words. The excitement that must be running through the brains of the Marvel execs; to see their company’s name across the top of this post, how exciting for them. What a thrill! What a moment!

(the sound of confused crickets chirping)

Anyways, I’ve been playing around with the service for about a month now. I’ve read through about 40 or 50 books and I have to say that I’m sold. It’s not a perfect service at this point, the set of tools available need some more work, some additional features, but nothing that can’t be improved over time.

The Basic Parts…

There’s two major parts to the service; the Digital Comic Reader and the Account Manager. In my opinion both will be equally important to the overall experience and to the overall success of the service. However, at this point the comic reader is way beyond the manager. That’s not completely unexpected considering the service is all about reading comics digitally, but once you get the users in the seats with the glitz of the reader, you need to keep them fulfilled with the entire experience.

So What About The Reader….

The reader is a very robust, easy and intuitive experience. It provides three different reading modes; the static one and two panel modes, both equipped with zoom capabilities, and the Smart Panel mode, the bread and butter of the service. Smart Panel mode works by having each book define the optimal viewing position and zoom level for each region of each page. Using the left and right arrow keys, you seamlessly transition and auto-zoom to each sequential region of the comic you’re reading. If you want to zoom out and see the full page, hit the down arrow. To zoom back in to the last viewed region, hit the up arrow. It’s a great experience. It stays out of your way and lets you enjoy the book.

The smart panel mode isn’t perfect though. First, it’s not friendly with all viewing aspect ratios. The viewer defaults to your screen resolution. On my machine, with the resolution set at 1920x1200, the bottom of the page’s often get cut off. This is easily fixed by adjusting the reader window to a more agreeable aspect ratio, but you would hope they could make it so that the default resolution looks at your screen resolution and adjusts its spawn size to the closest resolution that is an appropriate aspect ratio. Or, do a better job of supporting all screen resolutions…which ever’s easier.

Another issue has to do with the dialog bubbles. In a lot of the books they aren’t part of the page, they’ve been formatted using vector graphics to overlay the pages. This is for a separate feature available in the one and two panel modes that allows you to mouse over each dialog bubble to have them zoom in for easier reading. The problem is that they don’t always align properly, which isn’t usually a problem but in some books the text wasn’t removed from the page. So when its misaligned you can see both bubbles. Also, some times, not often, the bubbles are so badly misaligned that it’s hard to tell who is saying what. This makes reading a little annoying, but not that big of a deal.

Finally, it seems to hang a lot when using the reader with Google Chrome; something that will be fixed with time I’m sure, giving how new Chrome is. Firefox seems to work fine though, no hang ups even after days of having the same instance of the reader open.

All of these issues can be fixed, as long as Marvel is willing to put the money into making a the service better, which you would expect would be the case considering the heavy web-advertisement campaign they have going. But, even if these issues aren’t addressed, none of it is a big enough deterrent to not praise the overall experience of the reader.

Then There’s The Management Page…

The Account Management functionality on the other hand is passable at best. It has several different ways of browsing through the collection, you can rate each book you read, and it allows you to mark your favorites (neither from within the reader though), but that’s about it. My biggest complaint is that there isn’t a way to track what books you’ve read. I’ve been using the favorites list to accomplish that, but I would love to have both capabilities. There’s also no way to see your recent reading history, meaning there’s no way other than remembering the last book you read to pick up from where you left off. I’ve just been leaving the reader open to accomplish this, but that’s not always possible, and it’s certainly not ideal.

Another thing that bothers me about the manager is that when I do rate a book it doesn’t show me what I rated it. It takes my rating and adds it in to the global score and then just displays that global score. I’m guessing they’re not even tracking this metadata for each individual user, but I would love to see what my own opinion of the book was, not just what the rest of the world thinks. Maybe they could show the world’s opinion with yellow stars and then overlay my score with transparent red stars?

What ELSE Would I Like…

I would love to see the listing for the entire series, whether the book has been digitized yet or not. That way users could use this service as a complete management system not only for their online reading, but also for what hardcopy books they’ve read and own (assuming the missing management features mentioned previously existed).

Also, having a voting system for which books should be digitized next would be fun as a community feature, and a useful way 1) for Marvel to know what its paying customers really want the most from the digital service, and 2) empower the subscribers by letting them know that they are molding the content that Marvel is supplying through this service. Both are vital to the success of a user-centric service such as this.

So, what am I saying…

The reader is great and the account manager is passable but could be a much richer experience for paying subscribers. With that said, I highly recommend checking it out. You can read a ton of books for free to give it a try, and after you get hooked, the service is dirt cheap, 10 bucks a month or 5 bucks a month if you pay for the whole year. Just to be able to read the older issues that would be impossible to find, and impossible to afford if you could find them, makes this service worthwhile.

Blur #00003

2009-05-25T00:00:00-04:00

Finally, Mac is World Champion of the WORLD!!! The young Mac has dethroned the long time champ, Mr. Sandman, with a shocking Knock Out in the 3rd round. Mac has a staggering record of 13-39, and even though Mr. Sandman granted him 23 rematches, Mac declined Sandman’s request to step in the ring again. Instead, a match with the legendary Glass Joe has been scheduled for later this afternoon.

The Mega Man 9 Effect applies to PunchOut!! for me. I haven’t tried it with Wii motion controls, but why would you want to? This is pattern recognition and reaction at its best. Maybe I’ll eventually give the Wii experience a try, but for now I’m happy with nostalgia.

Blur #00002

2009-05-23T00:00:00-04:00

To show the useless nature of the Blurs, I thought I would express my opinions on the latest Terminator movie, Terminator Salvation. It’s a movie I was looking forward to for a while, finally a look at the actual war that ensues after Judgment Day. Unfortunately, it was a bit disappointing.

For one, Christian Bale was not good. This is something I can’t ever remember saying before, but that damn heavy breathing voice, the voice I refer to as his “Batman” voice, was on overdrive for the entire movie. It’s distracting, and annoying, stop doing it Bale.

The other disappointing part was the scale. I wanted to see Lord of Ring size armies of Skynet soldiers hunting the human rebellion. Instead, we only ever saw two or three Terminators attacking at a time. The war just felt like a skirmish at best.

There was some good, but it really falls short of my high expectations.

Blur #00001

2009-05-23T00:00:00-04:00

I came across Mike Gunderloy’s blog, A Fresh Cup, and I liked his formatting. He has normal posts, but then he also has micro-posts called “Double Shots”. I’ve called shorter posts “Blurs” since the beginning, but I’m now going to formally define it to be a micro-post. These will be quick opinions or observations living on the left side of Blurry Words. They’ll have less than 150 words and usually be useless, but will give me an outlet to keep posts flowing. Let’s see how it works out.

BlackBerry Java - Arithmetic Comparisons

2009-05-02T00:00:00-04:00

This investigation took me longer than I had hoped to get to a conclusion, mainly because the results I was getting weren’t matching my expectations. I started off by comparing the speed of arithmetic calculations between the BlackBerry Java’s native float implementation and its static class implementation for fixed point math, Fixed32.

When first faced with the need to store fractional values, I gravitated towards the Fixed32 class for two reasons; the first being that I’ve always had to use a fixed point implementation when developing mobile application as floats and doubles are not usually available. The second reason was that I believed the Fixed32 class existed for a reason, that reason being that the float implementation was so horribly slow that this additional fixed point implementation had to exist to compensate.

It turns out that the Fixed32 class is legacy code of the BlackBerry platform, implemented early on before floats and doubles could be properly supported. And, the truth was that the float multiplication and division implementations are faster than the Fixed32 implementation’s, though float addition and substraction was still slower due to the fact that Fixed32 is developed to use the integer addition and subtraction operators with no other processing.

These were the preconceptions that I had when developing my own test. The problem that was hanging me up was that I was seeing better performance out of the float’s add and subtract operators than the Fixed32’s use of the integer operators. I couldn’t figure out how this could be. Look how simple this code is, what could I be doing wrong?

    public class TestConstants {
        // ...
        public final static int X_MUL_DIV_VALUE = Fixed32.parseFixed32("1.84");
    }

    public class Fixed32Add extends CodeBlock {
        // ...
        public void run() {
            int xResult = 0;
            for(int i = 0; i &lt; TestConstants.NUM_OPERATIONS; i++) {
                xResult += TestConstants.ADD_VALUE_X;
            }
        }
    }

So I decided to expand the test and cover arithmetic with all native numerical types, the additional types being byte, short, long, and double. Once I did that, it became clear what the problem was. Without Fixed32 being involved, the integer addition/subtraction operators were about 3 times faster than the floating point operator.

There was a sneaky little issue that is nearly impossible to see if you’re not looking for it. Here’s the code change first:

    public class TestConstants {
        // ...
        public final static int X_MUL_DIV_VALUE = Fixed32.parseFixed32("1.84");
    }

    public class Fixed32Add extends CodeBlock {
        // ...
        public void run() {
            int xResult = 0;
            int value = TestConstants.ADD_VALUE_X;
            for(int i = 0; i &lt; TestConstants.NUM_OPERATIONS; i++) {
                xResult += value;
            }
        }
    }

The compiler handles the final variables, replacing each reference to the final variable with the code on the right of the declaration, resulting in the parse function being called for every iteration of the loop. As I said, sneaky. It’s something to be aware of when declaring final variables. If you have a native value, the inline processing performed on final variables can be quite beneficial. However, with objects and function calls to generate the value of the final variable, it can result in additional processing and memory that hides behind a mask that makes it hard to see. Just keep it in mind.

Anyway, below are the result tables, one for each device (Curve, Bold and Storm, NUM_OPERATIONS = 5000). As stated at the beginning, float multiplication/division is faster than Fixed32 multiplication/division.

BlackBerry Curve 8320

Variable Type	Add/Sub (ms)	Mult (ms)	Div (ms)
Fixed32	204	1372	1788
float	700	548	1184
double	1104	824	4376
long	260	260	528
int	196	200	248
short	240	220	272
byte	220	232	272

BlackBerry Bold

Variable Type	Add/Sub (ms)	Mult (ms)	Div (ms)
Fixed32	153	597	776
float	317	242	550
double	514	366	1931
long	114	117	225
int	96	90	114
short	102	102	125
byte	104	107	127

BlackBerry Storm

Variable Type	Add/Sub (ms)	Mult (ms)	Div (ms)
Fixed32	135	863	1089
float	379	293	694
double	599	420	2424
long	150	155	284
int	131	137	162
short	150	150	170
byte	146	144	172

To conclude, make conscious choices about which variable types are right for your arithmetic needs. If you plan to do a lot of addition and subtraction with fractional outcomes, the Fixed32 class may still be your best bet (if accuracy is not all that important). However, you’re better off using native floats with multiplication and division. Finally, be careful with final variables. They’re built in a way to cause problems and hide inefficiencies if care isn’t taken.

BlackBerry Java - Avoid String Concat

2009-04-16T00:00:00-04:00

To better my knowledge of the BlackBerry platform and its implementation of Java, as well as to share some useful information on Blurry Words, I’ve setup this sub-category of Mobile Development. Deem yourself introduced to the BlackBerry Java category. Though the name is a general blanket to anything I might be interested in covering for the platform, don’t consider this category a good place to learn the basics. This is in no way an introductory tutorial, more of a study into what works best with the BlackBerry implementation of Java. There are plenty of great sources out there to get you started, I don’t see a need for me to add to that. If you are here looking for a starting point to BlackBerry development though, check out the official BlackBerry Developer Site. It’s full of tutorials and example code, everything you need to get going.

Also, for full disclosure, I’m a software developer at Research In Motion. I’ve been with the company for about 6 months at the time of writing this post (though I’ve been working in mobile development for nearly five years now). All the development and experimentation that I do in order to provide hard data with my posts is done using only the external development tools provided by RIM. Blurry Words related activities are performed from a personal laptop dedicated to the content of the blog. This is done in order to avoid any cross contamination between RIM’s internal development tools/knowledge and what is provided to the public.

With that, let’s get into the topic of this inaugural post, avoiding String concatenation. String concats are usually one of the core parts of an application. Every app needs to collect information and provide it back to the user, which in most cases is impossible to do in a meaningful way without being able to concatenate strings. The BlackBerry Java implementation has a few different ways of accomplishing this task; the String operators + and +=, the String.concat() function,and using StringBuffer.append() to build the string before converting it to a String object (StringBuilder, which basically made StringBuffer obsolete as part of J2SE 1.5, is not part of J2ME or the BlackBerry version of Java).

The question to answer is which method is best from an optimization point of view? Without benchmarking, most Java developers already know the answer. The StringBuffer class exists for a reason. As String’s mutable side kick, StringBuffer exists to perform string manipulation with streamlined memory allocation, something immutable objects like String can’t accomplish. Don’t misunderstand, immutable objects are highly preferable, where mutable objects should be minimized due to their difficulty to implement and possibilities for abuse, as described in Joshua Bloch’s Effective Java:

Immutable classes are easier to design, implement, and use than mutable classes. They are less prone to error and are more secure…Classes should be immutable unless there’s a very good reason to make them mutable. Immutable classes provide many advantages, and their only disadvantage is the potential for performance problems under certain circumstances.

He goes on to say that small value objects should always be immutable and that bigger valued objects, or any object that may require multistep operations, like String, should be immutable with a mutable companion class to perform the operations. The reason for this is that an immutable object can never be altered. So, at each step of an operation a new object would need to be created, leaving the possibility for large amounts of garbage and as a result, degraded performance. The immutable sidekick should be developed to provide the same results without having the memory creation overhead. Hence the String and StringBuffer partnership, a perfect pair to test and provide hard proof of the goodness of this development approach. Here’s the code that was used to test each method.

String += Operator:

    private String strcatTest() {
        String test = "";
        for(int i = 0; i &lt; StrcatSettings.NUM_CONCATS; i++) {
            test += StrcatSettings.CONCAT_STRING;
            test += StrcatSettings.CONCAT_STRING;
            test += StrcatSettings.CONCAT_STRING;
            test += StrcatSettings.CONCAT_STRING;
            test += StrcatSettings.CONCAT_STRING;
        }
        return test;
    }

String.concat(String):

    private String strcatTest() {
        String test = "";
        for(int i = 0; i &lt; StrcatSettings.NUM_CONCATS; i++) {
            test = test.concat(StrcatSettings.CONCAT_STRING);
            test = test.concat(StrcatSettings.CONCAT_STRING);
            test = test.concat(StrcatSettings.CONCAT_STRING);
            test = test.concat(StrcatSettings.CONCAT_STRING);
            test = test.concat(StrcatSettings.CONCAT_STRING);
        }
        return test;
    }

StringBuffer.append():

    private String strcatTest() {
        StringBuffer sb = new StringBuffer();
        for(int i = 0; i &lt; StrcatSettings.NUM_CONCATS; i++) {
            sb.append(StrcatSettings.CONCAT_STRING);
            sb.append(StrcatSettings.CONCAT_STRING);
            sb.append(StrcatSettings.CONCAT_STRING);
            sb.append(StrcatSettings.CONCAT_STRING);
            sb.append(StrcatSettings.CONCAT_STRING);
        }
        return sb.toString();
    }

In order to benchmark these functions, each was implemented in its own class extending CodeBlock, an abstract class I created that provides one method, called run(), to be overridden. The code that you want to test/benchmark should be implemented within/through run(). Then all the different implementations are registered within a separate class called ComparisonTest, which wraps calls of each version of run() inside of benchmark timing code. I don’t get fancy with the timing, just the wall clock approach.

The tests are then run on a few different BlackBerry devices to 1) see how the devices compare, and 2) to make sure the results match in separate environments. I also use this code to obtain memory allocation and code size statistics. I use the BlackBerry JDE’s memory profile for allocations statistics and an application called jclasslib bytecode viewer to see how much bytecode was generated by the different tests.

Timing Results

As expected, StringBuffer lived up to the expectations laid upon it earlier in the post. Below shows the timing results collected on three different BlackBerrys, the Curve 8320, the Bold and the Storm. Using StringBuffer to append each String first and then creating and returning a String object at the very end of all the processing resulted in a significant performance improvement over either of the String methods.

Test	Curve 8320(ms)	Bold(ms)	Storm(ms)
String +=	37196	2658	5829
String.concat()	13116	1376	2801
StringBuffer.append()	312	89	119

These results show the cumulative runtime time of 10 runs of concatenating the string, “String Concatenation Comparison Testn” 500 times. It’s a hard test to get an accurate idea of what is going on though as so much garbage is created that you can’t be sure what is going on with the garbage collector during any run. I do request the garbage collector be run and yield the thread before each test, but there is still no way to be sure it doesn’t get fired off during the test. Here are some results from 100 runs of 50 concatenations.

Test	Curve 8320(ms)	Bold(ms)	Storm(ms)
String +=	5312	844	1471
String.concat()	1324	185	339
StringBuffer.append()	388	98	131

What you can take from this is that as the String objects grow in size, the performance of the String concatenation operator and function gets progressively worse, an expected result considering larger and larger String objects will be created each time. At the same time, the StringBuffer’s append method’s performance remains comparable in both test cases.

Memory and Garbage

As mentioned above, what’s really slowing down the += operator and the String.concat() function is the fact that a new objects must be created for each concatenation in order for the String object to be immutable. The StringBuffer isn’t constrained by these rules. The only time additional objects need to be created during the StringBuffer appending process is when the byte array that stores all the characters needs to be expanded. This process results in a new, larger byte array being created, the content of the original array being copied into the new array and the original array becoming garbage. I note this as you can avoid this reallocation by providing a good guess to exactly how many characters you will be appending during the process. That way the amount of reallocating that is needed for the byte array is cut down, possibly completely removed from the process.

Before discussing further, lets look at the memory results. This is one run of each test, performing only 50 concatenations during the run. The table shows the number of objects created during the processing and how many bytes were needed in total for all the created objects. Note, there might have been other objects created during the test. However, I focused just on String, StringBuffer and byte[] as those are the main objects being created relating to concatenation.

Test	Objects Created	Memory Used (bytes)
String +=	308 Objects (String: 106, StringBuffer: 51, byte\[\]: 151)	406,524 bytes (String: 60,392, StringBuffer: 1960, byte\[\]: 344,172)
String.concat()	110 Objects (String: 110, StringBuffer: 0, byte\[\]: 0)	48,500 bytes (String: 48,500, StringBuffer:0, byte\[\]: 0)
StringBuffer.append()	14 Object (String: 3, StringBuffer: 1, byte\[\]: 10)	7,268 bytes (String: 1,376, StringBuffer: 20, byte\[\]: 5,872)

The first thing I found interesting about these results, which you may have expected looking at the timing results, is that the String concat() function and the String concat operator are implemented differently. The += and the + actually use a StringBuffer to perform their concatenations, resulting in a ton of StringBuffer and byte[] garbage. The concat function avoids using the StringBuffer (though I’m note sure how it accomplishes this) and avoids all the extra overhead of allocating a new instance of it every time, easily responsible for its better performance. Nevertheless, neither compares with creating 14 objects and only 7200 bytes of data during the processing, which is what we get from the StringBuffer.append() method.

One final note on the memory allocation for both of the String class concatenation methods. Both created a blank String object for each concatenation. I don’t know what it is used for, but it is just another piece of garbage cluttering up the heap that doesn’t exist when using the StringBuffer’s append function.

Application Size

Finally, just as frosting on the cake, using the StringBuffer to do the concatenation actually results in a smaller bytecode size. Well, at least compared to the += String operator, which results in 119 bytes worth of bytecode. The StringBuffer.append implementation shown above results in only 62 bytes of bytecode. The String.concat() implementation results in 54 bytes of bytecode, but we can match that by chaining StringBuffer.append() calls together, as seen below:

    private String strcatTest() {
        StringBuffer sb = new StringBuffer();
        for(int i = 0; i &lt; StrcatSettings.NUM_CONCATS; i++) {
            sb.append(StrcatSettings.CONCAT_STRING).
               append(StrcatSettings.CONCAT_STRING).
               append(StrcatSettings.CONCAT_STRING).
               append(StrcatSettings.CONCAT_STRING).
               append(StrcatSettings.CONCAT_STRING);
        }
        return sb.toString();
    }

This results in 54 bytes of bytecode as it avoids the local variable sb from having to be loaded for each append. Each load results in two extra bytecodes, one to load the variable and the other to pop it once its processing is complete. From a timing standpoint the chained implementation is nearly identical to the default implementation, though it was consistently about 2-5 milliseconds slower.

Conclusion

Though immutable objects should be used whenever possible, sometimes the loss of performance is just not acceptable. However, that doesn’t mean to shy away from immutable classes, only to partner them with a mutable sidekick to do all the dirty work when improved performance is required. Finally, in a mobile environment, creating objects should be avoided at all cost. It’s an expensive task that is felt in everything from the battery consumed to the responsiveness perceived by the user. String is a nasty way of ramping up the amount of objects being created by your app. Avoid its functionality. Just remember, StringBuffer is there for a reason…use it.