What have you done for me lately?

Don’t worry! This is not yet another “I haven’t blogged because…” post. It’s similar though: it’s to aggregate all the cool material I’ve been producing lately instead of writing on my personal blog!

Without further ado, here’s the goodies from the past:

Oh yeah, there’s also some stuff going on in the present:

Finally, here’s some cool stuff I might possibly do in the near future:

  • I’ve worked several months in a Java/Maven/Spring project, which lures me to write about the differences between Java and C#. No promises though!
  • 2018-01-xx: excited to start on a project that uses ClojureScript, hurray for opportunities to learn stuff! Might even write about it, here or on Infi’s blog.
  • 2018-xx-xx: blog post about Top 100 Games is in progress, though no promises here!
  • 2018-xx-xx: a side project that gets sidelined a lot, I still intend to finish EmpGrid some time.

Several things on these lists I want to blog about, but I’m not ready to commit to anything yet. Stay tuned!

Learning to Linux: the Road to Becoming a Power User

Let’s first set the scene: I’m participating in an Infi study group and would have to present to colleagues about “WTF is Linux?”. Interestingly, I am a total Linux beginner, and they were ranging from intermediate to advanced skill levels. Joy!

So, what’s on the to-do list? Three things:

  1. Understand history and context of Linux;
  2. Get to know what you don’t know yet;
  3. Learn what the tools to learn more are;

Basically, I’m looking for all the things I need to get started and to keep going. Note that all this is aimed at folks that are at least to some degree a power user.

History and Context

First there was Unix, which was great, but it was closed source and not very portable. So Richard Stallman set to create a clone: GNU. However, the kernel “GNU Hurd” didn’t work out so well at the time. So Linus Torvalds wrote the Linux kernel in the 1990s, and together they now form the Operating System “GNU/Linux”, often referred to as just “Linux”. History has by now shown that GNU/Linux was far more popular than GNU/Hurd.

Before we dive into Linux itself, let’s consider its place amongst other Unix-like OSes. There are both open source ones such as Minix and FreeBSD, and closed source ones like Solaris. All of them are fully or partially compatible with “POSIX“: a standard for OSes. You can get the full picture at Wikipedia, but here’s a simpler version:

Unix-like OSes overview

Zoom in on the green “GNU/Linux” box, there turn out to be very many Distros. A distro being the Linux kernel, GNU tools, a package management system, and possibly a window system and desktop manager. Again, there’s a full picture at Wikipedia, but I made a more condensed overview:

Linux Distros Overview

The top ten distros for 2016 according to DistroWatch are as follows:

Rank Distro Package Manager Default Desktop(s) Comments
1. Mint dpkg Cinnamon, MATE, Xfce, KDE community-driven spinoff from Ubuntu with a lot of out-of-the-box multimedia stuff
2. Debian dpkg Gnome reliable Linux distro that can be used plain, but is also the ancestor for many other distributions
3. Ubuntu dpkg Unity (moving to Gnome 3) beginner-friendly spinoff from Debian, both for desktop and server environments
4. openSUSE rpm None, Gnome, KDE community program sponsored by SUSE, to promote use of Linux everywhere
5. Manjaro pacman XFCE, KDE, Gnome power and flexibility of Arch, but with a friendly installer and some more GUI stuff added
6. Fedora rpm Gnome latest and greatest features that will also go into Red Hat Enterprise Linux
7. Zorin dpkg Gnome 3 spinoff from Ubuntu for newcomers accustomed to the Windows GUI
8. elementary dpkg Pantheon spinoff from Ubuntu with the look and feel from Mac OSX with a few custom apps
9. CentOS rpm None, Gnome, KDE basically Red Hat Enterprise Linux without the enterprise license and support fees
10. Arch pacman CLI very minimalistic Linux distro, requiring the user to take control of the OS

There is also a pretty good Youtube video that gives some context about this same list.

