Archive for the 'Development' Category

Setting up a FubuMVC Project from Scratch

I am going to start a series of articles on using FubuMVC for web projects. I have several reason for writing these, one of which is FubuMVC has a lack of documentation right now, so these articles will help out that cause. Also I am starting to do mostly web work, and want to do these apps with FubuMVC as opposed to Asp.net MVC. (This is purely for personal reasons).

Upcoming Topics:

Setting up the Bootstrapper and Global.asax
Creating Models, Views, and Controllers with FubuMVC
Adding database connectivity
Using HTML helpers

I will most likely cross post these to the FubuMVC wiki once they are refined and final, so if any of you have comments, ways to do things better, or find things I should explain or do differently, please leave me a comment.

Before You Begin

Before you start your setup, head over to the FubuMVC website, grab the latest version of the source and compile it. This way you will have the references I am using below.

Project Setup

The first thing you need to do is go setup your project and folder structure. I am not going to detail the process here, because most people have thier own preferences and naming conventions but for my sampl I will be using the following folder structure:

  • FubuSample
    • lib
    • src
      • FubuSample.Core
      • FubuSample.Web
      • FubuSample.Tests
      • FubuSample.sln

    You may have noticed above that I am using three different projects: FubuSample.Core (class library), FubuSample.Web (Web Application) and FubuSample.Tests (class library). Setup these projects and we will move on, mine look like this:

FubuSampleProjectSetupv1

Got it, great. Next thing I am going to do is add references required for FubuMVC to work. I added the following references to my projects:

    1. FubuSample.Core
      1. FubuMVC.Core
      2. FubuMVC.Container.StructureMap
      3. StructureMap
      4. Microsoft.Practices.ServiceLocation
    2. FubuSample.Web
      1. FubuSample.Core
      2. FubuMVC.Core
      3. FubuMVC.Container.StructureMap
      4. StructureMap
      5. Microsoft.Practices.ServiceLocation
    3. FubuSample.Tests
      1. FubuSample.Core
      2. FubuSample.Web
      3. FubuMVC.Core
      4. FubuMVC.Container.StructureMap
      5. NUnit.Framework
      6. Rhino.Mocks
      7. StructureMap

Once all the references are are in your 3 projects, you are almost ready to get going. The next thing to do is to setup a basic folder structure inside your projects. In the web project I added a Views folder and a Content folder; under the content folder I added seperate folders for images, scripts and stylesheets. Moving on to the Core project I added top level folders for  Config, Domain, and Web. Under the Web folder I also added folders named Controllers, DisplayModels, Html, and WebForms. My folder structure now looks like this for my projects:

FubuSampleProjectSetupv2-AfterFolders

Next up, setting up the Bootstrapper, Global.asax and Web.config for FubuMVC

TeamCity - Build failed on WPF Unit Tests

I have been working today with Jeremy Millers’ ScreenBinder stuff and ran into a problem today with the tests. The tests all passed fine in Visual Studio, and with rake at the command line on my computer. The problem however came when I checked the code into source control, I got a nasty test failure message in TeamCity:

 

BuildError

Here is the error: Test(s) failed. System.Runtime.InteropServices.COMException : The program issued a command but the command length is incorrect. (Exception from HRESULT: 0×80070018)

So I did some googling around and found there is a bug in the .NET Framework 3.5 SP1 regarding this issue. So a little more work and I found a work around. I believe this bug only pertains to WPF stuff.

 

Workaround

On the build agent do the following:

  1. Stop the TeamCity Build Agent service (Start –> Run –> services.msc –> TeamCity Build Agent –> Right Click –> Stop)
  2. Browse to the service file (C:\TeamCity\BuildAgent\launcher\bin)
    Files1
  3. Right click TeamCityAgentService-windows-x86-32.exe and click Properties
  4. Go to the Compatibility Tab
    Properties1
  5. Click Show settings for all users
  6. Change the Compatibility mode to be Windows XP (Service Pack 2)
    Properties2
  7. Click OK a few times to close all the windows
  8. Start the TeamCity Build Agent service.

You should now have a working build with WPF unit tests. Hope this helps somebody out as I was banging my head on the wall trying to figure it out.

Success01

CSLA - first base was fun, but I want a relationship

