Today, one of my team leads did a tech talk for his team. The talk was an intro to MVC, specific to their project. It was awesome. You might be thinking, MVC is second nature to me. I have been using MVC for years. Any noob should know what MVC is. That’s not true.

At Mailtrust, the vast majority of our developers come from the coolest school across the street, Virginia Tech. Many of them didn’t learn MVC in school. Even if they did, they have never used it in an enterprise environment working in a team.

Camtasia to the rescue. For this tech talk, we did our first screencast recording. Now we have a reusable, applicable, and awesome training tool. The next time someone asks what MVC is, they won’t get the 5 minute high level talk that leaves them more lost than before. They get an hour long presentation, with full demo and discussion. Sweet. No more repeat training sessions.

In reality, this isn’t true at all. A feature is a commitment to your users. For every feature, the initial cost is usually design, development, testing, documentation, and support. What’s funny, is every single one of those is a continuing cost that usually gets overlooked. For every feature, there are bugs that developers need to fix, testers need to verify, and writers need to document. For every design, there is usability testing that reveals flaws. For every feature, there is support.

To succeed, I think there are really two choices. One, eliminate as much continuing cost from each feature as possible. This can be accomplished by reducing uncertainty. Unit tests, functional tests, usability tests, continuous integration, and multiple testing environments all reduce this uncertainty. Unfortunately, this slows your turnaround time down unless you can hire at a rate greater than your continuing cost, which is hard.

Or you can implement less features. This means every feature you implement has to be super important and you can spend a lot of time making it awesome. What’s funny is you now have time to do all the things necessary to build a feature with a very low continuing cost. The obvious downside is, you may not be able to compete because your competitor has everything you don’t.

What’s better? I honestly don’t know. What I do know is every feature should be thought of this way and not as a checklist item. Then skipping that useless unit or functional test doesn’t seem as appealing.

As with any service, there is room for vast improvements. The software is slow and buggy, but not bad enough to piss me off, which means it is still very usable. Also, the software only works on Windows XP or Vista, which is annoying for me because I run Ubuntu and Windows. In the future, software for linux that could be integrated with MythTV would be stellar-sweet. (Something tells me the suits are worried about the ability to rip the videos easier in linux).

All things considered, it is exactly what I wanted when my craving for season 4 of BSG got the best of me. I can’t compare it to similar services, but it is worth trying if you don’t care to hook your laptop up to your TV and pay $1.89 an episode.

Well, shouldn’t the same be true for documents, specifically those that describe some sort of process? For example, a document describing the steps to setup an IIS web server for a particular application is perfect to convert to an automated script. So, today, I started on a simple script to setup IIS compression using MSBuild.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
 
  <!-- Types -->
  <PropertyGroup>
    <adsutilPath>C:\inetpub\AdminScripts\adsutil.vbs</adsutilPath>
    <cscriptPath>cscript</cscriptPath>
    <StaticFilesToCompress>html htm js txt</StaticFilesToCompress>
    <DynamicFilesToCompress>aspx asp dll exe axd</DynamicFilesToCompress>
  </PropertyGroup>
 
  <Target Name="IisCompression">
 
    <Message Text="Turn on static and dynamic compression for all of IIS." Importance="high" />
    <!-- http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/502ef631-3695-4616-b268-cbe7cf1351ce.mspx?mfr=true -->
    <Exec Command="$(cscriptPath) $(adsutilPath) set w3svc/filters/compression/parameters/HcDoStaticCompression true" />
    <Exec Command="$(cscriptPath) $(adsutilPath) set w3svc/filters/compression/parameters/HcDoDynamicCompression true " />
 
    <Message Text="Select files to compress for static and dyanamic compression." Importance="high" />
    <!-- http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d52ff289-94d3-4085-bc4e-24eb4f312e0e.mspx?mfr=true -->
    <Exec Command="$(cscriptPath) $(adsutilPath) set W3SVC/Filters/Compression/Deflate/HcFileExtensions $(StaticFilesToCompress)" />
    <Exec Command="$(cscriptPath) $(adsutilPath) set W3SVC/Filters/Compression/gzip/HcFileExtensions $(StaticFilesToCompress)" />
    <Exec Command="$(cscriptPath) $(adsutilPath) set W3SVC/Filters/Compression/Deflate/HcScriptFileExtensions $(DynamicFilesToCompress)" />
    <Exec Command="$(cscriptPath) $(adsutilPath) set W3SVC/Filters/Compression/gzip/HcScriptFileExtensions $(DynamicFilesToCompress)"/>
 
  </Target>