Oh, and obviously I also have to do an honorable mention for the weirder, more “clickbaity” Linux distros: Satanic Ubuntu, Christian Ubuntu, Damn Vulnerable Linux, LinuxBBQ, Slackintosh, and Stresslinux. For the most part I have no clue what they do (if anything at all), I’ll leave that as an exercise to the reader.

What to Know

First thing to do when getting started with a new technology is finding out how much you don’t know yet. Thinking about the Dunning-Kruger effect…

Dunning-Kruger effect

… I would like to start at the Valley of Despair right away. And I’d like a clear path of that slope ahead of me. Please.

Now obviously you can’t start from zero; even reaching the Valley requires some knowledge. So investing some generic startup time seems good. Here’s a few suggestions:

But where to go from there? What is there to know? Well, there’s a few obvious resources that serve as very natural check lists:

In addition, it seemed helpful to try to do one or two nontrivial in-depth tasks in a VM, and see what you encounter. For example setting up a LAMP stack to host WordPress in a VM, or cloning a cool project and getting all dependencies (like Java, ugh!) up and running.

At the end of my research, and with help of my study-buddies, I conclude these are the few essential skills that I’m missing to be productive with Linux as a developer or sysadmin:

  1. Command Line. Without solid knowledge here you’ll feel lost for any nontrivial task in Linux. Some “introduction to Linux” articles tell you it’s not really needed (depending on the distro you choose), but I disagree, and think you’d get frustrated unless you learn to use it.
  2. SSH. Related to the Command Line, knowing how secure shell works is essential to managing a remote Linux instance (e.g. a VM in the cloud). This includes knowledge on managing SSH keys.
  3. Nano or Vim or similar. Also related to the Command Line. Often you’ll have to edit a config file from the command line, and being able to do that confidently is quite helpful.
  4. File System Hierarchy and Permissions. Knowing where to find stuff (and who has access to it) is essential to be productive. On a specific note, it seems important to know where things will be logged (e.g. where does a package install or server software keep its logs).
  5. Package Management and Installing Software (and troubleshooting that when it goes awry). Most interesting tasks on Linux require installation of libraries and software, and quite often this can go awry. You need to learn how to debug this.

My advice, at least to myself, is to sit down and carefully master these first. At least to some degree. Only then will other tasks on Linux (e.g. managing an NGINX server) not be a frustrating job anymore.

Learn to Learn

So how do you most efficiently climb this learning curve? Discoverability of essential info on Linux can be a bit of a problem. But here’s a shortlist we came up with:

  • man can be used with any other command as an argument, and it will explain all about it
  • info is GNU’s answer to man, intended to be more fully-featured (hyperlinks and such) and comprehensive
  • The “bropages” is like man but more succinct and example-based
  • locate, find, and which are commands for finding stuff on the file system
  • aptitude in Debian distros, or a similar tool for your set of distros, to help understand the package system
  • unix.stackexchange.com can be a great generic resource for Linux (and other *nix OSes)
  • https://askubuntu.com/ is quite a vibrant community should you choose to use that distro
  • LPIC (or similar) exam objectives can be a great study guide
  • read shell scripts before executing to learn
  • and as a final trick, you could do git init in a certain folder (e.g. /var/log) and use diffs to check how things change following your actions

However, perhaps unsurprisingly, the most common piece of advice when asking experts “How to learn?” is…. practice. Practice, a lot!


PS. This was cross-posted to Infi’s blog.

Pet project status report

This post assumes you’ve read my previous post on this project. It’s going to be a very short status report.