The scene opens on a typical fall Saturday evening at the local sports bar filled with enthusiastic football fans cheering loudly at the myriad of TV screens scattered around. In one small corner sitting around a high table is a group of people visiting about software development. Two guys, eager to make friends, walk up introduce themselves and let slip they’ve been developing software with CSLA for the past few years, and are looking for redemption.” The rest of the table then looks at each other and responds in chorus, “I’m Sorry!”

 

The shock on their faces at the collective “I’m Sorry” was a bit much. They knew some people have very differing opinions about different frameworks and tools, but hearing it confessed out loud was a breath of fresh air.

Recently our development team decided to stop developing with the CSLA framework. Before I get into specifics, I want to be very clear about something up front. I have no problem with people that continue to use CSLA. We used CSLA for nearly 4 years and it has worked in way it was designed.

 

While Hiren and I were at KaizenConf in Austin we made sure to find a few minutes each evening before getting caught up with a large group, to recap the day and share some new things we each learned. One of these nights while relaxing and evaluating what we’d been learning we came to the conclusion that it was time for us to step away from new development with CSLA and migrate existing codebases as well. Over the past week we have been outlining and discussing these ideas and why we have made the decision to move away from CSLA.

 

It all started a few months ago when we first started getting introduced to the Alt.Net ways of developing software. What I mean by the Alt.Net ways are things like S.O.L.I.D. principles, ORM use, unit testing, Domain Driven Design, Mocking, TDD, etc… All of this has really changed the way we think about and develop software. Even before this though Hiren and I made a very dangerous combination of developers because we are never satisfied with a piece of code once it is written, we usually have to talk one another into just leaving it alone because it works and is as good as it needs to be to get the job done.

 

There are several driving forces behind this decision, but the primary one is that our CSLA business objects just leave a bad taste in our mouth. Our systems are moderately complex and it is not uncommon at all to have a class with 1500 – 2500 lines of code, in fact that is probably an average line count in most business objects. The other thing that really smells to us is that the “model” contains a lot of stuff that is not directly related to the model, namely data access.

 

I would like to take a minute to point out some of the things I really like and will miss about CSLA, and some of the other reasons for making the switch.

 

 

CSLA, I will miss some of you:

  • Validation Rules System
  • Data binding Support
  • Combo of these == reach UI validation for user
  • Good set of guiding principles and samples to get started with.
  • Rocky’s Books!

I won’t miss these parts though:

  • Data Access code in business object
  • Difficult to mock out data access in mocking
  • N-Level undo – I never, ever used this but had to contend with it, like it or not
  • “Super” Classes

These are purely my opinion so take them as they are. I still think CSLA has a place for some people and unlike others I have run into on the internet, I will not bash you or think you are stupid for using it. CSLA was an excellent stepping stone for us; it introduced and really engrained the Object-Oriented Programming style of thinking into our minds. I/we just feel like we have matured to a new level of development through better understanding of our software development process and how apply those skills to our situation.

 

We are still learning and don’t yet know exactly what our development style is going to be end-to-end on this project. We have a long way to go before we are completely comfortable with all these new tools. Luckily, the Alt.Net community seems to be an open and accepting group and nearly everyone is willing to help us out along the way.

What I do know is that no team can just take what one person or one book says and do it that way. It won’t work. What we are doing is educating ourselves on different practices and tools and using what works for us, we do a lot of spikes right now. We are also building our domain model with POCO’s which gives us a great amount of flexibility in the infrastructure and presentation layers of our system. As we continue this process I will post successes and failures here on my blog.

Lean with Kanban is Not One Size Fits All

I have to say that I am very excited about all the lean software development process talks that have been buzzing around in the community lately. This is generating lots of good first hand experience that is being shared with the community which I think is excellent. I would like to talk about two main points tonight, a pet peeve of mine that I just need to rant about for a few lines and second I would like to point out some of the other great stuff that is out there and discuss it a little.

Lean is the Process, Kanban the Tool

