The list of proposed sessions are available on the web site http://austincodecamp2012.com. Please look at the sessions and vote for the ones you find most interesting.  We use this information to place the presenations in an appropriately sized room (though some will be cancelled I’m sure)

It’s going to be a great conference!

Also if your company would like to sponsor, please contact us.

You can find out more at http://austincodecamp2012.com You can register for the the event and also register as a speaker and submit presentations for the event.

All of the content in community driven, presented by members of the community.   I would encourage you to come and talk about whatever is interesting in the world of software development.  While the event is organized by the Austin .Net Users group, it is not limited to discussions about .Net.   It is an excellent opportunity to gain public speaking experience.

Please come join us!

Given our history with this application and the phases we’ve gone through (initial development, maintenance / enhancements, and complete change in process) I think it’s a good case study in the feasibility of using CQRS style applications.  We’ve made some good decisions and some, err.., not so good decisions that I learned quite a bit from.

A little about the Application

The application is the standard “enterprise workflow” application, where the end users work product goes through several stages and different people do different tasks in order to complete the work.  These type of State-based, processes fit well with the CQRS model, as different events occur on the items in question, which determine what’s required and what action needs to take place.  There were very few “CRUD” type screens, but there were a few.

My definition of CQRS

Separate models for reads and writes

I think my definition heavily influenced how we built this application.  Notice there’s nothing there about messaging, MSMQ, distributed architecture, Event Sourcing, etc…  We did use some of these technologies and architecture in this app, however they are not required for CQRS. It’s simply an acknowledgement that the write model looks and behaves differently from the read model.  This simple acknowledgment can have profound impact on the way build your application and your ability to solve problems for your end users (and if you’re not doing that, well…)

Not Everything has to fit into the CQRS Mold

I think one common mistake made while building applications with CQRS is forcing every single functionality through the CQRS square hole.  There were parts of our application that were very simple and did not require the complexity of CQRS.  That’s right, CQRS is complex. I said it.  Commands must be created, validated and executed.  Events must be fired and handled.  Usually the complexity is mitigated by the simplification of the domain models.  But if you’re domain models are already simple, then a simpler approach will yield better results.

Do Not Start With a Distributed Architecture

When most people see examples or presentations of CQRS, it usually includes some sort of distributed architecture, where the commands and messages are put on some sort of queue, like MSMQ, RabbitMQ, or whatever.  And there can be some great advantages when using these techniques, mostly scalability.  Using a distributed approach increases the complexity to a whole new level.  However it is simply not necessary, at least at first.

For our application, we created a very simple in-process bus.  Meaning, execution of the command and all events were executed on the same thread.  We used an IOC container to find all of the event handlers based upon the event class type. It is a web application, so the threads were handled by the web server.  For a typical event, we had 4-6 event handlers, updating 4-5 different database tables.

There were some real advantages to starting with an in-process model.  We were able to get faster feedback when errors came up, and it was easier for us to find and fix bugs. This enabled us to build the application faster and get it into the end users quickly.

Once we were in production, we started recording metrics on the how quickly requests took and where there were performance issues.  What we discovered was the only real performance issues were when the users would perform batch operations, the same operation on many records (set based operations are nearly impossible with this architecture, or at least I haven’t figured out how to do it).  So once we determined which functions were commonly done in batch form, we moved them out of process with NServiceBus.  I think that’s one of the areas where this approach shines.  Moving these out of process, when necessary, is really simple.

Move work out of process only when necessary

Think Creatively about your Domain and View Models

One of the mistakes we made was the design of our domain models.  From a purely DDD / aggregate root / ubiquitous language, there was really only one AR.  But having just one AR means it’s REALLY big.  In retrospective, we should have been more creative with how we define the AR into something different.  Honestly, while this application has come complicated logic, I don’t think that we needed to solve it with a Domain Driven approach.  However, the library we used (per client request) required us to do so.  I don’t have a solution for this yet, when I do I’ll let you know (hint, I think the Actor/Model patter Chris Patterson has been talking about is a better fit).

Event Sourcing … Meh

Event Sourcing has been probably the most misunderstood and miscommunicated implementation strategy surrounding CQRS.  Like other pieces of the architecture, it’s an implementation choice, not a requirement for building this type of application.  Honestly, I was never sold on the concept before this project.  On this project I don’t think we got any of the benefits touted from using it.  To be clear, I think one of the problems is our implementation of the Event Sourcing persistence.  We are currently storing a binary copy of the event.  Which means that event lives in perpetuity and we can’t change it nor get rid of it. If it was serialized with something like Protocol Buffers I think we would have more flexibility, but I haven’t tested that yet so I can’t say for certain.