In aforementioned post I’ve tried to break through my analysis paralysis by listing all the things I had to think about (it helped!). Let me re-iterate, update, and complete the list to once again gather my thoughts:

  1.  Project and Namespace structure. KISS, so I went with just a single project (plus one for tests) for now.
  2.  Folder structure. following the lead of popular C# projects, only needing some files in the root and a src folder for the projects.
  3.  Initializing git. this was actually the biggest mental blockade. I just bursted through: screw TFS history, screw being “optimal”, and just move. I copy-pasted all code, cleaned everything carefully, and initialized the git repo with an already decently sized project.
  4.  License. MIT.
  5.  GitHub setup. Let’s start simple. Project created under our organization’s GitHub account. Pushing straight there for now, using my own personal profile. Will think about working with forks and pull requests later.
  6. NuGet packaging. Haven’t started this yet.
  7. Re-including the open sourced bits in my closed source solution. Have postponed optimizing this. The not-so-optimal solution for now is that the projects are gone from TFS, and there’s a “lib” folder instead with compiled DLLs from the open source project.
  8.  Choosing a name. Chosen, but not ready to disclose yet, even though it’s very easy to sherlock this bit.
  9. .NET Core. We’ll cross that bridge when we get there.
  10.  What am I forgetting? Looking at some of the “top” C# GitHub projects (Restsharp, NodaTime, dapper-dot-net, AutoMapper) was extremely helpful. Note to self: in-depth code reviews of those projects will be extremely educational.
  11.  Minimum quality. I actually chose to make this project an exercise in being as “clean” as possible (within -though close to the edge of- reason). But one bullet at a time, so e.g. crafting a great readme is a sub-exercise left for later.
  12. Early feedback. Still on my list, but want to get to some kind of “alpha” stage before I send out review requests.
  13. Logo. Was a great excuse to get started with the recently released GitHub Projects feature.
  14.  XML Documentation. Probably way over the top, but a nice personal exercise, so worth it after all.
  15. CI. Have not started with this yet, but know I have to at some point.
  16. GitHub Wiki. Probably way over the top, but would be a nice personal exercise to create one.
  17. Domain name. Not sure how that plays together with the license, the fact that the repo was initialized under my organization’s account, or any trademark stuff. Will have to figure that out some time soon.
  18. .NET Framework Versions. Related to the .NET Core bullet I guess, but slightly more important. I found that the popular repo’s I looked at for guidance have some kind of setup with duplicated projects several times over, not sure how that works. For now I’ll have to stick with a (unfortunately slightly older) version, 4.5.1, because that is the highest version I can use in the project that is dog-food-testing the project.

Okay, now I can stop that hurricane of thoughts, and get back to this pet project, and tick some more things off the list!

Extracting and Publishing closed bits as Open Source

There’s a project at work that’s got all the traits to serve as a great vehicle for dabbling some more with open source:

  • Small-but-not-too-small;
  • Self-contained;
  • Not too specific (e.g. to our domain);
  • Keeping the IP safe isn’t a concern since it’s just a small tool unrelated to the core business (i.e. we’ve got “the okay” to make it open source);
  • It might be of some use to someone else, and failing that it’s still fun to open source it;

While trying to start with the process of extraction and open sourcing, there seem to come up a million things to think about when going through this process. I want to gather my thoughts (by writing this post) and untangle that mental mess, so that I can get to a clear plan of attack. Perhaps this post will even be of use to someone else, somewhere.

Context

Currently, the bits I want to make open source are only slightly coupled to the bits I want to keep closed. That is: currently everything is in one solution, but the split in projects already clearly demarcates what would be open and what would remain closed. To put this in a tabular overview (where “Foo” is the closed bit, and “Bar” is the open bit):

Current Situation

Closed Source

/Foo.App
/Foo.App.Tests
/Foo.Core
/Foo.Core.Tests
/Foo.MyInstances
/Foo.ConsoleWrapper
/Foo.ServiceWrapper

Target Situation

Open Source

/src/Bar.App ???
/src/Bar.App.Tests ???
/src/Bar.Core
/src/Bar.Core.Tests
/src/Bar.ConsoleWrapper
/src/Bar.ServiceWrapper

Closed Source

/packages/Bar ???
/Foo.MyInstances

/Foo.WindowsService ???
/Foo.Console