I personally think that a lot of people equate Kanban as beingBedSupermarket1 the methodology or even worse an equivalent replacement to Agile or Scrum. This is absolutely not the case, KanBan is not even a methodology like the others. This is a very important point that is often overlooked, especially when new people are trying to learn and apply Lean practices in their software process. Kanban is a Japanese word meaning literally “Signal Card” or “Signal Board”. A Kanban board is just a visual tool used to signal flow and show limits of the process and to create the signal for the pull flow of the system. Derick Bailey has a great easy to understand example of a Kanban in the shape of a grocery store over on his blog. I work for a Lean Manufacturer and we don’t use a “Kanban” in the traditional sense per say because we do not pass cards around the manufacturing floor, we do however use signaling and that is what KanBan is really all about. We refer to our signaling system as our “Supermarkets”, what these supermarkets are actually physical spaces in the production area that are designated for certain types and variations of product.  When a supermarket has an empty space, somebody up the process builds the product to refill that supermarket. To the right is a picture of one of our actual supermarkets, this is a bed supermarket.

 

 

Whether you are using cards, boards or supermarket’s the most important thing is that it is creating a signal in the pull system, and this enables flow. The two other really important pieces that Derick does a good job explaining are Order Points and Limits with his grocery store example so I won’t go to far in depth on this. These are two very basic items that every inventory management system has or should have at least. You obviously wouldn’t waste money shipping one box of cereal from General Mills every time a custom took one off the shelf. These just provide a way for the store or the development team to manage the amount of inventory they carry.

 

I kind of got carried away on what a Kanban was so let me get back on topic. A KanBan could be useful for various methodologies I think but it really shines if you are doing Lean Software Engineering. Lean is the methodology and I think there is a fear rising up within the software community that a lot of teams are just going to “Cargo Cult” this stuff and it really doesn’t work that way. Lean is a way of thinking, just like many of the Alt.Net principles. There are no hard and fast guidelines to implement Lean in 14 days, it is a process and takes time. Even then if you are practicing lean you will never stop implementing lean. I will get off my soap box but I just want people to know the difference between the tools and the methodologies.

Lean comes in Different Sizes

This is what I am really excited about right now. I know of 3 people currently implementing (or hoping to) Lean in their teams right now. The best part of this is that we are sharing the processes that we are following to make this as open as possible for other teams to follow along with. This is great because we are all in different teams, sizes, makeup, skill level, etc… So we should see some very different yet exciting results come out of all this. I committed to documenting my implementation at KaizenConf and have started with a few posts on what I have done so far. Louis Salin also has a series of great articles on his blog that are a recap of several sessions from KaizenConf combined with his own thoughts on this implementation and guess what, It isn’t that much different from the rest of us, only it is his way, which is awsome!

 

Louis Salin – The bag and the Kanban:

  1. The bag and the Kanban, part 1
  2. The bag and the Kanban, part 2
  3. Activity Modeling and the bag

Louis has got some great ideas here, especially the bag idea. This is something very similar to what I have been thinking of / calling my “To-do” list. I will expand on this topic in a few days, we are currently re-working the way we deal with items before they make it on the backlog.

 

Derick Bailey – Adventures in Lean

Derick Bailey has just started his series, “Adventures in Lean”, and I think this will be very interesting to follow as well. Derick’s team is a larger team that I have for sure, and I think larger that Louis’ team too.

 

Ryan Kelley – Lean in Small Teams

I am documenting the Lean implementation in our team as we go along. I will continue to write about this, good things and bad so hopefully other people can learn from what we are doing. That said, we are a very small team, in fact if we were any smaller we wouldn’t be a team. Some may think that for a 2 – 4 person team you don’t need to do Lean but I say that is Bull****. One of the main reasons we are “Going Lean” is to bring some formality into a process that hasn’t ever had any before. We are probably the most disciplined department in the company with regards to how we work, so we need to share the discipline around a little and off-load more responsibility to the customer.

Until next time, I hope this as whet your appetite for more Lean / Kanban discussions.

Strongly typed Collections of Abstract Objects

Some of you know that we are in the process of not using Csla anymore, this is a decision that just seems logical for us, but that is another post. I need a little help implementing a problem in my domain. Now the sample I am posting is out of a dumbed down version I have been using to spike with. Take a look at the following class diagram and then I will explain what is going on and what my problem is:

Order-ClassDiagram01

What is going on here you ask? Order is the primary object type, but it is abstract. I have maybe 7 different types of orders, service order, make order, repair order, etc… each order has several attributes that are always present on every order. What makes each order unique is the attributes that are not shared between all orders. This is why I have decided to use inheritance.

