Your Data Layer Matters!

Of course it matters.  What you use for your data layer is a fundamental decision that will affect a good chunk of your application and the development workflow that your team will need to follow.  This is one of those foundational elements that I don't think developers give enough thought.  I've come across too many developers that seem to have a "favorite" data layer and subsequently force it into every project that they work on.  I'm looking at you Entity Framework lovers!

Okay, that's unfair.  It's not just the Entity Framework, and frankly it gets a bad wrap, but that's because it gets misused a lot.  However, since I brought it up I'll continue to pick on it, but I could be picking on any data layer or technology in general.

The Entity Framework has some very specific use-cases that it's very good at.  One of those is getting an application up and running from scratch with very little effort.  Since it's so easy to get up and running at the start of development, and it works really well for small projects (i.e. most developers' proof-of-concept projects), I see a lot of developers commit to this technology without fully considering the greater implications of doing so.

The Entity Framework (or similar heavyweight ORM) can actually become quite a burden as a project grows and multiple developers are making changes to the data layer in parallel.  It's great if you develop your application in horizontal slices (i.e. one developer is responsible for the entire data layer), but if you develop your application in vertical slices (i.e. one developer is responsible for a feature end-to-end) then working with a heavyweight ORM just becomes a tax on your developer's productivity.  The developers either need to identify overlap and coordinate all of their changes upfront, or deal with the nightmare that is merging EDMX files after the fact.

If you're about to start a project where you have multiple developers working concurrently and each developer is responsible for a full feature (vertical slice of your application), then a heavyweight ORM is likely going to be more trouble than it's worth.  I would urge you to consider a lightweight or dynamic data layer like Massive or Dapper.

I don't think anything I'm saying here is revolutionary or anything you likely haven't heard before.  This is really about choosing the right tool to solve the problem at hand.  I just wanted to remind you that it's not just the problem that needs to be considered; you also need to consider what the division of labor will be among your development team.  Unfortunately, that means you can't blindly use your favorite technology on every project; always pick the right tool to solve the problem at hand.

Responsive Frameworks: February 2014

Bootstrap 2.3.2 was hands down the only sane choice for a web framework 6 months ago (for the types of applications my team develops).  Now that Bootstrap 3.1.0 is out we should just be using that right?  While I believe that’s a valid assumption, the project that I'm about to start working on is a pretty big deal so let’s give the internet one more chance to tell me there’s something better.

Son of a... apparently in the last 6 months everything has changed.  Here is my new short list of frameworks:

• Bootstrap 3
• Froundation 5
• Grumby 2
• Pure CSS
• InK

Where did all of these come from?  Apparently responsive frameworks are popping up like weeds.  Alright, Bootstrap and Foundation were the main two I considered last time so let’s leave them for last.

Grumby:  I didn’t get into it too much.  It appears to be one of the more popular up-and-comers, but I still can’t find a lot of good resources.  It’s open source, not backed by a large community or company.  It’s quite possible this will become something great, but the support isn't solid enough to build our business on it.

Pure CSS: Built by Yahoo!, which is good.  Tiny and efficient.  Only a CSS framework.  Only at version 0.3.0 which is way to early to adopt; been burned before.

InK: Built as a Bootstrap replacement with a minimalist design, it’s extremely lightweight but delivers tons of features.  Large companies haven’t started using it, but smaller ones have.  It’s not quite ready for wide adoption yet, and doesn't have a large community or company backing it.  Too risky right now.

That just leaves the two big contenders from last time: Bootstrap 3 and Foundation 5.  The assumption at this point is that Bootstrap will win, so let’s see what Foundation 5 is like.  To be honest I don’t remember why I ruled it out last time, but I do remember it was easy to rule it out.

It turns out that I completely ruled out Foundation 3 and 4 without fully understanding what the framework was, all because they didn't recommend or officially support jQuery.  Instead they have their own jQuery-like framework call Zepto.  I get why I ruled them out, but I wish I wasn't so dismissive when I first looked.  Foundation 5 however, admits that jQuery is the better choice and completely dropped Zepto.  Alright, so what is Foundation 5 all about?

Apparently, Foundation 5 is pretty awesome.  Bootstrap is really a turn-key operation; pick it if you want everything to work out of the box and you plan on it feeling like a Bootstrap site.  You could change it but it would take a lot of undoing what the framework has already done for you.  Foundation on the other hand, has everything that Bootstrap offers plus all of the things I noticed were missing (e.g. business application features).  The only think it doesn't have is the sex-appeal right out of the box.  Foundation is also backed by a company that you can pay to answer support issues and apparently just helps out for free sometimes as well.  The downside of Foundation is it doesn't have a huge community like Bootstrap so you’ll get your hands dirty figuring things out, but the a lot of the Bootstrap community stuff isn't production-ready code anyway.

Researching more into the company behind Foundation, this is really a company of designers who built a framework for themselves and then released it.  Digging even more, these are guys that want to design things the “right way” and aren't pressured for features like the Bootstrap guys are.  They've made a design choice and do everything to protect their minimalist, flat design.  Since it’s a fairly plain design, it also means it’s easy to build on… it’s literally the foundation of your application.

I really need to do some more research into Bootstrap and Foundation, but I’m really leaning towards Foundation at this point.  It just seems like the better long-term product for business applications and they’re backed by designers making consistent choices.

Apply Business Logic Like CSS

Providing a rich client experience in the browser has been something that we (as a community) have been trying to do for as long as I can remember.  You don't have to look very hard to see the evolution of our attempts.  Over the course of a decade or so there have been several efforts to make this a reality: ActiveX controls, Java applets, Flash, and Silverlight are just the ones that I can name off the top of my head.  As support for ECMAScript 5 grows (and with the death of Internet Explorer 8 just around the corner), we're finally in an era where we can provide a rich client experience in the browser with nothing more than JavaScript.

This is certainly an exciting time, but just because the technology is available, that doesn't mean developer adoption is guaranteed to be high.  Why is this?  Surprisingly, most of the developers that I'm aware of are happy relying on the server-side technology they're so comfortable with; the shift to a thick-client in the browser means that a lot of developers will need to be pushed out of their comfort-zone.  I think this is an incredibly promising area, but many developers will need to be introduced to the concepts slowly in order to get buy in.

Admittedly, when I first tried to push more interactivity to the client I was a little lost.  In my latest project I decided that we'd try to layer in more client-side interactivity than we've done in the past, but I wanted to do it in a maintainable way.  I didn't want it to be bolted on at the end of the project with jQuery plugins; I wanted the interactivity to have first-class support in our application.  I also didn't want beautifully structured server-side code that does a hand-off to client-side code that's spaghetti.  After all, a rich client isn't worth it if it's a nightmare to maintain.

Over the last few years I've had my eye on Knockout and the ecosystem surrounding it.  Based on everything that I knew about it, it would be a good addition to Microsoft's standard MVC stack.  The problem with vanilla Knockout is that there isn't a good separation of concerns when it comes to your views and the logic to display them.  For instance, a standard Knockout view would have snippets JavaScript code throughout it like this:

<div data-bind="visible: myFunction() > myValue">
  Some Text
</div>

Obviously that's a simple example, but as you build more complex logic these inline JavaScript snippets can get out of hand.  Luckily there is a handy plugin that allows you to pull this logic out and apply it to your view like CSS tags:

<script>
  var bindings = {
    myClass: function(context, classes) {
      return {
        visible: this.myFunction() > this.myValue
      }
    }
  };
</script>

<div data-class="myClass">
  Some Text
</div>

I've left out the standard Knockout code to bind everything together, but hopefully you can see that this will allow you to completely separate your view from the logic behind it.  Just getting that separation is a huge benefit, but you can do something much more powerful with this basic construct.  With CSS you define small reusable classes and then combine them on your view to build a more complex style.  Just like CSS, you can begin to apply functional behavior the same way:

<script>
  var bindings = {
    show: function(context, classes) {
      return {
        visible: this.isMessageVisible()
      }
    },
    message: function(context, classes) {
      return {
        text: this.getMessage()
      }
    }
  };
</script>

<div data-class="show message">
  Message will be shown here.
</div>

This simple concept allows you to build tiny reusable pieces that define behavior.  You can then apply multiple behaviors to individual elements (or a hierarchy of elements) to compose more sophisticated behaviors.  In my latest web application I've built behavioral classes for tons of basic things: show, hide, valid, invalid, enable, disable, and other more complex classes that represent common behaviors in my business logic.

This method could certainly use some improvements, which I hope to work on in the future, but this is still miles ahead of where we were a few years ago.

Bootstrap 2.3.2

About a year ago I really started to pay attention to responsive web frameworks due to their growing popularity and impressive adoption rate.  I think this spike in popularity is largely due to Twitter's Bootstrap even though they weren't the first to the party.  At the time, I decided to do some research into all of the options so that I would be able to make an informed decision about their applicability on future projects.

I quickly descended into the rabbit hole that is CSS frameworks, ranging from basic CSS resets to grid systems to completely responsive frameworks.  In the end, I had come to the conclusion that Bootstrap 2.1.0 was the framework that was the most applicable framework for the types of applications that I build at my day job.  I don't have my notes (unfortunately), but I remember thinking that hands down, it was the best by far.

Fast forward to late 2013 and an opportunity to give Bootstrap a test drive has finally come along.  After doing a quick look around, it looks like Bootstrap is still the best framework that's available and stable.  It's now up to Bootstrap 2.3.2 and Bootstrap 3 RC1 is also available, but based on the list of compatible browsers, it doesn't look like I'll be able to use the latest and greatest for this project (I can't wait for Internet Explorer 8 to go away).

Now that I've finished this post, I feel like there's no real takeaway for readers.  I suppose this is really more of an announcement that "I'm using Bootstrap 2.3.2" and if you don't hear anything else about it from me, assume no news is good news.

(I'll work on making better posts)

A Good Reason to Blog

I've been thinking about blogging for years and trying to determine why I would ever start.  Well, I've started and the fact that you're reading this is proof.  I think it was a combination of two things over the last year that have really stuck with me.

The first one really got me thinking about it.  It's Scott Hanselman's notion that you only have so many keystrokes in you before you die.  When I sat down and actually thought about this I realized that I spend countless hours carefully crafting emails to a handful of individuals explaining various technologies or research results.  Since only a handful of individuals ever read it, the ROI for those keystrokes is extremely low.  If I really value my keystrokes I should be trying to get the biggest ROI as possible, which means making as many of my keystrokes public as possible.

The second reason is the notion of giving back to the community.  In the last 6 months I've spent almost all of my spare time doing a tremendous amount of research that's led deep into the open source community.  I've honestly been awestruck by the dedicated people that fuel the open source world.  I always knew that someone had to build that widget that saved me a month of my own time, but I don't think I truly understood what it actually took to make that possible until recently.

While ROI on my keystrokes sounds like a compelling motive for change, it really wasn't.  Feeling the urge to give back and contribute to the community; that's a compelling reason.

My efforts to contribute won't be immediate and widespread, but I'm going to make an honesty effort to give back to the community.  Over the course of the next year, I hope to have at least a few insightful blog posts and maybe even contribute to a open source project (I've got my eye on a few).  That may not sound exciting, but we've all got to start somewhere.

In the end, if something I post here manages to make someone's life easier in some small way, then it was worth it.  With any luck, someone will benefit from something I do in the future and will contribute back to the community as well.