There are some question marks in that overview. Elaborating on them a bit:

  • I’m not sure if the distinction between “Core” and “App” should remain a dll/project splitup as opposed to possibly a namespace split.
  • I’m not sure how the Open Source solution will be included in the closed source app (via NuGet, or as external source or binaries, or…?).
  • I’m not sure if I can easily distribute a generic windows service wrapper, or if I need to create it in the closed source solution after all.

In addition to these source-related questions, there are other things to think about as well. So next up:

What things to think about beforehand?

Let’s summarize all the things I can currently come up with that might be important in this process, in no particular order, merely numbered to be able to reference them easily:

  1. Project, Namespace, and DLL structure: what’s wise, what’s neat, what’s useful?
  2. Folder structure: how will the repository be structured? What’s future proof here?
  3. Initializing git: currently, the project history is in our corporate TFS. So not even sure if/how to keep the history intact, or if that’s even feasible.
  4. License: okay, that’s not too difficult, but have to choose one nonetheless.
  5. GitHub setup. What’s a good setup? Should I make the organization main owner of the repo, with a personal fork from which I do pull requests?
  6. NuGet packaging: how does this even work? As an application developer I had never had the need to learn how any of this works.
  7. Re-including the open sourced bits in my closed source solution: via NuGet, as external source, or as external binaries?
  8. Choosing a name. One which is not already in use for some software, where a domain with “normal” extension is still avaible, where the name is not taken on GitHub yet, etc.
  9. .NET Core. From my rss feeds I gather that it can be a quite fuss to make open source projects .NET Core “proof”, but it would be yet another thing to tackle while starting this whole thing off. Perhaps something for later? Or is that a grave mistake?
  10. What am I forgetting? I’ve been looking at some of the “top” C# GitHub projects (Restsharp, NodaTime, dapper-dot-net, AutoMapper) and their git history to see how they have evolved, to find out if I’m forgetting anything.
  11. Decent starting point, code-wise: I might be setting unreasonably (and unnecessarily) high standards for the initial commit, but still something to consider. What is the minimum quality I’m requiring before opening the source?
  12. Early feedback: it might be useful to get friends and colleagues to review the setup and get the first version(s) of the repository just right.
  13. Logo: yeah, this project needs the best. logo. ever!

In addition, there’s a practical point: once I split off bits to an open source project, I’ll effectively have two (source-control-wise unrelated) forks of the same code-base, until I’m ready to make my closed source solution depend on the open source bits again.

In Conclusion

After writing the above: wew! No wonder I was not getting anywhere: my mind was just wandering in circles through all of the above points. And I guess “Perfect is the enemy of Good”, or some such. Time to tick off some of the above items.

Finishing Bieb

I’m calling it. Bieb is now officially wrapped up.

I’ve accomplished the bare minimum I set out to do with Bieb, and learned a lot of extra things along the way. But motivation to continue any further has dropped to near zero. And I’m okay with that.

Fair warning: this is a long post. Consider the above to be the TLDR version, and whatever’s below as a peek into my personal notes and thoughts. Read on at your own risk!

Still here? Allright, here goes.

Conclusion

So let’s start up with a preliminary conclusion annex Table of Contents:

  • Bieb was a fun project. Now it’s “wrapped up” / abandoned.
  • Azure sucks I disliked working with Azure for a hobby project. Great tech, but that learning curve…
  • Proper errors in ASP.NET MVC are hard.
  • ASP.NET MVC is a nice framework in general though.
  • Database integration tests for NHibernate are useful and easy to set up.
  • Bieb is a successfull TDD experiment.
  • Razor is great for static content. You need nearly zero JavaScript for views.
  • Designing (the domain logic for) an entire application is fun!

You want more details you say!? You shall have them! Moving on…

Elevator Pitch

First up, the elevator pitch. There actually was something of the kind (though not in typical pitch-format) on the project home page:

Website project based on ASP.NET MVC for managing and displaying your personal book collection on the web.

