GenXJamerican

The parts of our application (a long-term service and support system for the state of Maryland) that follow the DRY principle best tend to start with a combination of generic interfaces inherited by an abstract class that implements common functionality.  The end result–specific implementations that consist solely of a constructor.  I was able to accomplish this as well in one of my more recent domain implementations.  I’ve created a sample (using fantasy football as a domain) to demonstrate the ideas in a way that may be applied to future designs.

Let’s take the idea of a team roster.  A roster consists of players with a wide variety of roles that can be grouped this way:

• QBs
• offensive linemen
• skill position players
• defensive linemen
• linebackers
• defensive backs
• special teams

Since I want specific implementations that are (very) small, I'll need to find common attributes between these different groups.  Each roster grouping above is just a list of players.  Things that are common to all players (regardless of position) include attributes like:

• first name
• last name
• team name
• position

The first three attributes are just strings of text, so I treat them as such in my implementation.  Position could be treated that way too, but instead I'll implement an enumeration with all the positions and leave the implementation of it to position-specific classes I'll create later.  Going back to the roster grouping idea as a list of players, we can use a generic interface implemented by an abstract class so that implementations of the groups above will differ only by constructor.  Now, when I implement a Quarterbacks group,  the only differences between it and the implementation of an OffensiveLinemen group are the class names and types.  The RosterGroup class contains all the important functionality, including the IEquatable implementation that enables comparison of groups.  I followed a ReSharper suggestion to make IRosterGroup explicitly covariant.

 

I came across this post from Jeff Atwood in my Twitter feed this morning. It even sparked a conversation (as much of one as you can have 140 characters at a time) between me and my old co-worker Jon who agreed with Jeff Atwood in far blunter terms: “we need to cleanse the dev pool, not expand and muddy the water”.

While I understand Jon’s sentiment, “cleansing” vs. “expanding” just isn’t going to happen. Computer science as an academic discipline didn’t even exist until the 1950s, so it’s a very long way from having the sort of regulations and licensure of a field like engineering (a term that dates back to the 14th century). Combine that with the decreasing number of computer science graduates our colleges and universities graduate each year (much less the elimination of a computer science department), and it’s no surprise that people without formal education in computer science are getting paid to develop software.

While it does sound crazy that Mayor Bloomberg made learning to code his 2012 new year’s resolution, I’m glad someone as high-profile as the mayor of New York is talking about programming. When I was deciding what to study in college (way back in 1992), computer science as a discipline didn’t have a very high profile. While I knew programming was how video-games and other software was made, I had to find out about computer science from Bureau of Labor Statistics reports.

Jeff’s “please don’t learn to code” is counterproductive–the exact opposite of what we should be saying. Given a choice between having more people going into investment banking and more people going into software development, I suspect a large majority of us would favor the latter.

I also don’t believe that the objective of learning to code has to be making a living as a software developer in order to be useful. The folks at Software Carpentry are teaching programming to scientists to help them in their research. People who test software should know enough about programming to at least automate the repetitive tasks. If you use a computer with any regularity at all, even a little bit of programming knowledge will enable you to extend the capabilities of the software you use.

We need only look at some of the laws that exist in this country to see the results of a lack of understanding of programming by our judges and legislators. I think that lack of understanding led to software patents (and a ton of time wasted in court instead of spent innovating). The Stop Online Piracy Act and the Protect IP Act are other examples of dangerous laws proposed by legislators that don’t have even the most basic understanding of programming.

As someone who writes software for a living, I prefer customers who understand at least a bit about programming to those who don’t, because that makes it easier to talk about requirements (and get them right). They tend to understand the capabilities of off-the-shelf software a bit better and understand the tradeoffs between it and a custom system. In my career, there have been any number of times where an understanding of programming has helped me find an existing framework or solution that met most of a customer’s requirements, so I and my team were able to focus our work just on what was missing.

In the weeks since my last post, I’ve been thrown into the deep end of the pool learning ASP.NET MVC 3 and a number of other associated technologies for a healthcare information management application currently scheduled to deploy this July.  Having developed web applications using webforms since 2003, I’ve found it to be a pretty significant mental shift in a number of ways.

No Controls

There are none of the controls I’ve become accustomed to using over the years.  So in addition to learning the ins-and-outs of MVC 3, I’ve been learning some jQuery as well.

No ViewState

Because there’s no viewstate in MVC, any information you need in more than one view should be available either in the url’s query string, the viewmodel, or be retrievable via some mechanism in your view’s controller.  In the application I’m working on, we use Agatha.

More “Pages”

Each CRUD operation gets its own view (and its own viewmodel, depending on the circumstance).  This actively encourages separation of concerns in a way that webforms definitely does not.

A Controller is a Lot Like Code-Behind

I’ve been reading Dino Esposito’s book on MVC 3, and he suggests thinking of controllers this way fairly early in the book.  I’ve found that advice helpful in a couple of ways:

1. This makes it quicker to understand where to put some of the code that does the key work of the application.
2. It's a warning that you can put far too much logic in your controllers the same way it was possible to put far too much into your code-behind.

