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 Things – Intermezzo part 2 of 2

So, like I wrote, Google is “bidding farewell to Google Code“. So my recently “wrapped” up projects needed some post-wrapping-wrap-up (you still with me?!). I’m using this as a good excuse to partially move from Mercurial to Git, because I suspect Google Code’s export to GitHub is probably the migration path they’ve put most effort in.

So, here’s my first (active) day at GitHub:

GitHub Contributions

I’m a little afraid that -given GitHub’s popularity- many will see this and consider it to be my current status on code hosting services (disregarding commits to those repo’s being done over a larger time span, and disregarding activity on CodePlex). However -given GitHub’s popularity- I guess my GitHub activity will increase anyways over the coming years.

As a related side note: moving projects from Google Code to GitHub was extremely easy. The web-based tool required nothing besides a link to my Google Code project, and me authorizing Google Code in GitHub through OAuth. The only downsides I personally found during this automated conversion:

  1. My old commits in the migrated GitHub repo’s don’t get attributed to my GitHub account, because the user details were different. Also, apparently TortoiseHg “helped” me commit unwittingly as “jeroenheijmans <jeroenheijmans@localhost>”. I guess if I’d payed attention I (sh/w)ould’ve at least used a valid e-mail address. (Yes, given that probably no one has cloned my repo’s (yet) I could probably rewrite history to change this, but it’s not that big a deal I guess…)
  2. My repository includes some Mercurial-specific files, i.e. a .hgignore file. I might’ve stripped that if I had done the Hg-Git conversion manually.
  3. The project home page from Google Code was not automatically added as a README.md file in the GitHub repo. I think that would’ve been nice. Then again, this omission gave me a chance to check out Git(Hub).

And so my move to Git(Hub) begins. I’ve already enjoyed reading through other people’s thoughts on (Git) commit messages, had my first dealings with Atlassian SourceTree, as well as a combination of the two. You’d almost wonder how I got the actual migration done at all.

I feel excited about getting to know more about SourceTree, Git, and GitHub. However, I’m also still very determined to finish Bieb, which will remain on CodePlex. We’ll see how that plays out in the coming weeks / months. Stay tuned.

CodePlex Hg Hosting

This is a follow-up to my previous post on Hg Hosting Providers. I found that on the surface all four of them were very similar. From the four providers I investigated, CodePlex overall felt most intriguing, so I decided to start by trying out that one.

Note: I participate in another project, which I will be uploading to Bitbucket (because that’s the only one that supports small private projects at no charge), so I may be doing a follow-up on that provider too.

Sign Up and Project Creation

The CodePlex home page lures you into creating a project with a big, purple, Metro-style button:

CodePlex Step 1 - Create Project Button
Step 1 – Create Project Button

When you hit the button you’ll be asked to either sign in or register:

CodePlex Step 2 - Sign in
Step 2 – Sign in

If you don’t have an account yet (like I did) you can register for one on the spot. I decided to create an account linked to my Windows Live ID:

CodePlex Step 3 - Register
Step 3 – Register

The hardest part is the Captcha: damn those things can be a challenge! After finally completing this mini-game, it turned out CodePlex had forgotton all about my intention to “Create a Project”, and instead presented me with my personal (and very empty) project home page:

CodePlex Step 4 - Account page
Step 4 – Account page

Luckily, there’s another (though less obvious) “Create a Project” link on the page. There’s only a small number of fields you have to complete:

CodePlex Step 5 - Create Project
Step 5 – Create Project

The whole point for me was to choose Mercurial hosting, but it’s noteworthy that both TFS (which also supports SVN clients) and Git are an option too. Hit “Create” and if all goes well you’ll be directed to the brand new project’s home page:

CodePlex Step 6 - New Project Overview
Step 6 – New Project Overview

The project has now entered the “Setup Period”. This gives you 30 days to set up the project, i.e. before you have to go live. This was in fact a welcome surprise to me, because since this was my first time coordinating a hosted project the setup period allows me to calmly check out all the features.

Importing the Existing Repository

Keeping in mind that eventually I would be hosting the code online, I had already started with a Hg repository, committing my changes locally. There are several advantages to using version control while still flying solo, amongst others having backups and traceability.

I already suspected it wouldn’t be too hard to merge an existing repository into a new hosted project, and I even got some response to my question on Twitter, indicating it should be possible. The only thing I was worried about is that the username for commits would be “wrong”, because my computer user name “Jeroen” is different from my new CodePlex user name “jeroenheijmans”. To get everything to work I took the following steps:

  1. A simple copy/paste back-up of the existing repository, just to be safe.
  2. With some effort I got this Hg convert trick to work, changing the user name in commits for the existing repository to my CodePlex username.
  3. Make a clone (a.k.a. check out) of the project repository from CodePlex to a new local folder.
  4. Copy the existing repository over the clone from CodePlex.
  5. Some of the hidden files in the .hg folder have to be overwritten. I double checked all files with Notepad++, and in all (my!) cases the clone’s file could be safely overwritten.
  6. Using TortoiseHg I now pushed all the changes. In the previous step the CodePlex URL was probably lost, but that was easily remedied by entering it once more.