The biggest feature about using ES is the ability to replay the events and rebuild the state of your view models.  This sounds really cool, you get the ability to create new views in your application (like new reports)  and be fully avaialble with all data as if they were there from the beginning.  The only problem is that we’ve only done that once in the entire lifetime of the application.

But at the same time, using the event sourcing approach hasn’t really cost us anything either.  In the end, for this application, I would have been happy with just a Key-Value store of data or a document database for aggregate persistence.

Overall, I’m pleased with the application.  Like I said there was a big change in business process and we’ve been able to make those changes very fast in my opinion.  This is mainly due to the extreme decoupling you get from the way views are represented to how a domain object is changed or created.  I will likely continue to create applications of this type using this approach.  With a few changes underneath of course:)

http://bit.ly/ieUPl1

http://bit.ly/qHQq48

If you haven’t registered for CodeCamp, go here http://bit.ly/jrQ1Qs

As always it’s free.

An Open Space conference is really a different experience than the traditional, presentation driven conference.  While both formats are about learning new things, they go about it in entirely different ways.  An Open Space conference is more about the conversation than anything.  The way I often describe it is if you’ve ever gone to a conference and the most stimulating moment was a conversation in the hallway or break room, that’s an Open Space conference all day long.

If you’ve ever gone to a conference and the most stimulating moment was a conversation in the hallway or break room, that’s an Open Space conference all day long.

The environment is very fluid and active.  This is due to the Law of Two Feet and  the schedule is determined by the attendees.  Unlike a presentation focused event, where you tend to sit still and listen to someone for an hour or more, you are actively encouraged to move around and keep engaged.  If a session isn’t going the way you want, just go to another, or start your own.

The self-organizing aspect of the format is really important.  Even though I am one of the organizers of the event, I have almost no say in  what the topics and sessions are about (I’ll be proposing topics and help organize the proposals, so I have a little say).  And the fact that speakers don’t submit their sessions months in advance, the topics are usually very current and relevant.

At last year’s Los Techies Fiesta, a couple of the sessions really stood out for me.  One of the sessions I proposed was on NoSQL options.  At that time I had never used any of the NoSql tools and knew very little about them, but it was a topic that I wanted to learn more about.  It was an amazing session.  I learned about Mongodb, Cassandra, Redis, and several others.  I learned the difference between document databases, Key Value storage and Column Oriented databases.  Even though I was the “facilitator”, I  knew very little about the topic, everyone their shared their experiences and knowledge for a highly enlightening conversation.

I hope you’ll join us this year and share your knowledge with us!

Not too long ago Joshua Flanagan spoke at the Austin .Net User Group about how the Dovetail crew use conventions to simplify their development process. The approach is simple in concept (of course the devil’s in the details)

This inspired me to apply the approach in my current project. Our project has several screens that very similar: a table, some buttons to perform actions, and a set of filters. When we implemented the first screen, it was obvious that building the filters were going to get old really fast. This looked like a good place to try and make things a little easier.

I started by creating a class for the fields that were on a filter and used the properties in the class to create an NHibernate Criteria search. The only real requirement here is that the property names in the filter class had to match the names in the Nhiberante mapped object.

This was pretty easy to setup. All we needed to do was build up the Criteria from the property names and the values.