At the bottom of the page, the (equally important) secondary objectives are mentioned:

  • Finding out more about Codeplex
  • Experimentation sandbox for MSSQL, ASP.NET MVC, NHibernate, Ninject, html5, css3, jQuery, and Modernizr
  • Experimentation sandbox for trying out competing and additional frameworks
  • Having this website project available for anyone who’s interested
  • Real-life events such as BBQ’s and drinks to “discuss the project”

And that was actually pretty close to what it turned out to be.

Note that Bieb is not solving a new problem, nor is it solving a problem in new ways. There’s GoodReads, which is a great site that does 90% what Bieb does and more. Bieb was not meant for us to get rich with a “next big thing”; it was meant as a fun project to toy with technology.

The Negatives

Before I get to the positive things about this project, first some negatives.

Azure is no friend of mine

Bieb had to be a replacement for a version of this app I’d hacked together in PHP. With PHP however, it’s very easy and cheap to get some hosting, and very easy to set up a deployment. With .NET, there is no such luxury. Private / shared hosting of .NET sites is expensive. The best option seemed to be Azure (as I had a MSDN subscription that comes along with some Azure credits), but Azure has a very steep learning curve compared to getting a PHP site up and running.

Put in another way: Azure feels solid, but it also feels big and “enterprisey”. There’s just so many buttons and settings and “thingies” that it feels impossible to get started. Watching tutorials doesn’t help much, because your choices are (a) a very specific 20 min tutorial that doesn’t cover all your needs or (b) watching a 6-hour Pluralsight course and still being covered only 80% of the way. Add to that the fact that it’s still under heavy development (which mostly is a good thing, but doesn’t make the learning curve any better), and you’re set up for frustration.

One particular anecdote worth mentioning is as follows:

  1. I tweeted that I found it confusing that one Azure portal redirects me to yet another Azure portal.
  2. Azure support tweets back redirecting me to MSDN forums.
  3. In the forum thread, I get redirected to yet another forum where I should post my findings.

I think I would now like to redirect Azure to a place where the sun don’t shine.

Don’t get me wrong though: I love .NET development and Windows hosting in general. Both Azure and hosting yourself are fine options for business-type projects. However, I’m deeply disappointed in using Azure and .NET for web hobby projects. It’s probably the main reason I’m abandoning wrapping up Bieb, and the main reason I’ll be focussing on other tech for hobby projects in the near future.

Great error pages with MVC are hard

A very specific “negative”, but one that annoyed me to no end. I think I’ve tried to attack this problem 5 times over, and failed every single time.

This is what I wanted to accomplish:

  • No YSODs. Ever. Making sure that if your app fails it does so elegantly is very important IMHO.
  • Proper HTTP status codes. That means 404s for non-existent static resources, MVC routes that can’t be resolved, but also “semantic” 404s for when a domain item (e.g. a “Book” or an “Author”) was not found.
  • A nice error page. That means a proper MVC page when possible, one that gives options (like a Search partial view) and relevant info. Failing that, a nice, styled static html page.
  • Proper error logging. The logging and error handling code should be unobtrusive to the business logic. If a request fails (i.e. a 500 error) it should be caught, logged, and the user should be directed to a meaningful, useful page with proper content but (again) also a proper HTTP status code.

Whenever I tried to tackle these requirements, I would fail to do so, and clicking through the online resources about this problem I would inevitably end up at Ben Foster’s blog post on this problem. That excellent post notwithstanding, I have never gotten this to work on IIS or IIS Express.

And having failed to get this working locally, I dread the thought of having to get this to work on Azure…

The Positives

There were also many positive aspects about fiddling with Bieb. Here are the main ones.

NHibernate Database Integration Tests

I continued to work on a way to run database integration tests with a unit testing framework, based off an approach we took at my previous job. Here’s what the base test fixture looks like:

The Factory has some more bootstrapping code for recreating the database schema from scratch. All this setup allows you to write this kind of test:

Which is a nice way to fix a database issue in a test-driven manner.