To be honest, in hindsight I don’t know if step 4 and 5 are really necessary. I guess you could safely try just pushing your existing repo to CodePlex: if it doesn’t work surely you’ll get an explanatory error message?

Either way, after completing the above steps my CodePlex project contained a complete history of 40+ commits, only minutes after setting up the project!

CodePlex Features Overview

After importing the source code it was time to investigate the various CodePlex features. Given the 30 day setup period I was able to check out all the features without having to worry others may see my silly mistakes. Here’s my first impression of the available features:

  • Home is the first thing you see if you go to the project URL (which is a nice subdomain of CodePlex: http://yourproject.codeplex.com). It mainly contains some text to explain what the project is all about, and you’re invited to edit it (with Wiki-style markup). Worked nice and easy for my simplistic purposes.
  • Downloads is the section where you can offer releases, which can have various properties as well as attachments such as binaries or installers. So far I’ve only created two “Planned Releases”, which worked pretty straightforward.
  • Documentation is Wiki-based. So far I’m headed straight for the quintessential documentation pitfall: I’ll create it once the product’s finished.
  • Discussions looks like a forum-based commenting area. Given that the project is one we do together with friends we may not get to use this option much.
  • Issue Tracker is a very basic work-item system. It contains the bare essentials, but not much more. This was a bit disappointing to be honest, I would at least have liked to have some basic formatting, but apparently that’s still a work item on CodePlex itself.
  • Source Code is the section where… well… you can find the source code! It shows all commits in descending order, and even though I haven’t tried it yet it also shows forks and pull requests. If you click on a commit you get to see the diffs for changed files.
  • People shows all the coordinators, developers and editors on the project. It’s also the place to invite your team mates to the party!
  • License is where you can view and change the license for your project. CodePlex allows you to choose from ten different OSI licenses. I’m leaning towards picking the BSD license, but this license stuff feels like a snake pit (with it’s own acronym: IANAL).

So far this list of features seems pretty sufficient. At least: I haven’t “missed” a feature so far.

Conclusions

All together I’m pleasantly surprised by how easy it was to set all this up. I’m not sure (yet) how it actually compares to the other hosting providers I considered, but so far I’m happy I chose CodePlex.

I’m fairly certain our project will be published some time soon, and when it does you can find it at bieb.codeplex.com: join the party!

Comparing Hg Code Hosting Providers

Mercury ElementMost usually, I’m a very organized person. Even before I was programming (when I was making Hero Quest maps in Q&A and WordPerfect) I would still want periodic backups of my data. Given all that, I’ve remained remarkably oblivious of Version Control for quite a long time. Here’s an overview of my VCS history:

  • 1990 – 1992 Derp derp, playing Commander Keen and friends.
  • 1992 – 2003 Copy-paste-style backups, periodically.
  • 2003 – 2005 Visual Sourcesafe. The horror…
  • 2005 – current SVN and TortoiseSVN. Much better!
  • 2011 – current Mercurial (with TortoiseHg), and a dash of Git.

On a coding project with friends, one of them suggested we’d use one of the DCVS systems: either Hg or Git. After a short debate (and after reading endless flamewars between the two) we decided on trying Hg. My “re-education” started with reading the HgInit tutorial by Joel Spolsky. Here’s a quote that stuck with me:

It turns out that if you’ve been using Subversion, your brain is a little bit, um, how can I say this politely? You’re brain damaged. No, that’s not polite. You need a little re-education.

True as it is.

To be honest though: I still don’t mind using SVN. At work we have an existing repository from which we’ll probably not be switching, and it even has some advantages over Hg. However, for any new project I would choose a DCVS, either Git or Hg, depending on the circumstances.

So for my latest pet project I’ve started a Hg repository as well. So far I’ve just been committing locally, using it as a backup and history mechanism. However, with friends and family joining on the project I will probably be moving the repository to an Open Source Hosting Provider. There’s a few that came to mind, and I’m currently considering four of them. Even though there’s a decent Wikipedia comparison article, I still decided to make my own comparison table with features I find interesting:

Google Code Bitbucket CodePlex SourceForge
Source Control Hg, Git, SVN Hg, Git Hg, Git, SVN, TFS Hg, Git, SVN
Issue tracker Custom JIRA Custom Custom
Wiki MoinMoin-based markdown Creole-based markdown Yes Daring Fireball-based markdown
Forum No No Yes Yes
Private projects No Yes No No
Licenses Any, single-licensed ? 10 OS licenses available Any OS license
Authentication Google Account Bitbucket account Codeplex + optional Win. Live SourceForge account
Projects 250,000+ 93,000+ 28,000+ 350,000+

Currently I’m leaning somewhat towards CodePlex, for no particular reason or rationale. Or perhaps I’ll end up trying them all before deciding. Either way, I’ll sleep another night on it, for now.