</Project>

Not only does this script automate the process, but it serves as a living document for the process. By doing this, the documented process is now coupled to the task itself.

The next step to coding processes is coding tasks that can’t be automated. For example, during a deployment, if some sort of fatal error occurs, the next task might be to call your boss and clean up your resume. Why not code a message in the deploy script to give you the list of people and phone numbers to call in case of an emergency, then load up your resume in Word? Again, the documented process is now coupled with the task itself.

Obviously, this article grows out of my dislike of documentation. I dislike it, not because it isn’t useful, but because it takes a lot of time and, in my personal experience, isn’t used very often. By integrating the documentation with the task itself, I think we gain more value from it.

Session Management

The biggest thing that I don’t like is the session management aspect. Although I have come to understand why NHibernate sessions are so valuable and critical to its functionality, it doesn’t stop the fact that persistent objects are tied to a single database. For a project that follows the patterns and practices set forth in ivory towers, this works great. All business entities are stored in a database in 6th normal form and everyone is happy. Well, when working with legacy and enterprise systems, that usually isn’t the case. There are many different databases that are used and objects are stored across a variety of them.

In order to get my system to use NHibernate, the first challenge was incorporating multiple sessions. A session is basically a connection to a single database that manages persistent objects. This article describes a really complex way to accomplish it, but all you really need to pay attention to is the NHibernateSessionModule and NHibernateSessionManager. Using the outline described in the article, I successfully got multiple sessions to work fairly painlessly.

The second challenge was storing a persistent object in multiple database. Since persistent objects in NHibernate can’t span multiple sessions, some data massaging has to be performed. As I see it, there are two possibilities for storing an object in multiple database.

1. Different objects for each database with type conversion operators
2. The same object for all databases with extra session logic

The latter is obviously easier from a domain model perspective, but not from an implementation perspective. For a persistent object from one session to be stored in another session, all references must be removed from the session. This means unproxying the object and unpersisting any collections contained within the object. Looking through the NHibernate source code, I was able to accomplish this with only a few lines of code.

Setup & Documentation

Most of the getting started guides for NHibernate are no where near complete or up-to-date. It took a couple days to get my environment up and running. This isn’t really a problem with the library itself, but is still a problem for first time users. In all reality, there seems to be a lack of documentation in general. Three example mappings in the documentation is no where near enough for what is marketed as an enterprise ORM solution.

Conclusion

NHibernate is awesome. Even with these minor issues, it is one of the greatest tools for web development I have ever used. I hope that the development of this library continues to improve, and hopefully some of these issues will be resolved.

ADO.NET provides common interfaces and base classes that can be used with different database providers. While some companies use everything Microsoft, we do not. In all honesty, I would choose MySQL over SQL Server for almost any project but that is an argument for another day. Like I was saying, ADO.NET is good, but can have some very repetitive code. Managing connections, creating commands, adding parameters, and executing readers is pretty annoying. But, the worst thing about ADO.NET is having to create database provider specific code. To create a connection to an Odbc database, you have to actually load the OdbcConnection class.

Luckily, Microsoft realized that ADO.NET had these short comings and created Data Access Application blocks, which are part of their Enterprise Library. I have been using them for a couple weeks and am definitely a fan. The greatest thing about it is the ability to completely abstract out the database provider. For example (Copied from the Microsoft website):