Using Agatha has helped to keep the controllers I've written so far from being too heavy.

More to Come

This barely scratches the surface of my experience with MVC so far.  None of the views I’ve implemented has been been complex enough yet to benefit from the use of Knockout JS, but future assignments will almost certainly change this.  We’re also using AutoMapper to ease data transfer between our domain objects and DTOs.  In addition to using StructureMap for dependency injection, we’re using PostSharp to deal with some cross-cutting concerns.  Finally, we’re using RavenDB for persistence, so doing things the object database way instead of using SQL Server has required some fundamental changes as well.

I presented a brief talk on LINQPad at RockNUG a couple of weeks ago.  This post will elaborate on that presentation a bit, since the 30 minutes I had wasn’t nearly enough to do justice to a tool I only half-joking called the Swiss Army knife of .NET development.

In addition to enabling developers to write and execute LINQ queries, LINQPad can be used to execute SQL queries as well as compose and run code snippets in C#, VB.NET, and F#.  LINQ can query a wide variety of collections and data, including SQL databases and XML.  The ability to query XML with LINQ becomes quite powerful when the XML comes from WCF Data Services (an implementation of the OData protocol).

During my presentation, I queried a local version of the Northwind database, as well as the OData endpoint of Netflix.  StackOverflow publishes their data via an OData endpoint as well. Additional producers of OData services can be found here, or in the Windows Azure Marketplace.

One of the nice features of LINQPad is the number of export options it provides for your query results.  The results of any SQL or LINQ query written in LINQPad can be exported to Excel, Word, or HTML.  The Excel and Word export capabilities give you the option of preserving the formatting LINQPad provides, or leaving it out.  Once you’ve queried a database with LINQ, the results display allows you to toggle between the equivalent fluent LINQ, SQL and MSIL syntax.  I demonstrated this feature by executing a SQL query against the Northwind sample database, then cutting and pasting the equivalent syntax to new query windows and running them to show that the query results were the same.

The LINQPad website pitches the tool as a replacement for SQL Server Management Studio.  To test this proposition, I demonstrated LINQPad’s ability to execute stored procedures.  I used the TenMostExpensiveProducts stored procedure in the Northwind database, and this script to show one way to use LINQPad to run stored procedures that take parameters.

LINQPad’s capabilities as a code snippet runner are further supported by its ability to reference custom assemblies and namespaces.  So instead of dealing with all the overhead of Visual Studio just to write a console application, you could simply write them in LINQPad and reference any custom assemblies you needed.

The latest version of LINQPad also has an extensibility model, if you wanted to query databases other than SQL Server (or different querying sources).

One feature I wished I’d had time to delve into further was LINQPad’s ability to query Entity Framework models defined in Visual Studio.  There’s a brief description of that capability here.

All of the query files from my presentation are available on Github.

Since yesterday’s post about my goals for next year, I heard from my friend Faisal about a jQuery plugin he’s been working on called Ninja UI.  It’s on github, so I’ll definitely be checking it out as part of my learning of jQuery for next year.  Going beyond using open source tools to being a committer on one would be a big step forward for me.

Today at work, I gave a presentation on NuGet.  I’ve suggested they consider it as an option to ease management of the open source dependencies of our major application, so it was natural that I present the pros and cons.

NuGet is a system for managing .NET packages.  It’s not unlike RubyGems or CPAN (for Ruby and Perl respectively), and while it has some work to do to be on par with those alternatives, they’re off to a very good start.  Today’s presentation focused on just a few the capabilities of NuGet, and I’ll recap a few from my presentation in this post.

The primary use case for NuGet is the management of open source dependencies in a .NET application.  There are a number of key open source libraries that .NET developers like me have been using in projects for years.  Upgrades were always a pain because of having to manage their dependencies manually.  Many of these tools (NHibernate, NUnit, log4net, and more) are already available as NuGet packages at the NuGet Gallery.  I used NHibernate and NUnit in my examples today.  Another tool that proved quite useful in my demo was the NuGet Package Explorer.  Some of its features include:

• Opening and downloading packages from remote feeds
• Opening local packages to view and change their metadata and contents
• Creating new packages (instead of fiddling with XML manually)

In addition to getting packages from Microsoft's official feed, it's possible to create your own feed of NuGet packages.  Phil Haack has a post on how to do this.  My demo for work only included a local folder feed source, but I tried Haack's instructions at home and they worked quite well.

I wrapped up my presentation with two different examples of building NuGet packages without a manually-created .nuspec file as a starting point.  The documentation provides examples of how to generate a .nuspec file from an existing DLL, and how to generate a NuGet package from a .csproj or .vbproj file.  I published the rules engine (which I found in an answer to a stackoverflow.com question), and a test assembly I created to the NuGet Gallery earlier this evening.  If you want to check them out, just search for Arpc.RulesEngine in the NuGet Gallery.  I still need to publish the rules engine source as a package and/or  push it to a symbol server.  Once the enterprise story for NuGet becomes a bit clearer, I hope I have an opportunity to present on that as well.