Finishing DotaGrid

Let’s start off similar to Finishing BattleTop, with the elevator pitch that I would have created for DotaGrid at the start:

I’m hacking a web app together to quickly create a well-aligned grid of heroes for the picking-stage at the start of a Dota 2 match, so I have something to use while dota2layout.com is down.

There’s a few important things to note here:

  • “hacking”: Yes, this is throwaway code, even though it’s open sourceHeck, the main code files are called myMonolithicApp.js and tempHeroesJson.js.
  • “well-aligned”: I prefer my hero layout to be aligned to a grid with some very minor spacing between items. I.e. there’s no option to turn off “snap to grid”.
  • Dota 2“: Yes, this entire pitch and the tool itself assume you know and play Dota 2. Or that you know me personally and are willing to struggle through the Dota 2 specifics of this post.
  • so I have something“: The key word being “I”. Even though I’ve shared the app and its source, it was mainly something I created to satisfy my own need.

That last point is really rather important here, and it greatly affects the way I want to “wrap up” this project. But before I talk about that, let’s first look at something that seems to be in big contrast with this point.

Reddit

Even though my first ever Reddit post was well-received, Reddit has always felt as a moderately hostile environment. Depending on the particular subreddit, folks can be rather harsh and direct, not always in a well-founded fashion. But there was only one way to test that assumption and face my public-reddit-humiliation-fear: by posting something. I felt my DotaGrid tool was decent enough to be of some use to others as well, so I decided to post it on Reddit. Here’s a screenshot of my post:

DotaGrid Reddit post

This got me some decent votes and upvote percentage…

DotaGrid post Reddit vote count

…some friendly remarks…

DotaGrid friendly Reddit comment

…some suggestions…

DotaGrid add techies comment

…and some low-on-details bug reports…

DotaGrid bug report without info

…but in any case, overall comments felt friendly. So even though I wrote the tool for my personal use, deciding to share it seems like a good idea in hindsight.

The Code

Looking at the code now, a few months after I wrote the tool, I must say I’m not too disappointed. Sure, it’s “hacked together”, and according to Feather’s definition it’s legacy code, as it doesn’t contain unit tests. However, the code’s structured well enough to add those after all and work from there. For example, have a look at this typical view model property:

Not quite great code, especially that final (rather frail) line of code, but at least it’s concise, clear, and potentially unit testable.

If I were to rewrite the tool I do think I’d need to separate things a bit more. Especially the fact that the internal grid model (which hero sits where) and the rendering bit should be decoupled. This would also be necessary if I were to create a more responsive version that possibly doesn’t use a table for layouting the grid (but either a canvas or a div instead).

Then again, I’m not rewriting the tool. Instead, I think I’m going to wrap it up by:

  • Putting a disclaimer on the Google Code project, the app itself, and the Reddit post;
  • Annotating a few bits of the code, should I or anyone else care to continue the thing;
  • Keeping it up to date with new heroes as they come out, but only for as long as I feel like it (which highly depends on the amount of Dota I’ll play).

That last point does remind me to make one confession: I did not anticipate too well what would be needed to add heroes to the app. I feel rather dumb about that, since my tool is a direct response to the fact that dota2layout.com broke precisely for that reason. But oh well, you can’t win ’em all.

In conclusion

So in any case, that’s how I’m going to wrap it up, effectively “closing down” this project. Which clears the way for me to reboot and start finishing my final “open” project…

Finishing TimeLine

Oh my, that code… where to begin!?

Before you read on, perhaps you should have a 30 sec look at what I’m talking about. I’ll wait here, go ahead!

Current thoughts about this project

TimeLine’s at prototype status, but hopefully it’s clear what the app was meant for: visualizing experience over time, using grouped, parallel timelines.

I look back at this mini-project, and directly notice a few things. First and foremost: I still like the idea of such an app! Visualizing work experience is great for a résumé I think, it allows the reader to instantly get a “feel” for what you’ve been working on. Much better than dreary text.

The second thing I realize is that I clearly had no idea and/or time to quickly scaffold an editor (“yes”, I thus resorted to using a textarea with JSON; so sue me!). Today I’d use KnockoutJS for this, even in a mockup. Or, barring KO, I’d use some other plugin for it. But then again: “first make it work, then make it work better”, so I’m happy I chose something and moved on.