One of the items that are common between all types of orders is that they all have many parts. However, I want the base Order class to have a collection of base OrderPart objects. OrderPart is the mapping object in between Order and Part for the Many To Many relationship, I am using an object because this association has state of it’s own. Now to complicate matters even more, each concrete Order can have a different concrete type of Part and OrderPart assigned to it.

I have the model all setup and Have written some tests against it as I wrote it, not really test first but hey, I am spiking here. So below is one of the tests that shows most of this in action.


public void CanCreateOrderWithCustomerAndParts()
{
var order = new CustomOrder();
order.Customer = new Customer
{
Name = "John Smith",
Address =
new Address
{
Street = "45623 Easy",
State = "TX",
City = "Dalals",
ZipCode = "73884"
}
};
order.OrderNumber = "Y984939";
order.Amount = (decimal) 1234.33;
order.CustomOrderDescription = "Testing adlkfjl 123";
order.Parts =
new List
{
new CustomOrderPart
{
Part =
new CustomPart
{
PartNumber = "Part456sdf34",
Description = "Test Partasd 87",
CustomPartText = "TEST",
},
Quantity = 12
},
new CustomOrderPart
{
Part =
new CustomPart
{
PartNumber = "PARTWITHNULLPULLLOCATION",
Description = "Test Part 848sasd8243",
CustomPartText = "TEST",
},
Quantity = 251
}
};

With.Transaction(() => Repository.Save(order));

Order createdOrder = Repository.Get(order.Id);

Assert.IsNotNull(createdOrder);
Assert.AreEqual(2, createdOrder.Parts.Count);
}

Don’t make fun of my test code, like I said, it’s a spike. But when I create a CustomOrder I am creating Parts as a new List<OrderPart> which is how it is implemented. But then I had new CustomOrderParts and CustomParts into that collection. NHibernate will persist this information correctly into the database and will retrieve it correclty from the DB. So seemingly all works fine right, sure I guess. Maybe it is just because I have been in Csla land so long that I don’t know any different but what I am really missing is being able for the concrete order object to know what concrete type of  OrderPart is contained in the parts collection. As I wrote that I just kicked myself, if that isn’t a violation of Seperation of Concerns I don’t know what is, or is it? I mean Order or a concrete Order is basically an Aggregate Root in DDD terms so it is the responsible entry point into the chain/web of objects that make up the aggregate.

So, for my real question which I am not sure of now, How would you tackle this design problem? How do you handle child collections? Am I just way off the reservation?

NHibernate Caching Explained, finally!

Gabriel Schenker has just posted an excellent article explaining in detail how to the 1st and 2nd level cache in NHibernate works. This is a long overdue article on caching that will greatly benefit the community. The article also explains the differences between Get(id) and Load(id) when retrieving entities through NHibernate. I am recommending this article because it is an in depth look at one of the pieces I covered earlier on Ayende’s session from KaizenConf.

DDD - Just reading book

When I got back from #KaizenConf I had to order a copy of Eric Evans book, Domain-Driven Design: Tackling Complexity in the Heart of Software. Main reason being that I went to a DDD session Dave had and learned a lot that just made sense so I figured it was a must have. So I ordered it, got it and have been reading it the majority of the weekend and I must say it is a very good book. For me though a lot of has been just giving formal names to the things we were already doing. Most of this is because we are a small team/company so we have always been the developers/business analysts etc…. But overall very good so far with good emphasis in the right places I think.

KaizenConf Wrap

I know this is a little late and somewhat out of order but I really feel compelled to write a public thank you note to all of the facilitators and attendees at the pre-conference workshops and the KaizenConf open spaces conference. I have made a boat load of new friends in the ALT.Net community that I know will be long lasting and very fruitful. The 4 day conference was by far the best conference I have ever been to. I came with so many questions got some answers and left with even more questions. It was very humbling to be surrounded by a lot of smart people, at the same time it is also very encouraging because these people are all very nice, friendly and real.

 

Workshops

The workshops that were put on were outstanding. I personally attended the Advanced NHibernate talk which was very helpful, you can see my notes here. I also went to the DDD Chalk Talk on Thursday afternoon, this was a very good talk about different aspects of Domain Driven Development. Friday started off with Jeremy and Chad’s Opinionated ASP.Net session and followed up with Dave’s Pull Don’t Push - Lean Systems and KanBan. All of these sessions were great. I have linked to what information is available now, and will link more as I find it.

 