public IEnumerable<ICriterion> CreateFilter(object filter, Type objectToFilter)
{
  var criterion = new List<ICriterion>();
  var props = filter.GetType().GetProperties();
  foreach (var pi in props)
  {
    var val = pi.GetValue(filter, null);
    if (ShouldNotAddToFilter(pi, val)) continue;
    criterion.Add(new SimpleExpression(pi.Name, val, "="));
    return criterion;
}

Now this will create a very simple criteria by creating where statement with a bunch of Property = value OR Property2 = value2. While this is functional and does cover most of our needs, it is pretty limited in what it could do. One issue is that it only goes one level deep in your persistence model hiearchy. You would not be able to apply filters to anything modeled as components. Also there were a few fields that needed to be queried using expressions other than equals. We needed to do like filters as well as greater than / less than queries too. So we need to provide some metadata for the properties to make variations on the criteria output. The easiest way to do that is to decorate the filter properties with some attributes.

We created a set of Attribute classes that allowed us to create different types of Criteria Expressions.  The type of expression needed was created inside the attribute.  We can then use the power of polymorphism to avoid a big if or switch statement and keeps the query building code clean.

public class QueryFilterAttribute : Attribute
{
  public virtual ICriterion GetCriteria(string propertyName, object val)
  {
    return Restrictions.Eq(propertyName, val);
  }
  public Type ComponentModel { get; set; }
}

public class LikeQueryFilterAttribute : QueryFilterAttribute
{
  public override ICriterion GetCriteria(string propertyName, object val)
  {
    return new LikeExpression(propertyName, val.ToString(), MatchMode.Anywhere);
  }
}

These attributes allow us to change the Criteria Expression or Apply the filter to a Component Type. The full source code is at the gist below.

This relatively simple construct saved us a lot time, especially when you think about how much code we would have written after about 10 or 12 of these by hand. When you start to put these types of conventions in your entire codebase, they add up to a lot of time savings. Just another example of how working smarter, not harder can make your life a little bit easier.

        

          

              
public class BasicFilter 
        {
            public Guid? ClientGroupId { get; set; }

            [LikeQueryFilter(ComponentModel = typeof (Address))]
            public string AddressCity { get; set; }

            [QueryFilter(ComponentModel = typeof (Address))]
            public string AddressState { get; set; }

            [QueryFilter(ComponentModel = typeof (Address))]
            public string AddressZip { get; set; }

            [LikeQueryFilter(ComponentModel = typeof (Address))]
            public string AddressLine1 { get; set; }

            [LikeQueryFilter(ComponentModel = typeof (Address))]
            public string AddressLine2 { get; set; }

            public int? ClientId { get; set; }

            public long? PropertyId { get; set; }
            
            public Guid AssignedToUserId { get; set; }
        }
          

          

            view raw
            BasicFilter.cs
            This Gist brought to you by GitHub.
          
        

        

          

              

public class FilterQueryBuilder
    {
        public IEnumerable<ICriterion> CreateFilter(object filter, Type objectToFilter)
        {
            var criterion = new List<ICriterion>();
            var props = filter.GetType().GetProperties();
            foreach (var pi in props)
            {
                var val = pi.GetValue(filter, null);
                if (ShouldNotAddToFilter(pi, val)) continue;
                var queryAttribute = (QueryFilterAttribute) pi.GetCustomAttributes(typeof (QueryFilterAttribute), true).FirstOrDefault();
                if (queryAttribute == null)
                {
                    criterion.Add(new SimpleExpression(pi.Name, val, "="));
                    continue;
                }
                var name_to_return = GetNameFromAttribute(queryAttribute, pi, objectToFilter);
                criterion.Add(queryAttribute.GetCriteria(name_to_return, val));
            }
            return criterion;
        }

        static bool ShouldNotAddToFilter(PropertyInfo pi, object propertyValue)
        {
            if (propertyValue == null) return true;
            if(pi.GetCustomAttributes(false).Any(x=>x is NotAFilter)) return true;
            return pi.PropertyType == typeof (Guid) && (Guid) propertyValue == Guid.Empty;
        }

        static string GetNameFromAttribute(QueryFilterAttribute queryAttribute, PropertyInfo filterProperty, Type objectToFilter)
        {
            if (queryAttribute.ComponentModel == null) return filterProperty.Name;
            var filter_property_name = filterProperty.Name;

            var filtered_type_property_name = objectToFilter.GetProperties()
                .Where(info => info.PropertyType == queryAttribute.ComponentModel && filter_property_name.StartsWith(info.Name)).First().Name;

            var component_property_name = filterProperty.Name.Replace(filtered_type_property_name, "");
            return filtered_type_property_name + "." + component_property_name;
        }
    }
          

          

            view raw
            FilterQueryBuilder.cs
            This Gist brought to you by GitHub.
          
        

        

          

              
    public class NotAFilter: Attribute
    {
        
    }

    public class FilterGroup : Attribute
    {
        public FilterGroup(string displayName)
        {
            DisplayName = displayName;
        }

        public FilterGroup()
        {
        }

        public string DisplayName { get; set; }
    }

    public class QueryFilterAttribute : Attribute
    {
        public virtual ICriterion GetCriteria(string propertyName, object val)
        {
            return Restrictions.Eq(propertyName, val);
        }
        public Type ComponentModel { get; set; }
    }

    public class LikeQueryFilterAttribute : QueryFilterAttribute
    {
        public override ICriterion GetCriteria(string propertyName, object val)
        {
            return new LikeExpression(propertyName, val.ToString(), MatchMode.Anywhere);
        }
    }

    public class DayPrecisionDateQueryFilterAttribute : QueryFilterAttribute
    {
        public override ICriterion GetCriteria(string propertyName, object val)
        {
            var value = (DateTimeOffset) val;
            return new BetweenExpression(propertyName, value, value.AddDays(1).AddMilliseconds(-1));
        }
    }

    public class IgnoreFilterAttribute : QueryFilterAttribute
    {
        public override ICriterion GetCriteria(string propertyName, object val)
        {
            return new NotNullExpression(propertyName);
        }
    }
    
    public class GreaterThanFilterAttribute : QueryFilterAttribute
    {
        public override ICriterion GetCriteria(string propertyName, object val)
        {
            return Restrictions.Gt(propertyName, val);
        }
    }
          

          

            view raw
            QueryFilterAttributes.cs
            This Gist brought to you by GitHub.
          
        

Using StructureMap from IronRuby StructureMap can be loaded and accessed from IR without difficulty. But I find the syntax to use generic methods in IronRuby a bit noisy. So I made a simple module that wraps the StructureMap generic methods. We see these used in a minute.

require 'StructureMap'
include StructureMap
#module to hide the IronRuby generic noise
module ObjectFactoryModule
    def get_instance type_name
        ObjectFactory.method(:get_instance).of(type_name).call
    end
    def inject(type,instance)
        ObjectFactory.method(:inject).of(type).call(instance)
    end
    def eject(type)
        ObjectFactory.method(:eject_all_instances_of).of(type).call
    end

    def replace(type,instance)
        ObjectFactory.method(:eject_all_instances_of).of(type).call
        ObjectFactory.method(:inject).of(type).call(instance)
    end
end

Config files are your enemy

Because IronRuby runs in its own AppDomain, it is impossible to directly access your config files from IR without some serious hackery. But this it is not impossible to get around this if you encapsulate application settings behind an interface, with the default implementation getting values from configuration files. We have a very simple interface:

You can create a ruby class that implements the IApplicationSettings interface by including the interface.

require 'PropertyRegistration.Common'
include PropertyRegistration::Common
include ObjectFactoryModule
class ScriptingApplicationSettings
    include IApplicationSettings

    def EventSourceDBConnectionString
        return 'Data Source=localhost;Initial Catalog=db;Integrated Security=SSPI'
    end
    def ViewModelConnectionString
        return 'Data Source=localhost;Initial Catalog=db;Integrated Security=SSPI'
    end
    def FasTrackDbConnectionString
        return 'Data Source=localhost;Initial Catalog=db;Integrated Security=SSPI'
    end
    def CurrentSessionContextClass
        return 'thread_static'
    end
    def ViewModelDefaultSchema
        return '[PropertyRegistration_ViewSource].[dbo]'
    end
    def LoadZipcodeDatabaseData
        return false
    end
end

Now here’s the cool part we can inject the ruby class into structuremap so that it will be the implementation of IApplicationSettings.

$LOAD_PATH << File.dirname(__FILE__) + "/assemblies"
require 'Rake'
dlls = FileList.new(File.join(File.dirname(__FILE__),"assemblies/*.dll"))
dlls.each {|f|require f}
require 'StructureMap'
require 'ObjectFactoryModule.rb'
require 'ApplicationSettings.rb'
require 'PropertyRegistration.DataLoader'

include ObjectFactoryModule
include PropertyRegistration::DataLoader::Application
include StructureMap

#bootstrapper, loading StructureMap registries and other stuff
BootStrapper.startup

settings = ScriptingApplicationSettings.new
# ejecting IApplicationSettings and replacing with ruby class
replace PropertyRegistration::Common::IApplicationSettings, settings

Now, we have loaded all of our assemblies, Called our bootstrapper to initialize StructureMap and everything else. Then we replaced the default implementation of IApplicationSettings with our Ruby implementation and our application is none the wiser. We can now use the IApplicationSettings from StructureMap as well as any classes that have it as a dependency.

exporter = get_instance(DataLoader::SchemaExporter)
exporter.generate_schema

There was more work involved getting everything to run from Rake, but this is the basic wiring and the other stuff is not really important.

I have bigger plans for using IronRuby with my applications. This was the first step. I’ll post more as my journey continues.

I started a new project this year and part of my responsibilities is gathering requirements and converting them to user stories and acceptance criteria.  It’s been a very interesting experience for me and put me a little out of my comfort zone.  I’ve been sheltered most of my career, with someone else there to drive out these requirements.  It’s actually taught or reinforced a lot of things that I think are very important.

Distilling to Minimum Viable Product

Before this project I was sharing office space at a startup incubator, where people with an idea were given some direction and focused on what they really need to do first as a startup: get customers.  One term I heard over and over was Minimum Viable Product.  What is the smallest thing of value you can launch with?  I’m taking the same approach with an enterprise application: what’s the smallest set of features you need to stop using you’re homegrown excel application.  The interesting thing to me is that I’m not just reminding the business owner, but also myself.

Do the simplest thing that works until it doesn’t

What’s the simplest thing you can do to solve the problem but also follows sound software design principles? I’m not saying you should cut corners on your architecture to complete the application quickly, in fact the opposite.  No matter how well you can elicit requirements from business owners and no matter how many thought provoking questions you ask, until users start using the application, the users simply won’t know everything they need until they start using the application.  By using a modular design that’s has easy to replace functionality you can keep the process simple and change it when you have better information

YAGNI

You Ain’t Gonna Need It.  It’s one of my favorite acronyms, but it’s harder to adhere to than you might think.  When you’re gathering requirements you often hear about things the business owners want to do in the future.  Plus it’s just in our nature to build in everything we can.  It takes a great deal of restraint to build an application that is useful in 3 months instead of the perfect solution in 8.

The 80 / 20 Rule

This is probably the most difficult thing for programmers to remember: not everything has to be solved in the application.  Today we we’re hashing out the stories dealing with escalation.  There were one or two scenarios where the person handling escalation couldn’t solve the problem themselves, but needed either a manager or some other team member to do something.  There’s no doubt this could be done within the application, but the reality was that it would just be faster if they asked the person either in person or on the phone or in an email to make the change for them.  Since it was only one or two cases out of 15 or 20, it didn’t make sense to have this part of the minimum viable product.  

It’s possible that our analysis is wrong and it happens way more often than we think.  But at this point we don’t know and trying to build it now would add weeks to initial deployment.  There are plenty of cases where it’s just better to handle edge cases outside of the application.  The important part is to gather data so that you can either confirm or refute your original hypothesis

Metrics

A lot of assumptions are made during the initial development of an application.  You need to be able to validate those assumptions and one way to do that is to gather as much data about usage as you can.  From click throughs to thorough logging, capturing usage data is crucial to find the holes in your initial assumptions.

We’re one of the few professions where it’s okay to build something with imperfect information.  We have the ability to improve our designs after people start using it.  It’s okay to get a few things wrong as long as you design your system so that you can make changes quickly.  Low coupling, design by contract, and high test coverage help you do that.   By applying restraint in our design and architecture and incrementally improving applications can lead to really great software

Kyle mentions that in his application, he still has a very anemic domain model and most of the work happens when a command is processed. However, it’s entirely possible to use a full domain model with the commands, and really make things easier in the long run.  The commands do the same job the service methods did: collect information necessary for the domain models to do their job.  Once that’s done, the info should be passed to your domain model to determine what to do with it.

There are two reasons (that I can think of) why I think anemic domain models will cause problems in command based architectures.  First, just as with service layer architecture, if you’re service layer is making decisions about what state your domain objects should be in, then the only way you can change the state of your domain object is by processing a command.  Another problem is that, while using commands, makes it easier to understand what each command is doing, it also hides the process somewhat.  When a command executor is responsible for finding the correct command to execute, it can be more difficult to manually fire off the correct command to execute.  If there is important logic hidden in the command, it is more likely to be duplicated rather than referred.

Regardless of whether you use a Service Layer or a Command Processor architecture, the important part is to keep all of the logic that keeps your domain objects in a valid state within the domain object.  This will promote the reuse of logic, increase the cohesion of you domain objects, and reduce the coupling to other components to maintain proper state of an object through it’s lifetime.