The final thing I realized: it’s a decent prototype, and to get there I sacrificed a lot of code quality. With 140 SLOC it’s not much code, but what’s there is rather bad.

Finishing things

This leaves me a bit in a tight spot. What am I to do with this project?

First I thought about deleting the thing entirely, praying no one would ever find out about the JavaScrippaghetti I had unleashed on the world. Then again, that would be silly: everyone needs to write a fair share of bad code to get better at writing code.

My second thought was to rewrite the thing from scratch: right here, right now. Nearly started working on it too. Guess I wasn’t lying when I said I still like the idea. Then again, that would be silly: I still have two other projects left to “wrap up”, one of which is much more deserving of my time.

My third and final thought was to wrap up by doing a loose “code review” of my own code. In addition it feels good to “stamp” it with a disclaimer and message that it’s “wrapped up”. And that actually seems like the best idea.

Code review

The html is not really worth going through. It’s a plain html-reset-based file, that uses semantic markup (header, nav, article, etc), and has a placeholder div where Raphaël will draw the timelines. The html contains a link to timeline.js, and some basic bootstrapping code to call timeline jQuery-plugin-style on the placeholder div.

Let’s dive into that one code file. It’s starts off with some good signs:

Apparently the code’s being linted with a more sane version of Crockford’s jslint, and the code declares ES5 “strict mode”. Guess the author did forget to run the linter recently, because currently it seems to still cause a few errors. Anyways, moving on we see:

Not exactly globals, but a definite hint the author’s struggling with JavaScript closures. Except for paperPadding perhaps, which hints at a feature for settings that’s just not implemented yet.

Moving on the code follows a typical jQuery plugin template, first with all the plugin’s methods defined within a seperate closure, then at the end of the file exported in a typical fashion:

What you can already see here though is that the plugin relies on one single god method: init. This method in itself isn’t all too interesting. It just loops through the grouped timelines, and renders them one by one. To find some things that are of note I went through a mix of Dutch and English comments (not a good thing for something intended to be public). Here’s one that’s particularly interesting:

Phew, at least the author realized the code could not go on like this for much longer. This is further clarified by the presence of this kind of code (abbreviated):

Yikes! The break statement is IMHO often a code smell (smells of goto), surely there’s an OO-approach for the problem being solved here.

Let’s finish on a positive note though, having a look at some of the variable names in use:

  • categoryHighway
  • lane
  • segment

This makes me smile. Having the UI of the app in mind I instantly know what these mean. A segment is one piece of timeline, a lane is a horizontal area where segments can be placed, and a catgory highway is a set of lanes for segments from one category. Close-reading the code I find this is in fact mostly correct. And with that I feel there’s a great OO (or more prototypical) way to reboot the code for this app.

In Conclusion

In conclusion, or perhaps more appropriately “in summary”, I can say this is a fine and above-all inspiring prototype. The code’s short and bad, but not even that bad for a quick prototype.

With a proper disclaimer and “wrap up” message I feel can safely leave TimeLine be for now. Perhaps one day I’ll revisit it.

Finishing BattleTop

Okay, the title is about as uninspired as topping a vanilla ice cream dessert with chocolate sauce. But it’s to the point! Also, with slight OCD, it’s nice that my archives will show nicely aligned “Finishing …” titles. This is important for many reasons!

BattleTop ThumbnailAnyhow, as I’ve announced recently, I had already finished wrapped up one project: BattleTop. Have a peek at the Source, or check out the Live Version.

Elevator Pitch

What would’ve been the Elevator Pitch if I had made one when I started? Something like this:

I’m developing an app for keeping combat initiative so tabletop RPG groups can skip the tedious parts and share the initiative state easily, using (mobile) devices that are present in sessions anyways.

Writing elevator pitches is far from my specialty, perhaps I should’ve said something about “the competition” too: I’ve actually looked for existing apps, and tried a few from the Android Play Store. Only a few existed at the time, and they were very unsatisfactory.

What’s it built with?