Currently my approach has one big flaw though: the tests are not isolated. Each test has to account for previous tests possibly having left data in the database. For the tests written so far that doesn’t matter, but it’s an accident waiting to happen nonetheless.

I see basically two solutions for this:

  1. Drop and recreate the database before each test. But that’s probably slow.
  2. Wrap each test in a transaction, and roll it back at the end. But that exludes the option of testing things that require actually committing transactions.

Truth be told, I wrote most database integration tests because I was unsure of how NHibernate would function and/or handle my mappings. And for that (i.e. learning NHibernate) the current set up worked just fine. If I were to continue with Bieb there would most likely come a time where I’d go for option 2. I think Jimmy Bogard typically advocates a similar approach.

PS. For what it’s worth, I’ve written a GitHub Gist with a minimal setup for creating NUnit+NHibernate tests, specifically geared to creating minimal repro’s to share with colleagues or on Stack Overflow.

ASP.NET MVC is a very nice framework

I quite like the kind of code you have to write to get pages to the user with MVC. Here’s an example of a Controller action in Bieb:

It’s short and to the point as it delegates the other responsibilities to (injected) dependencies like the Mapper and Repository. In addition, Razor views are also pretty easy to write. At the least, they are a breath of fresh air after WebForms.

So, if you want to create web sites with a big C# component, ASP.NET MVC is a fine choice. However, I do ponder if a more SPA-like approach (with Web API or similar + an MV* client side library) or a full-stack JavaScript solution are better choices for new web development projects…

Having said that, I’m very pleased with how Bieb was a great way to learn ASP.NET MVC.

Test-Driven Development

Bieb Code Distribution

I went to great lengths to stick to TDD development, even when things got ugly. In particular, I’ve had to learn how to deal with several awful dependencies:

  • Random
  • HttpContext
  • HtmlHelper (and all the things it drags along)

To show the length I went, here’s a summary of the Visual Studio code analysis for LoC:

  • 49% (1.564 lines of code) for unit tests
  • 8% (253 lines of code) for database tests
  • 43% (1.371 lines of code) for all the rest

Even though Lines of Code is hardly ever a good metric (it would be easy to inflate these numbers one way or the other), in this case they do reflect the actual state of the code base. Note that this does not include view code (obviously), nor does it include client side code (there isn’t nearly any; more on that later).

Looking back at the code, I’m also pretty pleased with how the tests turned out. There’s very simple, early tests like this one:

As well as tests that border on not being unit tests anymore, but serving IMHO a great purpose:

Which tests your haven’t forgotten any attributes like these:

Which is worth the fact that it’s not a “clean” AAA-style unit test, in my opinion.

Where’s the client side code!?

But wait a second: where is the JavaScript? The answer: there isn’t (nearly) any! All the custom JavaScript for Bieb is this inline bit of code:

This may seem silly anno 2015, and truth be told: it is!

Bieb was a vehicle for me to learn mostly server side tech. Most of my hobby projects, as well as the larger part of my day job includes client side programming. I’m confident I could improve Bieb (a lot) with rich client interaction, but haven’t found the need to do so (yet). I was aiming to get a 1.0 release out with mostly MVC code, and work on improved client side components after that.

One important thing to note: I was very pleased with how far you could get with just Razor in creating html. I was also pleased with how much fun it was to generate static content, which Bieb is mostly about.

The admin views of Bieb suffered most from the lack of JavaScript. The UX is bad, at times even terrible. However, with me wrapping up this project that will likely never change.

How are things wrapped up?

So, how are things wrapped up? Well:

  • You can check out bieb.azurewebsites.net, at least as long as my free Azure credits last.
  • The CodePlex Project will go into hibernation, but will remain available for as long as the wise folks at Microsoft keep it up and running.
  • Some screenshots can be found at the bottom of this post.

And that’s that. Which brings me to say something…

In conclusion