Database db = DatabaseFactory.CreateDatabase();
DbCommand dbCommand = db.GetStoredProcCommand("GetProductsByCategory"); 

// Retrieve products from category 7.
db.AddInParameter(dbCommand, "CategoryID", DbType.Int32, 7);
DataSet productDataSet = db.ExecuteDataSet(dbCommand);

If you didn’t notice, there was no mention about an Ole, SQL, Oracle, or Odbc provider. Also, I think it is a really clean and logical way to abstract the database. I definitely recommend checking out Data Access Application blocks, as well as the entire Enterprise library.

After a few days of digging though, I found a few great articles (Choosing Data Containers for .NET, On the Way to Mastering ASP.NET: Introducing Custom Entity Classes) on why not to use DataSets, as well as why you should. DataSets were designed for rapid application development, and seems to be Microsoft’s answer to the Rails ActiveRecord pattern. It is a quick and dirty way to build the data access layer for web applications. To be more specific, by quick I mean it allows version 1.0 of a product to be released quickly, because a data abstraction already exists. By dirty, I mean it isn’t an abstraction created for your application, it is a data abstraction created for any application.

Pro’s of ADO.net

• Fast development time
• In place architecture.
  Developing custom data access solutions can be very powerful, and very risky. A bad design can lead to bad performance and is inherently error prone
• Feature rich
  • Disconnected data
  • Concurrency
  • Many more…
• Easily serializable

Con’s of DataSets

• Large memory footprint
• Not object oriented.
  DataSet’s represent relation data, just like a database. But I don’t want an in-memory representation of the Employee table, I want Employee objects. Scott Hanselman sums it up pretty nicely:

  A DataSet is an object, right? But it’s not a Domain Object, it’s not an “Apple” or “Orange” – it’s an object of type “DataSet.” A DataSet is a bowl (one that knows about the backing Data Store). A DataSet is an object that knows how to HOLD Rows and Columns. It’s an object that knows a LOT about the Database. But I don’t want to return bowls. I want to return Domain Objects, like “Apples.”

• Not abstracted.
  Directly connected with database data and structure. So, any change to the database schema, could trickle down to the presentation layer.

Conclusion

ADO.NET is a huge improvement from old ADO, but don’t buy into the entire framework. Microsoft is trying to push DataSets but they might not always be the best solution. For enterprise applications, I don’t think DataSet’s are the answer. On the other hand, for smaller web application, it might be a perfect fit.

My requirements for a theme are simple:

• Widget ready
• At least 1 sidebar, maybe 2
• Simple

Being a web developer, I hoped for a little more though. I wanted an Ajax theme. It took a while, but I finally found K2, the second version of the default Kubrick theme. So far I am super happy with it, but I need to tweak the Now Reading plugin to not suck at HTML.

Maybe I can get back to blogging about important things soon since this one annoyance is gone …

I initially had low expectations, expecting 1.0 to just clean up 0.7 code, with minimal feature additions. After I downloaded it, I found out how wrong I was. The 1.0 release fixed every negative comment I had about 0.7. Although it’s not perfect, it’s a lot better than it used to be.

The Good..

• Variables for defining which row and rowset classes to use in Zend_Db_Table. This enables custom row and rowset classes which I believe is a must-have.
• Support for compound primary keys
• Ability to cache the table meta data and prevent unnecessary database access

The Bad…

• Application level support for foreign keys, namely cascading deletes. This feature is awesome since a lot of the tables I work with are myisam and don’t support cascading deletes. Too bad it doesn’t truly cascade. If you delete a single record, it will cascade that delete to all related tables, but no cascading after that. Basically, a worthless feature that causes more confusion than it helps. Just use MySQL’s Innodb storage engine and clean up the code
• Complexity. Lots of classes and lots going on.