Schema Generation using FluentNHibernate and S#arp Architecture

Posted by indomitablehef | Filed under S#arp Architecture, NHibernate

This took me several hours to figure out, and even though it makes me look bad to admit that, I figured I’d share what I eventually came up with.

I’ve been using S#arp Architecture for ASP.Net MVC, which uses FluentNHibernate. The S#arp Architecture project template generates the following test, used to test the FluentNHibernate mappings:

1
2
3
4
5
6
7
8
9
10
11
12

    [TestFixture]
    [Category("DB Tests")]
    public class MappingIntegrationTests
    {
        [SetUp]
        public virtual void SetUp()
        {
            string[] mappingAssemblies = RepositoryTestsHelper.GetMappingAssemblies();
            NHibernateSession.Init(new SimpleSessionStorage(), mappingAssemblies,
                "../../../../app/FuBar1.Web/Hibernate.cfg.xml");
        }
<...>

To do the Schema Export based on the FluentNHibernate mappings, you need to get at the NHibernate Configuration object.
Luckily, the NHibernateSession.Init method returns the Configuration object. So, I modified the Setup for the MappingIntegrationTests class to:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

    [TestFixture]
    [Category("DB Tests")]
    public class MappingIntegrationTests
    {
        private Configuration cfg;
 
        [SetUp]
        public virtual void SetUp()
        {
            string[] mappingAssemblies = RepositoryTestsHelper.GetMappingAssemblies();
            cfg = NHibernateSession.Init(new SimpleSessionStorage(), mappingAssemblies,
                "../../../../app/FuBar1.Web/Hibernate.cfg.xml");
        }
<...>

…capturing the Configuration in a private variable.

I then added this [Test] method to the class, to do the SchemaExport:

1
2
3
4
5
6
7

        [Test]
        public void SchemaGeneration()
        {
            var session = NHibernateSession.SessionFactory.OpenSession();
            new SchemaExport(cfg).Execute(true, false, false, false, session.Connection, null);
            Assert.IsTrue(true);
        }

and viola! I get this in the test output window (ReSharper, NUnit)

Yeah, that’s right. Monkeys.

Nashville Alt.Net Lunch and Learn - LINQ

Posted by indomitablehef | Filed under Alt.Net

Nashville Alt.Net Lunch and Learn is this Thursday at 11:30.

Topic: All things LINQ.

Remember to bring your own lunch, and no recruiters, please.

Directions: 216 Centerview Drive, Suite 390
Brentwood, TN (map: http://tinyurl.com/6y4pbx)

From Franklin Rd., Turn onto Church Street, then take your first right
on Centerview Drive. We’re in the second 3-story office building you
come to on the left. 3rd floor. When you exit the elevators go
straight ahead to the end of the hallway in front of you. We’re the
last door on the right, suite 390.

Management Debt

Posted by indomitablehef | Filed under Anti Patterns

Extending the concept of Technical Debt to Management: Musings about Management Debt.

I see this especially in cases where an organization is running in crisis mode all the time. I especially love what one of the commenters said:

A manager who is responsible for project management, software development, etc. asks decision-makers which project is the most important and the answer is “all of them.” [Which actually means] “all our projects are equally unimportant.”

NashDotNet Resources

Posted by indomitablehef | Filed under Continuous Integration, .Net, Tools

• Presentation Outline
• Martin Fowler’s seminal article on Continuous Integration
• An older post from me, with resources for automating your build with NAnt and using CruiseControl.Net for continuous integration
• JetBrains TeamCity
• Customizing your build script to interact directly with TeamCity’s simple API
• MSBuild Community Tasks
• PsExec
• Visual Studio Web Deployment Projects Download
• Ruby Programming Language
• Rake NUnit Task
• OMG, Rake! - Dave Laribee on using Rake to automate your builds, with links to helpful resources for learning Rake
• Rake documentation
• Example Project and Example Automated Build scripts from the presentation
  look under “source” /trunk/NashDotNet

It’s Caves AND Commons…

Posted by indomitablehef | Filed under Anti Patterns, Agile, Productivity

…not Caves OR Commons, and not Commons only.

Australian scientists have reviewed a global pool of research into the effect of modern office design, concluding the switch to open-plan has led to lower productivity and higher worker stress.

“The evidence we found was absolutely shocking,” researcher Dr Vinesh Oommen from the Queensland University of Technology’s Institute of Health and Biomedical Innovation, said.

“In 90 per cent of the research, the outcome of working in an open-plan office was seen as negative, with open-plan offices causing high levels of stress, conflict, high blood pressure, and a high staff turnover.

If you have to choose one or the other, you’re better off giving everyone a cave than forcing everyone into a common area. It’s feasible to cram multiple developers into a cubicle for pair programming and collaboration. It’s not feasible to focus and achieve “flow” in an open plan office when working alone. The last time I worked in such an environment, it turned into a shanty-town. Developers would build little “forts” around their half-cubes with marker boards, stacks of books, and pieces of cardboard. They’d hang up signs saying “do not disturb”, and invest their own money in expensive noise-canceling headphones - just to be able to get a little work done once in a while.

Amazingly, this is one of those fundamental things that almost nobody gets. I’ve never worked in any place that got it right. Software developers are expensive resources, especially good ones. And as a manager, you would think that getting the absolute most out of that expensive piece of equipment would be one of your top priorities. Instead, developers are crammed into cubicles instead of offices, and at worst, forced to sit out in an open floor plan. It’s money down the drain.

How about a little math?

Let’s say you’ve got a good developer, and he makes 90K year.
Now let’s make some assumptions…hypotheses, if you will.
1. Assume that working in an office would make him more productive by 1/2 hour per day, over working in a cube
2. Assume that working in an open floor plan would make him less productive by 1/2 hour per day than when working ina cube.
3. Assume that having an office with a door, and a common area to work with and collaborate with a team would make him more productive by 4 hours per week.

There are 260 working days per year. Assuming an 8 hour day, your developer’s half hour is worth approximately $21.60. His four hours per week is worth approximately $173.

So, in one year:
1. If you give him an office, he is more productive to the tune of 21.60 x 260 = $5,616.
2. If you sit him in an open floor plan, he is less productive to the tune of $5,616
3. If you give each developer an office, and the team a common area to collaborate, each member of the team is more productive to the tune of 173 x 52 = $8,996

Assume your office floor plan will last 3 years or more and you are considering an open floor plan. Can you afford some sort of an office for every developer for less than $33,696? Not a corner office with a view, mind you…just walls and a door.

Assume you have a team of 6 developers, average salary of 90K, and you are considering an open floor plan (for 3 years)…can you afford to set up offices and common areas for less than $161,928?

Can you afford not to?

(I think my productivity assumptions are highly conservative, and that the real return would be much higher. Probably double. Maybe more.)

Also, I have at least heard of one place that got it right: Joel Spolsky’s Bionic Office.

Table Stakes

Posted by indomitablehef | Filed under Agile

In a card game, “Table Stakes” means that you can only play with what you have on the table.

All poker games are played table stakes. This means one can only bet what one has in front of him on the table on any given hand. Players cannot reach into their pockets and add to their bets. If a player runs out of chips in front of him in the middle of a hand, he or she is considered all-in.

The same principle applies when your are planning a project, a release, or a sprint. Whether you’re limited by a fixed budget, a hard delivery date, or just a self-imposed sprint or release length, you can only plan for how much you have on the table. I recently worked on a project where I violated this principle. Working with the customer, I hashed out the requirements and gave them rough estimates. It was a fixed-bid project, and when we added up the estimates, it came out to nearly double the budget.

Under pressure to do so, and against my better judgment, I agreed to get started working. I warned the customer that we were over budget, and that we’d have to make cuts. But I agreed to work through the first (1 week) sprint, and do that “cutting” the next week. When that next week came, I again warned the customer that we were not going to get done, and that we’d have to make cuts, but I again agreed to wait till the next week. And so on, and so forth. In the end, expectations were never realistically set, and no one was really happy.

Rookie mistake, I know. But now I have a label, something I can use to remind myself never to do that again. And I can the Table Stakes analogy to explain to customers why I won’t do it. From now on, we’re not done planning and ready to get started coding until we have gotten our list of requirements down to something we can actually do in the time allotted.

SqlTdd Improvements

Posted by indomitablehef | Filed under SqlTdd

I’ve improved the recording and display of Test Results, including the start/end times for each test and maintaining history for test runs. http://code.google.com/p/sqltdd/

Speaking at .Net User Group on Jan 15

Posted by indomitablehef | Filed under Uncategorized

I’ll be presenting at the Nashville .Net User Group on Thursday night, January 15, 6PM at the Brentwood Library.

The topic will be “Continuous Integration with JetBrains TeamCity”:

TeamCity, the new Continuous Integration application from JetBrains (the people that brought you ReSharper) provides easily configurable continuous integration, advanced reporting and metrics, and integration with Visual Studio (and It’s free for small teams). This presentation will cover installing and configuring TeamCity and connecting it to source control, with examples using various build runners (MSBuild, NAnt, and Rake) to build .Net applications. We’ll also cover NUnit integration, artifact generation, and configuring notifications. We’ll show you how to troubleshoot broken builds, run the .Net duplicate finder build, Visual Studio integration, and how to use TeamCity as an automated deployment tool.

Tactics vs. Strategy

Posted by indomitablehef | Filed under Uncategorized

Neal Ford: Tactics vs. Strategy (SOA and the Tarpit of Irrelevancy)
First in a series on “Evolutionary SOA”…looks like great stuff.

AntiPattern: The Proxy Product Owner

Posted by indomitablehef | Filed under Anti Patterns

I am not the sort of person who never makes the same mistake twice. I may swear up and down that it’ll never happen again, but I forget. And it happens again. If, however, I can identify a pattern, some immutable law of the universe that I can internalize to keep me from making that mistake again, it helps. It may push me towards dogmatism, but at least I won’t get bitten on the ass by the same dog next time.

So, here are a couple of mistakes from the past, recently repeated, that I am now going to attempt to quantify, categorize, and put to bed for the remainder of my career.

I’ll do one today, and plan to do one tomorrow.

AntiPattern: The Proxy Product Owner
This one is an oldie for me. It happened to me on my very first production web application, in my very first job out of college. It happens when there is a “proxy” between you and the real users/product owners of the application you are building. This person may be a well-meaning project manager, trying to shield you from stupid users or shield users from asshole developers. It may be a piss-ant IT manager who is protecting his little fiefdom. It may just seem more “convenient” and “cost effective” than introducing the actual developers to the actual product owner.

In that first web app I wrote, I had the piss-ant IT manager as a proxy between myself and the department that was going to use the app. I got all the requirements from him, showed all my progress to him, and stopped working on it when he was satisfied that it was done. He was thrilled with the result. Absolutely thrilled. Then they asked me to teach training classes to the end users. When I got to class, it was the first time that any of the users had met me OR my application. They’d never seen it. And they hated it. They couldn’t understand why anyone would do things that way. They certainly wouldn’t be able to use this to get their jobs done. Eventually, the app was updated to meet some of their needs, and they gritted their teeth and learned to live with the rest of it. And the piss-ant was still thrilled with it. And the users still hated it.

That’s the “explode on impact” scenario - where everything looks fine till the end, and it turns out that neither side understood each other at all. There’s a more gradual way of playing out this charade as well.

1. Week (or Month) One
   Developer Meets PPO (Proxy Product Owner), and hammers out application requirements, screen mockups, estimates, and schedule. Developer starts work, confident that he has diligently picked the product owner’s brain so that he really understands their needs.
2. Week (or Month) Two
   Developer delivers first progress to PPO, who is thrilled. PPO decides to wait till next week to show the application to real customer. No reason to get them involved just yet. Developer keeps working.
3. Week Three
   Developer delivers progress to PPO, who has bad news. PPO showed demo app to customer late last week, and customer has changes. Just some “tweaks”. PPO sends Developer an excel spreadsheet with new requirements, new screen mockups, and changes to the names of several features. Also requests additional administrative options and reports. Developer informs PPO that these changes will probably affect our ability to meet a rapidly approaching deadline, and some features will have to be cut.
4. Week Four
   Developer re-designs application layout to meet new specs/mockups, removes some features from week 1 and starts on some new features from Week 3.
5. Week Five
   Developer delivers progress to PPO, who has recently spoken to customer again. They’ve heeded the developer’s advice from week three, and decided to stick with most of the original plan, except for some of the name changes and screen layout changes. They believe this gets them back on track to meet the deadline, maybe even ahead of schedule.

This process continues until the money runs out, the customer is not happy, the product is barely usable at all, and the developer takes up smoking again.

Update: It occurs to me that I’m just restating the importance of “On Site Customer“, not saying anything new. Just saying with more bitterness.