Bieb was a great learning experience. There were things (apart from aforementioned struggle with Azure) I did not really enjoy coding, including:

  • Setting up Logging. A real website needs this, but setting it up is a chore. Setting it up so that it’s unobtrusive can even make it a tricky chore.
  • Setting up a Dependency Injection Framework. DI itself can be a great help, I find that it kept my code clean and testable by default, but choosing- and learning how to use a specific DI container didn’t feel particularly interesting.
  • A proper Unit of Work pattern. It’s necessary, but certainly not my favorite bit of coding. And it probably shows in my codebase, too.

But this is vastly outweighed by the things I did enjoy coding:

  • Razor Views were fun to write.
  • Designing the Domain and its logic was fun, even though unfortunately sometimes the underlying persistance layer leaks through.
  • Project and Solution structure: fun things to think about, even though Bieb is just a small application.
  • Routing: it feels good to have nice, pretty URLs.
  • Controllers: because I did spend some time on the things I did not like, the controllers did end up looking pretty good.
  • Database structure, written through NHibernate mappings that actually is used to generate the database from code.
  • Design. Truth be told, the design is at most 49% mine, but that doesn’t make me any less proud of the end result.

Bieb was a fun project to do. I learned a lot. And even though I had many more plans, and even the start of a big backlog, it’s time to move on.

Farewell Bieb, slumber in peace!


Bieb - Home - LG View

Bieb - Book Index - LG View

Bieb - Book Details - LG View

Bieb - Book Details - XS View

Bieb - Book Edit - LG View

Bieb - Person Index - LG View

Bieb - Person Details - LG View

Bieb - Person Details - XS View

Bieb - Series Index - LG View

Bieb - Series Details - LG View

Bieb - Publisher Index - LG View

Bieb - Publisher Details - LG View

Bieb - Search - LG View

Finishing Bieb – Prelude

I will finish version 1.0 of Bieb in 2015!

But I’m getting ahead of myself.

You know that awkward feeling you get, when you’ve committed to some idea, merely by expressing it out loud or putting it in writing, and you can’t get yourself to do it? Yeah, “guilt” of some sort. I know, I get that too. I’ve had this for some time now, because I publicly stated I’d finish things.

Influence: The Psychology of Persuasion There’s a fantastic book on the subject which explains in detail how you should let rational thoughts trump previously stated intentions. I have applied this advice to my own situation, and rationally evaluated my publicly stated intention of finishing Bieb before doing anything else.

So here are the facts I gathered:

  1. I haven’t posted for 5 months, and I feel bad about that, because I’ve had ideas and things I wanted to post about.
  2. Hunting for a possible new job took a lot of time (I wasn’t even sure whether I should be looking for one), giving me a reasonable excuse not to work on a “big” pet project like Bieb.
  3. More recently, having found a new job, I’ve been spending almost all my free time studying new technologies I’ll be using soon. This is a very reasonable excuse to postpone blogging and pet projects.
  4. I’ve been tempted to start off new pet projects, but didn’t dare because I felt it would’ve been Bieb’s death sentence.
  5. The Windows Azure dashboard overwhelmed me. I want and perhaps even need to use it for rolling out Bieb, and it’s probably great, but wanting to do everything right the first time around doesn’t combine well with how extensive it is.
  6. I’m going to try out speaking at small events by giving a Lightning Talk at the next DomCode meetup, which takes away time from other hobbies like blogging and pet projects.
  7. I really, really, want to actually finish a 1.0 version of Bieb.

Okay, I was lying. Those were not “facts I gathered”. Those were thoughts, more or less chronologically ordered. And they can be summarized as:

  1. I want to give up on Bieb.
  2. I have all sorts of excuses for at least postponing it.
  3. But wait: I do not want to give up on Bieb!

So, ratio tells me: ignore wanting to give up, postpone finishing it for a reasonable while, and then finish it. Basically, I’m publicly restating my intention of finishing it, this time even attaching a deadline.

I will finish version 1.0 of Bieb in 2015!

You can hold me to that promise. I know I will.

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.