Minimal List Debut

by December 31, 2012 04:52 AM

Over the holidays I created and published a new web application - Minimal List ( From the application's about page:

Minimal List was created to solve a need my daughter and I had - a simple way to have our weekly grocery list online.

You can read the rest of the about page for more detail, but that pretty much sums it up. This post was indeed meant to introduce the app, but more than that, I wanted to talk about the geekier details of the project :).

When my daughter and I decided we needed (yes, needed!) this application, we knew that a mobile application was in order because one of the primary places we'd be using it is at the grocery store - to check off items as we put them in the cart of course. Well, anyone who knows me well knows I'm a web guy and tend to avoid rich clients if possible. However, I don't have anything against an application that looks like it is a native mobile app. I just prefer HTML and javascript over any of the proprietary stuff for the UI. I'm obviously building on the MS stack (ASP.NET, MVC4, C#, IIS, SQL Server), but I like the UI to be a browser (usually Firefox or my phone's browser for me personally - iPhone for the daughter).

jQuery Mobile

jQuery Mobile (JQM) was created exactly for this purpose - a native mobile feeling, but served from the web. It's also something I've wanted to play with for a while now - again, if you know me you know I'm horrible at just "playing" with things in spikes and throw away code. I like putting things in production and seeing how things go in real scenarios. So finally, a legitimate reason to play :).

I was quite pleased with the development experience using JQM. In the editor, the footprint is actually quite small. Mostly simple and regular HTML elements that are just tagged with some special JQM attributes. The existence of these attributes (after including JQM css and js of course) is what causes all the magic to happen. So once I got to know which attributes to use, things started moving along rather fast because the rest is just plain web application development like I've done for years.

However, the first real test at the grocery store wasn't all that great. My daughter went to Oregon for the holidays, so I didn't get to see what it is like on an iPhone, but the performance on my Windows Phone 7 was completely crappy. I spent a lot of time standing there waiting on screens to load as I was updating my shopping list items with either price or isle information. Completely unacceptable user experience.

Other than performance though, it worked as advertised! No bugs or issues and the grocery trip experience was exactly what I was looking for (not too surprising since I designed the app specifically for the experience I was looking for).

Next Step

The next step is obvious - improve the UX. Not sure how I'll do it yet, but there are a few paths I can take.

First, part of JQM is AJAX navigation. It intercepts local links and queries for the resource AJAX-style instead of navigating away from the current page. It then takes the response and loads it into the existing DOM all fancy like so it feels more like the native experience. This also makes the UX faster because your browser doesn't have to re-run all the javascript and whatnot that happens on a full page load. However, when you navigate to a page where you've already been, it just shows the page it already has in the DOM instead of re-requesting the URI. This sounds great, but can be challenging with data-heavy pages because the data obviously isn't going to be fresh. To get by this for now, I just turned off the AJAX functionality for most of my links and form posts. So this is something I can look into - there would obviously have to be javascript watching for those page transitions so it could dynamically update the data on the page if necessary.

Second, I could take a more SPA approach - Single Page Application. I could still use JQM for the UI and page requests and whatnot. But the main feature sections would become small SPA islands and I wouldn't do any page transitions at all within the context of that feature. This might be a good time to start playing with knockout.js or something.

And of course, I could always completely abandon JQM. I've created web apps before that were careful to be a good UX even in a phone browser, but didn't look at all like a native phone app. But where's the fun in that?!

The Code

I decided to leave the code in a public repository for all to see:


Project codename named after Momo from Avatar: The Last Airbender

You'll also notice a link to the commit that created the currently released version in the footer of every page on the site. However, when things move on and you want to see it exactly the way it was as of this post, that commit is ceef281.

That's it for now. I hope you all have had an excellent holiday season.

Tags: , , ,

Toph - Early Architecture Decisions

by November 9, 2012 06:29 AM

In Another Gig Completes, I mentioned planning to start a new project to help track consulting gigs. Here I introduce you to:


Project codename named after Toph from the Avatar: The Last Airbender

As I mentioned before, this project is meant not only to help organize my consulting gigs, but also give me a public project and codebase I can point to. I also hope to use the project as blogging fodder. Speaking of which...

Early Architecture Decisions

I've spent the vast majority of my career joining existing projects. There is always that sense of "that's not the way I would have done it". Well, I finally get to do it my way! It was tempting to go crazy with it and implement everything cool I've been reading about recently - whether needed or not, I might add. In the end I decided to go with a pragmatic approach that is much more likely to be a useful example I can point to when talking to developers as I continue consulting.

Visual Studio Projects

I'm still a fan of and will continue to advocate onion architecture (some might say Hexagonal Architecture). One difference you'll find between Toph and what I normally do though, is the lack of an Infrastructure project.

There seems to be a theme going around the blogosphere that is advocating the removal of unnecessary abstractions and part of the theme has been the combining of projects. The idea is that it is perfectly possible to create an architecturally sound solution without using Visual Studio projects to enforce it. In case you're wondering how they "enforce" it, realize that Visual Studio projects won't allow circular references between two projects - whether by directly referencing each other, or indirectly (A - B - C - A would not compile). Therefore if you have a UI and a Core project with UI referencing Core, you couldn't reference UI from Core.  Thus, this usually prevents you from directly doing UI type actions from within Core since you couldn't touch the controllers or view models.

I'm almost always a fan of pragmatic programming. As it turns out, the Infrastructure project never proved that exciting for me as a standalone project. So I just created a namespace within UI called Infrastructure and dumped everything in there. You see, everything usually consider Infrastructure is generally only used during application startup anyway as I'm building up the inversion of control container.

However, I still very much like having my Core separate. It just feels right. So, I decide three projects are all we'll need in this solution

  • Toph (I decided there was no reason to call it Toph.Core)
  • Toph.UI
  • Toph.Tests

Even if I end up adding another project in the future for scheduled tasks (to be run on some application server somewhere), leaving Infrastructure under UI should still be fine. That's because I generally just invoke endpoints in the UI from those background tasks rather than directly dealing with the domain or application's database.


New projects should always be started with the latest and greatest, right? I went with ASP.NET MVC 4 of course. Specifically, I started with the Internet Application project template.

Data Access

That template starts with using a local database and using Entity Framework as its ORM of choice. As expected if you know me, I changed that use SQL Server 2012 Express and NHibernate. To do that...

  1. Delete InitializeSimpleMembershipAttribute. This is the attribute added to AccountController that ensures the database exists and is initialized. There is only one line in there that is needed: WebSecurity.InitializeDatabaseConnection.  I moved that into Application_Start
  2. Delete UsersContext. This is the EF DbContext
  3. Move UserProfile from the Models directory into the domain and kill the EF attributes
  4. Add Fluent NHibernate
  5. Do all the normal NHibernate config and mapping stuff
  6. Change your connection string
  7. Create the database with the single UserProfile table
  8. Run the application

That should do the trick.

Other notables

The only other things I added to the project were Structuremap and my personal code library RobTennyson.Common.

I also stuck with restricting domain access to a Service Layer like I usually do. One difference I thought I'd toss into the mix this time is a bit of CQS goodness (not full blown CQRS, mind you). We'll see how this turns out as the project grows.

Grabbing a copy and playing

If you're interested in playing around with this, but sure you get the code specifically from this commit: 91a19e9f8b

I'll be moving on with the project of course, but at that exact point, the project is still basically just the default template - well, juiced up a bit, but basically still has nothing to do with the real project in it yet.

Happy coding

Tags: , , , ,

July 2012 - Drowning in New Technologies

by July 22, 2012 04:14 AM

Since April (around the time of my last blog post!), I've been on a gig with a company out of Indianapolis. It's your classic big corp, big ball of mud, type of application. Nothing new to me since I've spent my entire career in corporate America and I'm pretty sure I've created a few balls of mud myself.

The cool thing about this gig, however, is the team. After some turn-over and apparently a breaking point that caused them to get much more picky about hiring decisions, the team I joined seems to be a team of rock stars. Most have figured out they can come to me with questions on just about anything code related and here's the cool thing - answering their questions is always easy. I mean, they just get things insanely fast - every single one of them! Now, I've worked with some freaky smart developers before (last team I worked with at Tyson for example), but rarely do you see a team of dozens where all of them are freaky smart. There is always a handful of laggards (no, I don't think you are one of them).

Additionally, I've gotten to learn a few new things on this gig.


I haven't become a SOLR or Lucene expert or anything, but I've had to do a couple things with SolrNet. Seems to be all that I've read about over the years. Can't say I'm enjoying this from a developer's perspective though. You see, they have all the environments setup for it, but when developing locally, the internal SOLR abstractions hit DEV instead of local. This means if you're working on UI that uses the search indexes, it sucks because your local changes obviously aren't going to show up in the indexes from the DEV database. It also means I must be connected to VPN to touch UI using SOLR.

An implementation of the gateway and/or facade patterns would take care of this nicely I think.


I'm not entirely sure how I feel about AutoMapper yet. I've heard nothing but praise about it for years now, but this is the first time I've been on a project where it is actually being used. Maybe it's the way they're using it, or maybe I just haven't seen the light yet, but at this point I'm not digging it.

Sure, it does make your controller actions much smaller. It also takes care of DRY if you're mapping between two objects in many places. But mostly I find myself constantly having to hunt down the mapping logic to figure out exactly what is being copied between the objects, or, more frequently, to find out why something is not mapping correctly. I'm sure I'll come around, but right now it seems like a mix of voodoo and magic. Most importantly, there is no "go to definition", search results is the only way to find the mapping.


This one was fun. I played briefly with Topshelf in the past as a spike - never made it to production if memory serves. This time though, we're using it to take care of the Windows service that handles all of the project's scheduled background work. The API is crazy easy and lightweight. Can't think of anything negative to say about this at all.


Holy crap this thing is cool. NSerivceBus has been on my radar for a long time - as well as Mass Transit. We had a bit of trouble with MS DTC and permissions and whatnot, but it has otherwise been nothing but goodness. I love the feeling of isolation and extremely small units of work you get when dealing with service bus architecture - each message is its own unit of work and tends to be a small one.

I think that pretty much covers it. Well, there are a couple of others (like their internal email handler/service/thingy), but I'm afraid a recruiter might see and start offering me gigs utilizing them. Kind of like the fact that you won't find assembly, C, C++, or BASIC on my resume. I don't want people knowing I know that stuff!

Tags: , , ,

Personal Code Library + NuGet

by December 20, 2011 02:05 PM

As I was getting into my next consulting gig, I found myself copying yet again all of those utility extension methods and classes I tend to pull along with me into every project I work on. Enough is enough, I thought! That and it was a great excuse to finally play with NuGet.

You see, I've been avoiding creating a personal library all this time because I didn't like the idea of having an odd dependency that I included in projects. It would have a foreign or personal sounding namespace, versioning and updating it would be a pain, and developers that came along behind me on the project would have this weird black box of random code. I wouldn't want to run into something like that on a project I joined.

Then I figured out that I could create a NuGet package that was content only. Not sure why I hadn't already put that together, but my original thought was that I would have to create a package that delivered a binary which would be referenced by the target project. Easy versioning and updating taken care of, but I'd still be left with the black box of random code. With a content only package, the actual source code from my "personal code library" actually ends up in and lives in the target project.

The final kicker was my noticing source code transformations. By using the $rootnamespace$ token, the NuGet package installer would transform the namespace declarations into whatever the target project was using. No weird or personal namespaces! Pretty much takes care of every problem I had with creating my library.

The Source

The source for my project lives on github in rtennys/Common. I know, real original name.

I set up a basic class library project and unit testing project. Not that I've done a lot of testing mind you, most of the code in the library has been in my possession for a very long time, but I plan to add tests as I modify and grow the core library.

The interesting part to me was automating the deployment into NuGet. Next to the solution file, you'll see my standard deploy.bat and deploy.proj files (if you've worked with me, you probably recognize these!). In here is where I use MSBuild to grab the current build version, copy all the source to a temp folder, replace my namespace with the $rootnamespace$ token, create the NuGet package, and finally upload the package to Very easy and very cool.

With the addition of a hotkey in Visual Studio (see here for details - I do it similar: no context menu, just a hotkey), updating my personal code in a target project is as simple as updating my library, running deploy, and then updating the package at the target. Crazy easy!

The NuGet Package

The package is called RobTennyson.Common. Installing it is as simple as running this in the Package Manager Console:

PM> Install-Package RobTennyson.Common

I don't know that I'd suggest using it since it's my junk pile and filled with my opinion on how things should be done. It's also likely to change a lot and often. But you're welcome to it if you'd like. You're also welcome to snoop around in it and tell me why I'm nuts for doing this or that (like my .Each and .F extension methods!).

Good times!

Tags: , ,

Fort Smith DNUG - SOA For The Developer

by October 10, 2011 01:00 PM

My Fort Smith DNUG presentation description:

Service Oriented Architecture has been a buzz word for a while now and gets talked about all the time. However, I see very few presentations targeting the developer and what he/she should be doing in code as an SOA advocate. In this presentation we surface an old and well known design pattern called the Gateway. When developing applications that talk to other applications (or pull data straight out of their databases!), this pattern can save your bacon at worst and at best will give you a clear and easy to see delineation between your app and external systems.

I actually burned through the presentation rather quickly and for a moment thought the whole thing was going to be a dud. And then people started opening up with comments and questions and I'd say the night turned into a huge success. Awesome group to present in front of. Thanks for the invite!

See the code I used in the presentation here.

Tags: , ,