I’ll be honest: from the subset of suitable technologies, I didn’t choose based on “best for the job”. Instead, I chose two technologies that I wanted to learn more about, and stayed in my comfort zone when choosing the rest.

The initial prototype was built with:

  • Html5, because at the time I loved tinkering with the new semantic tags. Also, I intended to learn all about tinker with LocalStorage for saving state between (possibly accidental) page refreshes.
  • Custom CSS, because it’s “good enough” for a prototype, and switching to SASS or LESS later on is easy.
  • jQuery, because I thought I wanted to learn how to write jQuery plugins.

Only two days / 11 commits after I had started did I branch off to rewrite things MVVM style with KnockoutJS. I’ve not looked back since. It also paved the way for easy unit testing, allowing me to experiment with QUnit.

How’s it wrapped up?

The frequency with which our group did RPG sessions had dropped dramatically. This removes the need to have a tool, the motivation to keep developing it, and the ability to test it. And this is okay with me. I learned some cool new things, and heck: it even got it to a functional beta version.

To wrap it up I just reviewed all of my code. Unit tests had already been done in August, and even though the code isn’t the fanciest ever, it didn’t have any obvious loose ends or idiotic bugs. So after some minor changes I just added a “discontinued” warning to the code, the live version, and the project site, and that’s that: closure!

Any future for BattleTop?

Not very likely. I think I prefer to focus effort on one certain other project, and after that probably even start new projects before picking up BattleTop again.

But like I said: I’m okay with that.

Finishing Things

Nearly without exception have I used Title Case in my post titles. This time though, it’s more appropriate than ever. The “Things” I speak of are my “open” Projects. Unfinished things that feel Big, but that can either be small, or at least be done in small pieces.

Yes, you’ve guessed correctly, I’ve made my choice: I’m going to finish and/or wrap up loose ends.

You know what? I’ve already started. In fact, I’ve already wrapped up the first project, which probably means that I’ll write (after months of silence) a third post in one week.

Projects to Wrap Up

But let’s not get ahead of myself. The set of projects I want to wrap up is this subset of projects you can find on my www:

  • BattleTop. My RPG initiative app. Reached fully-functional beta status. However, with less and less Table Top RPG sessions, it’s hard to fully test and further develop the app. Gonna Wrap It Up!
  • TimeLine. An app to visualize grouped timelines, though in honesty a personal playground for new html5 semantic elements. Did not get past prototype status. Gonna Wrap It Up!
  • DotaGrid. A pragmatic tool hacked together to customize the Dota 2 hero picker. Reached beta status, but wasn’t really meant to go beyond that anyways: heck, the code is grouped in a file called “MyMonolithicApp.js”. Gonna Wrap It Up, though I might update it occasionally with new heroes if I feel like it.
  • Bieb. A somewhat bigger project to create a website showcasing books you have in your own library. Not even in alpha status yet, will have to see how I will Wrap It Up…

That’s it! I’m looking forward to wrapping those projects up. Hopefully it’ll give me some closure, and by side effect some energy to start new projects!

Stay tuned for the first wrap-up-post.

So much to do

So much to do, yet so little time.  Three weeks of vacation have come and gone. Two weeks of work have come and gone. One of those work weeks was even a week #OffsiteCoding, where we went to a great (I’d dare even say luxuruous) location with the whole IT team, to work (dedicated) on a new part of our product.

New computer desk at homeAfter those five summer weeks I’m still full of inspiration, and deep into several projects and new hobbies. If I fail to post on my blog, rest easy knowing I’ll be enjoying myself with:

  • Guild Wars 2, also known as World of Warcraft 2.0;
  • The Mists of Pandaria expansion for World of Warcraft;
  • Our brand new Open Source project Bieb (on CodePlex), which is now public (yay!), but still needs a release (boo!);
  • Studying for my 70-513 exam on WCF;
  • Cranking up my skills with WPF, which I’ll be using at work a bit more the coming months.

Much of my inspiration for new projects comes from finishing other projects. Have a look at the picture for the most recently finished project: a custom (home) made desk for two workplaces at home.

Problem with this approach for getting inspired: every finished project gives me inspiration for two more! Like I said: so much to do, yet so little time. A luxury problem, I suppose.