After Justice Gray’s bubbling fan boy review of this book I thought I should go and check it out. I have to say I almost share as much enthusiasm as he does.

I found the book really well written and concise. The book goes though many of the things I have learnt the hard way like duplication is evil, designing by contract, minimize coupling, and a bunch more. I found everything hits the nail on the head without killing the hammer. I never found myself disagreeing with the book or thinking something should be added. To me that is pretty impressive for a book to do things that well.

I feel that this book should be required reading in programming courses. Its a fast read, there is no code, and nothing really that hard to understand. What it does provide though is a lot of wisdom and junior programmers always need wisdom (and lets not fool ourselves, intermediates and seniors as well). If there was one book I would hand a new developer it would be this book (followed by about 10 other books… but that is another post). So if you have not checked it out yet go pickup a copy of The Pragmatic Programmer.

The 2nd annual Edmonton Code Camp is going to be held on October 20th, 2007 at the UofA. I must say I am excited on this one! Maybe because a bunch of us are fresh off the ALT.NET or maybe becuase I am finally doing a full fledged presentation here! Either way I am looking forward to all the great conversations and questions to be had.

Last years camp was really well done so this one should be even better. The organizers have added another track bringing the total up to three. This has allowed for five more sessions to be done. Hopefully you are not too torn between which talks to go to and if so there is no harm moving half way through. The lineup of speakers also looks really good again this year with lots (or maybe all) of presenters from Edmonton or Calgary.

The schedule is still being worked out a bit but keep checking http://www.edmontoncodecamp.com/ for sessions and updates (also make sure to register if you plan on going).

BTW, my talk will be on implementing partial trust in ASP.NET to easily reduce the attack surface of your application (yes I combined security and easy).

Hope to see you all there!

Executable Requirements

I really had never heard the term Executable requirements comming into this talk so thought I would see what I could learn. An executable requirement is a requirement written in such a way that  user (or BA usually) can read / write it and it can also run against our code to test it. FIT is the best example of this.

Some people here have used fit/fitness but most people have had pain with it (FITNESS is the wiki. FIT is the dll)
-Refactoring with fitness was hard
-It turns into a lot of overhead
-There are problems with source control (TFS/VSS can not be done.. well Jeremy says it can be done)
-CI integration is hard

Where FIT Shines: table type testing (similar to row test from mbunit), the realm of primitives (strings ints, dates,etc) it tests really well.

Testing objects are not so easy.

“remember refactoring with nmock? FIT is just like that but worse” –Jeremy Miller

We then had a look at nbehave. nBehave was inspired by rBehave which was done on ruby. With nBehave the story is in the code and done with a fluent interface.

transferStory.AsA(“savings accountHolder”).Iwant(“To withdraw”).SoThat(“I can buy things”);
transferSwroty.WithScenario(“Creidt account”).Pending(“ability to withdraw”).Given(“my balance is”,400).When(“I writhdraw from my account”, 100).Then(“my savings account balance should be”, 300);

 We went on about this for a bit but I really did not like it. The person who got up to talk about this said that it what they were doing was sitting with the BA and writing out the story in a fluent interface and then having a coder go in and wire in some code.

I was feeling a bit over my head as I never played with this tool and the discussion really went into how to use it. I have a feeling that I will not be using this anytime soon so decided to pop over to check out some of the other talks. There is not much to write about them as I missed a lot of the beggining context.

The closing of the day was really good with all of the attendies going around in a circle giving a 30 second blurb about what they thought of the conference. Lots of good points came out of this and Scott and I have some video of peoples thoughts that we will hopefully get put up somewhere for any of those interested (I only got about 10 minutes as I ran out of memory and Scott got more but ran out of battery)

Spreading ALT.NET

The guy who is running(?) MSDN mag was here and really wanted to learn about the community and bring some of these ideas into the magazine. This was good as there is lots of talk about the divide between alt.net and Microsoft so this is a positive sign coming from MS.

James Kovacs had a good point that e are in an echo chamber and need to find how to spread the word.
Some ideas to do it:
-Speaking at user groups
-INETA speakers bureau
-Codezone
-Tying it to MSDN
-Including open source tools and techniques  in sample apps
-Focus on concepts, not specific frameworks
-When showing a solution, make sure that you explain the problem
-Linking to existing content vs. Writing new stuff
-Show unit tests in your demo (and show things breaking too)

When MS does something (i.e. introduce the entitiy framework) then ORM mappers will become really popular.

We broke into a bit of a debate that when you take certification you do not have to take any test on OO. Some of this breaks into that it is hard to determine what a right answer is programmatically.

There is an agile developer center on MSDN. It actually links to more external content than internal MSDN content which is good. You can get to it from http://msdn.microsoft.com/architecture

Peter also said that they were like us and that they are here because they are interested in this stuff. They are not here to spy on us. They are here to learn with us.

PnP has a cool thing called “Work at PnP”. They will pick up a development shop and move them to their office and work with them for a week to learn and teach in the community.

Roy had the idea of having a critic column in MSDN that is basically the review of something that came out. Scott Bellware was volunteered.