Open Spaces

Friday night we “Opened” the space and one of the topics I suggested is Lean software engineering / KanBan with a small team. I didn’t know if anybody would vote for my topic or not but low and behold they did. So at my first open spaces event, I was also the convener of a space. This was a little bit intimidating at first but I handled it very similar to the way I do my college classes, we just all talked. Special thanks to Dave Laribee, Chad Myers, Chris Bilson and others that I don’t know your names, for being so involved and speaking during this session.

 

I spent time in some other very good sessions such as KanBan Applications, and Concurrent Set Based Software Engineering. There were so many good topics that I can’t even remember what all they were,  but there is a full list on the wiki.

 

As an action item on Sunday with KanBan in Small Teams I committed to documenting my teams implementation of the Lean Methodology with a KanBan task board.

 

In conclusion, Thank You again to all the great people in the Alt.Net community that came together in Austin to make this a very memorable event.

LEAN -Software Development in Small Teams - Part 1 – Value Stream Mapping

As promised at KaizenConf in Austin I am going to document our implementation of Lean Software Development as we go through the process of eliminating waste and creating a flow or pipeline process. We are in a unique situation as the rest of the organization is already following a LEAN approach for the most part due to the fact we are a Lean Manufacturer. So upon our return today we have gotten some guidance from internal “Lean Experts” and have started the process. The very first thing we did is two Value Stream Maps (VSM), this has helped us identify a couple of things already in the short amount of time it took to create them.

Value Stream Maps

I am going to first show the VSM’s and explain them a bit, then I will share some lessons learned already. Since we are a small company the IT department and Software Development department are one in the same, as in we do both. This means I need to have some value stream maps for both areas of concern. The VSM’s we created today are based on an average for each area. As we start and complete work in these areas I will create more VSM’s so that I have a better understanding of just where our waste and value times are and what happens in each. The way I like to create my value stream maps is that a box represents Value Add and a line represents no value add. Each box or line is then given an amount of time that a request/feature stays in that area.

Software Feature VSM

SW-Feature-VSM1

This is the VSM for a feature request in our company and it flows like this:

  1. Customer Request comes in, usually via phone or email
  2. Request enters To-Do List
  3. Feature undergoes Design and Analysis
  4. Feature enters Backlog
  5. Development/Testing is done
  6. Feature waits on customer approval
  7. Dev/Test any fixes
  8. Demo the feature with Customer
  9. Release feature
  10. Done Done

IT Request VSM

IT-VSM1

This is the VSM for an IT Request in our company and it flows like this:

  1. Customer request comes in, usually via phone or email
  2. Request then undergoes a quick Severity Check to determine how critical it is
    1. This gets a little interesting now as the path splits into two different paths, one for low or regular priority and one for high priority. The only thin different is the amount of time spent in each area.
  3. Request enters To-Do list
  4. Request is analyzed
  5. Request gets worked on (WIP)
  6. Request is complete.

 

Just creating these two value stream maps has identified a few errors that need to be worked on. The first area is Customer request, we need to create a standard way to handle requests. This should also put more responsibility on the customer than just accepting, “I need you guys to make X”. Second thing is that the VSM for a software feature is really just a guesstimated average right now. We have to work very hard to create like sized items to go on the KanBan board, which I will post about in a bit.

I have also lost my virginity (and you should too)

UPDATE: I have lost my virginity in regards to attending my first software conference, just in case that wasn’t clear… you know who I am talking to.

I just read Brian Mavity’s latest post and am obviously rowing the same proverbial boat that he is. This is not only my first software development conference but the first software development conference our company has ever sent anybody to. I personally have already taken more away from this than I ever imagined. Just sitting around at dinner or socializing with the same people whose blogs I follow is somewhat intimidating, but they are all very welcoming and want to help us new guys get going. I have had conversations (okay, mostly absorbing) with Ayende, Chad Myers, and Jeremy Miller. I have also been able to speak one on one with others and will most definitely get the opportunity to do some more.

Same as Brian Mavity, if you your company does not care enough about their development team to spare a little time and money to get you involved, you should consider finding a place that does or making your voice heard better to accomplish this.

I am really looking forward to the next few days worth of activities.

Next Page »