So the build broke based on a unit test that failed.  Is the general rule of thumb that the build breaking check in person fixes the test?  What if they did something that broke someone else's test for something?

...hmm, the philosophy of project handling and management.

Today I have nothing to proffer or offer the world of the blogosphere, merely that I'm exhausted and going to gladly jump on my bike and high tail it out of the office.

Tomorrow is implement functionality and dependency injection on the UI day.  At least get started, as it seems our UI has gotten rather dirty the last two weeks of coding.  Time for the refactor.

I was running three virtual machines on my laptop and couldn't help but think, this is awesome.  I couldn't have imagined doing this 6-7 years ago.

That is three operating systems running in virtual machines.  Windows 2003, Windows XP, and of course Windows Vista.  All running hosted on a Windows Vista Machine - my laptop.  2+ Ghz and 4 GB RAM on dual 7200 RPM 200GB Drives.  Awesome to be able to work with such an environment.

...and I hate it.

Excel has a model, that seems to be broken all the time, and appears that there are a zillion ways to do things that are not a preferred way.  The most common situation seems that Excel either breaks, crashes hard, eats up on the memory, or some other monstrous thing happens to cause a day to go south.

But the reason I love Excel, and maybe it is the pack rat collector mentality I have sometimes is - you can put stuff in it.  It isn't just putting stuff in it, but arranging, formatting, calculating, and crunching the numbers is interesting to me.  For some reason, this almost seems odd, as if I should be bored silly.  But in all seriousness I really dig working with Excel.

That's my epiphany of the day.  Later I'll probably write something more useful for myself, but alas, I was thinking...

Recently a situation were I needed to pull out the dependency injection and inversion of control skills came up again.  The need for loose coupling in so many projects is vital to these patterns.  I was going to start writing an article, but then realized there are some really amazing ones out there.  They point out the reason for Separation of Concerns (SoC), Loose Coupling of UI Components, Controller Independence (free from proprietary UI code).  With that said, here's some links;

• http://en.wikipedia.org/wiki/Dependency_injection - Dependency Injection (DI)
• http://en.wikipedia.org/wiki/Inversion_of_Control - Inversion of Control (IoC)
• http://msdn.microsoft.com/en-us/magazine/cc337885.aspx - MSDN Article on these topics. Excellent read.
• http://www.code-magazine.com/Article.aspx?quickid=0705071 - Code Magazine Article written by Boodhoo - also an excellent read with great examples.
• http://martinfowler.com/articles/injection.html - Article on DI and IoC by the guru himself, Martin Fowler.

The VS.NET integrated build monitor is great.  This thing helps you keep track of your latest changes, the status of the build, and other information right at your fingertips.  If you're using ReSharper and NUnit (or other integrated test framework) you get even more functionality.

First just install the TeamCity Visual Studio Add-in Tool.  You can find it under the "My Settings & Tools" section of the TeamCity Web Application.  Make sure Visual Studio is closed.  You don't want it flaking out on Visual Studio and doing an "almost fully installed" installation.  Those are never fun.

As usual, it's a good idea to leave the path as the default.

Once the tool is installed open up Visual Studio.  In Visual Studio you'll find another menu is available now.  Click on the TeamCity Menu.

You got one option at this point.  Login.

Once you login the command button bar will come alive with newly active command buttons.  This is where the coolness begins.

Click on the two buttons the red arrows are pointing to.

You'll now have the Failed Tests and My Changes available at the bottom of Visual Studio.  On the My Changes screen you'll have up to the minute status of the build, the current changes, etc.  This makes it super easy, without another single tool open to keep up with what's going on with the build.

A quick tip o' the day, that really has nothing to do specifically with software development - but is none the less a very good tip.

Meetings can be awesome and useful, or they can be useless and wasteful at best.  There are a couple reasons;

1. Any meeting over 30 minutes is absolutely wasteful.  Too much is happening and most will fall in the gutter by the time the next meeting comes around.
2. Too many topics are being covered.  Attack particular points that can and will be covered and acted on.  Too many topics just means more complacency and lack of activity.  i.e. lower productivity.
3. People get bored.  Bored people means lower productivity.
4. People get frustrated.  Frustrated people mean lower productivity.
5. If a meeting can cover key points in 5-30 minutes than management is overdoing the key conversation points.

How does one resolve this problem?  How does one make sure they stay productive and help keep things moving?

1. 5-30 minutes, 30 being an absolute maximum.
2. 3 bullet point topics.  No more, maybe less.
3. Talk on the point, stay on the point, don't stray.
4. Once the three points are covered, summarize the meeting verbally, and break up to accomplish action items.

That's how simple it is.  Wash & repeat.

No point in getting all thought provoking, it is Friday.  So go entertain yourself.

• http://xkcd.com
• Important Life Lesson
• Playing the Devil's Advocate to Win
• Shopping Teams

Integration tests are dependant tests that go across boundaries; database to the data layer, UI to the client layer, Model Layer of the MVC to the Something Layer, and the list goes on.  These tests are not something that can be added to a build solution without first getting the various segments actually "running".  We then end up with several different issues;

• With the assumption that the unit tests pass, the integration tests should then fire.  This is a fairly straight forward need, have ordered tests run.  Unit tests always go first and then integration tests.  What is the best way to set this up?
• How does one launch things like Web Services, setup Databases, etc to test to in an integration point of view.  Something that can be repeated time and time again in a reliable fashion.  I've been using TeamCity, but in general how does one go about getting an application to actually deploy?

The best solution that I've come up with so far is to have the unit tests in the building solution and separate the integration tests into the actual Setup/Deploy/*.msi Solution.  When that solution is built, it needs to verify and deploy/setup the various parts of the application.  Since it is part of the functional requirement of this solution to be able to be deployed, the integration tests are "almost" a large scale application level "unit test".  Right?  Ok, so maybe I'm thinking to creatively but it should work.

I'll be putting a solution together to do just that and will find out then.

Subversion is in the entry title, but these really apply to just about any source control being used for almost any type of project.

1. Update every time a build is successfully completed on the server to assure you are using the latest and your code still builds locally.

2. Check in as frequently as possible.  Every 30 minutes is a good standard.  Make sure to get an update before hand to assure a good build before checking in.

3. When making edits that cause *.sln file changes make sure to check them in immediately before adding code files or anything else.

4. Keep in mind the virtual "state" and "revision" mind set that source control is built around.  It doesn't work like the regular file structure, but pretends to act that way.

5. When the build is broken, everyone should STOP checking in code immediately until it is fixed.  If need be everyone should participate in the fix.

6. Do NOT commit (check in) when the build is broken.  This only compounds any prospective issues and possibly drags out the build resolution.

Some more quick best practices for using source control.

Simple Rule:  Check in often, build often, and keep updated as frequently as you have code that builds.  This prevents merge conflicts, overrides, and other goofy nonsense that no one wants to deal with.

I would say it is a good idea to update every time a new successful build occurs on the build server.

Commit (check in) every time new working code is completed.  This should be every 30 minutes to an hour.  If not, you're probably working through tasks that are too big at one time and the tasks need to be broken down further.  This is also a sign that TDD is not being followed closely (or at all).  Even if test after is the process, tasks should be 30 minutes to an hour, and should be committed accordingly back to the repository.