Jeff Sutherland (sp?) had a good article with stats about introducing agile. The article showed a 50% increase in productivity after switching to test first

Someone had a good story that when they introduced testing/CI that it caught a bug before it went out. The dev who implemented it said “I just saved you $1,200” as that is the cost of a bug making it to production. By looking at the cost of a bug and the cost of a solution is really good

MSDN might be introducing screen casts for people too.

We also said that we are talking about stuff we knew two years ago. We assume that what we are doing that everyone knows it. This is not the case. I showed nunit to someone and they were amazed. We need to keep talking about what we know and realize where we sit on the curve really.

We need to unify all of our knowledge into a site. If people write for MSDN then they can link to that site.

DDD-itsu

Ok I feel over my head here to start out with. Mostly because I have not done DDD on a project (well to its full extent).

There was debate over:

Account.depoit / account.withdraw
vs. A service implementation like:
WithdrawServier service = new WithdrawService(account)
service.withdrawAmount(100)

Which was an interesting debate but really comes down to implementation and complexity. Account.deposit/withdraw does violate SRP but on the other hand when you are modeling the domain I think you should be MODELING THE DOMAIN so an account can do deposits / withdrawls (IMHO)

The debate was expanded in more detail to this:
public class TransferService
{
  function Transfer(from, to, amount)
  {
       from.balance -= amount
       to.balance+=amount
  }
}

or

Public class Account

{
Transfer(amount, to)
{
    this.withdraw(amount)
    to.deposit(amount)
}

}

By doing the service method we have a lot more classes
by the account model the object is only dealing with another object of its same type

So all of these are right but easily debatable

Someone said that DDD is “Capturing ubiquitrons”.

“A diagram is the representation of the model”

We then moved on to defining some terms within DDD:

An entity is an object with identity and state

A value object does not have identity. i.e. currency (public class money) and are usually immutable

A cluster of entities is an aggregate: i.e. order and line item

Repository

Repository controls the retrieval of an aggregate root. Usually a few methods like findOne, findByQuery, handle saving of aggregates. There is usually one repository for each aggregate root.

Module

A module is an encapsulation. It may be that we model two separate things that do not interact (or interact minimally). This can be done with namespaces or separating them by assemblies.

ASP.NET MVC

I had no idea that Microsoft was coming out with an MVC (Model View Controller) implementation . I am kind of excited about this one (everyone else was too as everyone came to this session, seriously… everyone was here). I have tried playing with monorail and have not been terribly impressed so hopefully something a bit more integrated and refined would be good. Whether MS pulls it off remains to be seen.

This is one hard to blog about unless you have used an MVC implementation like rails so I will talk about other stuff.

I have liked a lot of the attitudes about this project. Things seem quite pluggable, you can change the view engine, implement your own IOC container, do unit tests with no asp.net runtime required. At the end of the day Scott put it well in that “MS finally is putting out a web framework that focuses on testing”.

There is an alt.net vs. MS undertone here and am wondering if people just came to see Scott vs. Scott. We were discussing at lunch how MS seems to create an implementation of mature open source projects but they are not as good as there open source counterpart.  There is already good unit testing frameworks yet they create msTest which does less than the open source tools do. I am thinking that it might be the same with MVC

It came up that you have to specify the view to render i.e. RenderView(“HelloWorldView”) from the HelloWorldController. In other implementations the view is tied to the controller as they share the same name. Scott brought up the point that MS should not do it this way as every other tool does not so why introduce it (unless there is an advantage to doing it)

All in all the MVC framework looks quite promising and I can not wait to try the beta (in 6-8 weeks it may be coming out). If it works well I hope that it can help drive MVC and better testing/separation of responsibilities out into the community at large.

Lunch was some big tasty sandwiches but the talks were better. We got onto the topic of parallelism which was quite interesting.  Scott Guthrie  got up onto the whiteboard to talk about scaling applications

List<person> people
for(i=0;i<people.Length(); i++)
{
   person.DoTask();
}

this code will not scale as the interpreter cannot easily split this code across processors. As a programmer you may be able to write some code that starts new threads and does locking but it might perform even worse (due to managing your locks) or might work on two processors but will not scale up to 400 cores

The power comes from lamda expressions and extension methods  in .NET 3.0
people.With(p=>person.DoTask())

By using this technique the compiler should be able to split the tasks across cores/processors. Note that the .net framework does not do any balancing across cores/processors but by this is the best way to deal with parallelism in the future (Well this week anyways)

A few of us had a talk about why we should worry about parallelism. If you have a task that needs to perform well then it is obviously to your advantage to program for multiple cores. The point I brought up is that if you have a simple task that 100 people are using simultaneously then each person will run one after another (basically). If you code to make it parallel you will not get much advantage. The advantage will be that the OS will more of the simple tasks simultaneously so that there is not a huge queue. Trying to use multiple cores in this scenario might actually hurt performance as now more cycles are spent allocating and managing threads instead of just allocating a core/user. Either way you have to be careful and think about these things.