As I had never been to a startup weekend before, I really had no idea what to expect. Despite never having been to a startup weekend I had two goals:

• I wanted to meet some new people in my field or a related field
• I wanted to try something a little bit new and different and fun

I’m sure there’s a ton of people who have written posts about what happens at startup weekend. Aaron and Chad sum it up much better than I will likely be able to anyway.

My Journey

The night started off with the pitches. There were a ton of good pitches and some very exciting ones. I had some ideas but there was exactly one reason why I didn’t pitch: All my ideas had some sort of resemblance to applications I have built at work – And I came here explicitly not to work on the sort of things I do at work. I came to work on something fun.

My night started off by getting on a team with @clangager. Despite my goal of working on something fun, the original idea we were working on centered around bridging two applications via a middle tier. Luckily for us, the problem had already been solved and in such a way that it wasn’t worth attempting over.

Finally, after a night of deliberating, Chad and I ended up deciding on building @sextrics (Sex+Metrics), initially created to be iPoo of sex. Yes, a ridiculous idea. And if you check our twitter stream, many, many laughs were had over the weekend.

Here is the interesting part. Despite being a totally crazy and outlandish idea (I mean – “Hey! We’ll track how often you have sex, what position, what room and we’ll give you some badges and everyone will laugh”) everyone was intrigued. Literally every single person who came through the space came by to see just what the hell we were doing. And laugh. And talk. We had a ton of fun building it and a ton of fun with each other.

Halfway through the day Saturday, we were also joined by @ianj_alberta, who had never used Ruby, Rails, GitHub or Heroku before. We had a lot of fun discussing Ruby, what it was and how it works. However, where his expertise really shone was due to the fact that not only was he a developer, he is also a photographer with Photoshop experience. He built all of the location icons and helped cut out all of the position icons.

In the end, we made our pitch and came in second to @MidoDeals. Congrats to that team.

My Lessons

It was a long weekend and my description above is a very distilled version of the weekend. However, I learned one very valuable lesson.

Any idea, no matter how small or ridiculous you might view it to be has the power to become great if you are just willing to throw it out there and see what people say.

I never thought we would get as far as we did with our idea. But we did.

I never thought an idea that started out as a sex trophy case could turn into a viable prospect. But it did.

I never thought the experience would have such a profound effect on me. But it did.

My Takeaways

1. Take a step outside the norm. It doesn’t even have to be outside your comfort zone. Just something different.
2. You would be surprised what you can accomplish in 54 hours.
3. Never limit yourself. Negativity and nay-saying could prevent you from seeing true value of something.

Oh, and if you’re going to pitch something – make sure you have some sort of a business plan. We didn’t and I’m sure it cost us winning the weekend. Not that I care because I came away from Startup Weekend learning things that are far more valuable than a first place finish ever would have been.

Powershell

Yes, I know I whine about it a lot. But it is a step in the right direction. From a technical standpoint, it is exactly what users in the Microsoft world needed. The main reason I complain is because I like the way that unix shells work in general compared to the way windows shells do. It’s a cultural/ease of use thing. It was a welcome, though LONG OVERDUE tool.

Asp.Net MVC

Once again, a very welcome release. As I said in the last post, it still lacks compared to other MVC frameworks, but it is absolutely a step in the right direction. Maybe you will never even convince WebForms guys to use it, but at least it’s there and it seems to be taking off. You’ll never get rid of webforms from the standpoint of legacy apps that are too big/expensive to rewrite, but going forward we’ve at least got a choice.

My biggest concern with this one is that they shipped MVC2 with Visual Studio 2010. _If_ this means that ASP.Net MVC releases are going to be tied to the Visual Studio releases, they’ve just shot themselves in the foot big time.

The Big One – JQuery

Let’s face it, this was probably one of the biggest announcements MS has ever made. It (could possibly) signify a shift in MS’s stance on open source and community projects. Instead of going out and writing yet another half baked framework, they went out and found a way to package (arguably) the best one with their framework. I understand there are other frameworks out there (and have even used them), but none seems to be nearly as popular as JQuery. In fact, JQuery has basically become the Kleenex of Javascript. Often time’s we on our team will say “I’m gonna JQuery that up” or “Throw some JQuery there”. It’s a noun, a verb… whatever it needs to be for us to say “Use Javascript”.

In fact, I don’t think there would be very many open source libraries with more acceptance and use than JQuery.

Razor

Okay, so maybe I don’t get it, but it does seem a lot better than webforms. But why release it just to throw into webmatrix? Unless I’m missing something here and it’s going to be in ASP.Net MVC next week, or V3.0 (when will that get released?) then it’s ridiculous that it isn’t integrated already.

The big picture

So, though I may not exactly like all the techs I’m about to list, let’s look at them from a high level. MS now has it set up that they can offer an MVC Stack (ASP.Net MVC), a great Javascript Library (JQuery), an IoC container (Unity), an ORM (Entity Framework) and a decent command line environment to deploy it with (using psake and Pstrami if it ever comes out . Again very positive.

So why the big rant?

My biggest point in my last post was “What took so long?” I’ve heard two stories regarding why MVC came to fruition. One is that they were worried about all the MVC frameworks and finally decided to build their own. The other (way cooler) one is that the Gu was given a demo of rails at a conference and loved it so much that he wrote the humble beginnings of ASP.Net on the plane ride home.

Either way, imagine if, instead of a reactive release in 2009 we had gotten a more proactive release even in 2006? Imagine if RIGHT NOW we had in our hands what ASP.Net MVC is going to look like in 2013. Look at the other frameworks. Whenever someone gets something right, they copy it almost immediately. Imagine we had a framework like that.

Or what about entity framework. I haven’t used it yet. I don’t have a need. But in talking to people I have found that EF4 is a huge step forward. Not great yet, but not bad either. It works, but still has shortcomings. Once again, imagine if instead of a 2008 release we had something more along the lines of, i don’t know, 2006? Imagine if EF were nearly as mature as NHibernate.

All I’ve been trying to say is that MS is always late to the party and then tries to get people to push these tools when they know there are better ones out there. There may come a day when an MVP who knows both EF and NHibernate will push  EF before NHibernate (it may even happen already) but it will not be common for a few more releases of EF.

But once again the positive

All these releases seem to be coming closer and closer together now. The IIS Express, Sql Server Compact Edition, Razor announcements recently are examples of that. It seems as though MS is paying attention to the developers and seemingly even other developer communities again. If they can continue to do that and continue shoving resources towards improving the development story on Windows, things are bound to improve. Hopefully quickly.

Let’s face it, outside Visual Studio, windows development is second rate compared to everything else, and I hope they change that because I don’t want to be second rate.

I’m going to start by saying that the first part (and majority) of this post will be negative. Not the whole thing, but you’ve been warned.

With the introduction of the Razor view engine today and the subsequent very expected questioning and praise, I’m feeling the same way I do about so many releases that Microsoft has made since I’ve been a .Net developer:

At best, a little pissed off. But let’s get to that later.

Let’s start with Razor. High level, is it:

• New? Check.
• Different? A little bit.
• Ground breaking? No.
• Revolutionary? Not even close.

If you take a look at the example’s in Scott Gu’s introductory post and the examples for the Spark View Engine, you’ll see why people are commenting about the similarity.

The fact of the matter is, it’s been done. So really, why be upset when people question the use of it? It’s this attitude that starts me on my rant.

ASP.Net

Let’s start way back on January 5, 2002. Love it or hate it, Microsoft introduced ASP.Net Webforms. Whether you agree with it’s methodology or not, you can’t deny that it was:

In fact, it was so revolutionary, that it took until March 17, 2009 before they even released the ASP.Net MVC framework that acknowledged there was another point of view on web development. Now was ASP.Net MVC:

Yet there everyone the pure MS developers were finally being enlightened on what web development could be like. And we were supposed to be grateful. Grateful that literally years after other developers figured it out, MS did. Java got struts in 2000. Ruby got Rails in 2005. There’s numerous others, but to finally get to the subject of my annoyance:

WHAT IN THE F@%& TOOK MICROSOFT SO LONG?

Powershell

Yet another leap forward…. at least for the Microsoft world. How does it stack up:

• New? Nope.
• Different? A little.
• Ground Breaking? Maybe if you include the .Net Integration.
• Revolutionary? Not at all.

There’s literally hundreds of shells. Microsoft finally got up to creating a real one. Reaching at least as far back as 1971, shells have a long and storied history. Probably the most celebrated of the shells, the Bourne Again Shell (bash) was first released in 1987, and was blowing the Microsoft world out of the water in terms of usability, capability and power from even back in the days of DOS. So why is it that it took until 2006 for Microsoft to take the next step?

The obvious omissions for me are: a real history search and a preserved history. Two of the most beneficial tools in a bash user’s aresenal. Credit where credit is due though: The .Net integration story in powershell is immensely intriguing.

Are you seri-OSS?

Bad pun, I know. But the problem is so bad that the developer community has had to take it upon themselves to solve these problems and innovate themselves. There is too many for me to go into each one so I’m going to short list it:

• Entity Framework vs NHibernate
• MSTest vs NUnit, MBUnit and others
• Unity vs Structure Map, Castle Windsor
• MSBuild vs NAnt
• IIS Express vs WEBrick and Mongrel and the like

And the four point system of New, Different, Ground Breaking and Revolutionary is going to look the same for all these. Even the aforementioned items had OSS precursors (MonoRail vs MVC and cygwin/bash vs Powershell).

So why all the acclaim?

Instead of looking from the outside in, let’s take a look at these from the average Microsoft Developer who never strays from the walled garden. Every single technology mentioned would answer something like:

• New? And shiny too!
• Different? Mind bendingly so.
• Ground Breaking? I’ve never seen anything like it!
• Revolutionary? Unbelievably so!

I’ve been an avid *nix user and had at least one or more *nix based systems in my house for 10+ years. I’ve been working (very casually) on a Rails site since 2006. I was a Java developer before I was a .Net developer. To me it always feel like we finally are arriving at the party, years after everyone else.

Better late than never

Truth be told, there _is_ a bright side to all this. Microsoft is finally starting to provide their developers with tools that other platforms have had for decades. Is there a push to be more developer friendly again? I’m not sure. All I know is that finally, they are attempting to move in the right direction. This is very positive. They aren’t there yet.

In fact, currently Microsoft is playing catch up. But it seems like once you awaken the sleeping Beast of Redmond that things start to get done.

It’s not all a miss

I’ve personally used some Microsoft Techs with great success in projects. The ones that come to mind immediately to mind are Prism and WPF. Though both could be improved (we rolled our own Event Aggregator in Prism) and WPF’s INotifyPropertyChanged is frustrating, both are a great step over what we previously had.

In fact, I think that the Framework itself is, overally, extremely impressive. I love C# as a language. I enjoy it and enjoy using it. It’s in many ways, far ahead of most other static languages, combined with VS and R# it’s a dream to use too.

But…

What happens if tomorrow the python devs make some huge leap forward that no other platform has? I would put money on the Java/Ruby/etc communities to mimic it almost immediately. Probably even the .Net OSS community will get something out. But will Microsoft have to wait for “the next release cycle”?

Grateful?

I’m going to be honest, I’m not happy with being second rate. In fact, I’m downright insulted that second rate is shoved in our faces and we’re expected to act like it’s the greatest thing ever. Yes new framework X IS much better than what we’ve got, but it’s still years behind what the other guys have. It’s a classic grass is greener situation, except for that the grass is measurably greener. You want to know why so many leaders are leaving .Net? It’s because Microsoft is behind the times and seemingly refuses to outright acknowledge it until people whine, bitch and complain for YEARS.

Here’s an idea

Wow me. Let’s go back to 2002. Do something. ANYTHING. Don’t just play catch up. Take it to the next level. Be the innovator. Beat the OSS community to the punch. If nothing else, Microsoft is putting itself in the position to do so. But intentions don’t keep developers on your platform.

I’ve been saying it for the last few years: .Net is in many ways stagnant, old and behind the times.

But I couldn’t be happier if they just came out and PROVED ME WRONG.

So prove me wrong. PLEASE.

Since it seems like more and more people are taking advantage of mSysGit and Cygwin to take advantage of Git, I thought I’d take a few minutes to talk about the utilities and tips that I use to help make things easier on myself when using my Cygwin environment.

Sometime in the last two years, I went completely over to Cygwin and Bash for my command line environment on Windows. I’ve been an avid FreeBSD, then Gentoo and then (after having kids and not a lot of time) Ubuntu user since about 2000/2001. In that time there are a few utilities that I’ve come to love that Windows has always left me wanting for.

1. SSH

SSH (secure shell) is an encrypted networking protocol that can be used for a myriad of things. At it’s most basic, you can think of it as a secure, encrypted version of telnet.

You need to have an SSH daemon (think windows service) installed and running in order to connect. You can find a decent tutorial here. As well, you will need a client. I vastly prefer Putty.

Not only can you login and access your computer remotely (via the command line interface) but there are a ton of options that it opens up for you. One of the most useful, in my opinion, is SSH Tunneling. Imagine being away from home, but needing to remote desktop into your home computer (for something you couldn’t do via command line right?) but you don’t have an RDP port open on your firewall. Well, simply set up a tunnel in putty:

What this does create a tunnel from port 9000 on the client machine (the one you are using) to port 3389 on the host daddicant (in this case, my main computer). Now, if I want to remote desktop into daddicant, despite the fact that I don’t have the firewall open for RDP, I pull up remote desktop and….

When I connect to localhost:9000, it will work as if connected to daddicant:3389 via the magic of SSH Tunneling. I really appreciate this from the point of view of not needing to manage my external firewall aside from providing an open SSH port.

2. SCP

Now that you’ve got the SSH daemon up and running, you can easily start copying your files back and forth. Have a zip file you need at home? Just use:

scp file.zip mendicant@beigesunshine.com:/home/mendicant/

After entering your password (or if you’re up to it, a pubkey file, you can google that one or ask me to post about it later) it will connect and copy your file over. You can also use sftp in a similar fashion.

3. Screen

So, now we’re connected remotely, but what happens if A) I want to use multiple consoles or B) what if I’m on my way home but want to keep my session open?

Both are solved via the Screen utility. Start it using “screen”.

Now that you’re at the prompt there are a bunch of keyboard shortcuts you can use, most beginning by pressing Ctrl-A followed by another key. There is a tutorial here, but here are my most used commands.

Ctrl-A C : Create a new console. You will now have two consoles running.

Ctrl-A [0-9] : Switch to your opened consoles.

Ctrl-A D : Detach from screen. This is the most useful because now that you’ve got a console running, you may have a long running process going which you don’t want to disturb when you log off. So just detach!

When you are ready to reattach, just log back in and type “screen –x”. This will re-attach screen to the already running one where your process is still happily chugging away and has been, even when you were logged off!

4. tail

You can use tail to show the last 10 lines of a file (or a configurable number using the –n switch). But the most useful part of tail is the –F command. Using “tail –n 100 –F mylog.txt” will show the last 100 lines of mylog.txt, but it won’t exit. Instead, it will continue to listen to the file and display anything that is written to the file to the screen. This means that you can have a log file scrolling on your screen as it gets written without having to have an app open refreshing. Try this:

1. Open screen.

2. touch test.txt

3. echo “line 1” > test.txt

4. tail –f test.txt # YOu should see it output “line 1” to the screen

5. Ctrl-A C to open a new screen

6. echo “line 2” >> test.txt

7. Ctrl-A 0 to go back to the original screen, you will now see “line 2” on the screen as well!

You could do the same with the –f option of tail, but the –F will reconnect if the file is truncated, meaning those of you with rolling logs would be better served using –F.

5. Finding files

Can’t find that .docx file your wife was working on?

find /cygdrive –iname “*.docx” –type f

will find all of the .docx files on your system. the –iname means Case Insensitive Search. The –type f means only find files.

I use this a lot to remove .svn files via:

rm –rf `find ./ –iname “.svn” –type d`

6. History Search

This is probably the biggest reason I use bash over powershell, cmd or other windows command line utils. Open your ~/.inputrc file and add the following lines:

"\e[A":history-search-backward

"\e[B":history-search-forward

These lines will add back and forward searching to your up and down arrow keys (you could probably bind them just as easily to Ctrl-J and Ctrl-K for you VIM junkies out there).

Anyway, to test go to your prompt and type “source ~/.inputrc” to make sure the changes have taken and then type “cd” and press your up arrow key. This will get you cycling through all your commands that have started with “cd”.

7. Ctrl-U

This one is a small one, but if you need to clear everything that’s before your cursor, type Ctrl-U and it will clear the prompt. Similar to using “esc” in cmd. Hint: This also works in some other apps, such as in the address bar of Opera.

That’s all that I can think of for right now. I’m sure there’s a lot more but those are some of the biggest ones. Let me know yours and I’ll update with the best ones!

At one of the recent WAN Parties, there was some discussion on testing. Some items came up that really got me thinking about why the last 2 years has sold me on testing. From memory, I’m going to go over my thoughts on some of the comments.

It’s hard to write tests first. How did you learn?

Well, I didn’t have a choice. I learned TDD by taking a job as a junior looking for some mentorship. My first two projects were:

1. Get every old app we supported (~ 24) into a build script and onto our CI server
2. Write a small make work app, but do it completely via TDD.

Me and my coworkers had done some pairing and I had written some tests with people, but I always had someone to lean on so it was kind of easy.

However, once I started out on my own, building a system from the ground up and having no idea where I wanted the design to go? That’s when things got difficult. I remember spending literally an entire afternoon writing a single test. One. I don’t even know if I finished. I just remember knowing Point A and Point B and having no idea which path to take between the two.

Of course, as my boss would come and check in on me he would say "That’s good… but why can’t it look like this"? He’d sit down and write a few lines and suddenly I’d feel like a total moron.

The point of the story is: It takes work. It takes writing tests and realizing their crap and continuing on writing more. Don’t expect your first foray into true TDD to be easy, and don’t expect to do it well. However, I can guarantee you that if you stick with it, it _will_ become second nature.

Also, if you can get one, find yourself a mentor to help you. It will help immensely.

How do I know what I should be testing?

I’m inclined to say "Pretty much everything". I’m not a coverage nazi, though we do have some guidelines and goals around it in our shop. However, there’s just code that it doesn’t make sense to test. Like a value object made up entirely of autoprops. I’m pretty sure I know how that thing’s going to work.

Don’t tests force your design?

It seems like many people feel that because everyone has their brilliant idea of what the design of the system is going to be, that they will write tests that will suit their perceived design. For me this is true, but the true power of it is that it shows you ahead of time where your design has flaws.

Yes, I usually have a path that I think I’m going to take when I start writing a test. However, often times before I’m done a set of tests for a feature, I end up changing my mind. The thing about writing the tests first is that it shows you where your design has flaws and where it’s going to cause you pain. If it’s painful for me to write a test then it’s probably going to be a pain in the ass to write and maintain. Pain in writing tests usually signals that you’re trying to do too much at once, often you’re trying to break SRP.

In the end, you’re not only testing your code. You’re also testing your design.

I hear all this propaganda over and over, but how do you know?

For me, I have two projects that I currently work on. One with tests and one without. The one without tests was started before I learned about TDD (though I’m currently trying to begin adding tests, it’s very difficult to retrofit). As well, the one without TDD uses ruby. I heard someone say at the WAN Party the other night that Static Languages and their compilers are just a set of implicit tests. After using a dynamic language I can totally agree.

Anyway, I always find myself trying to find excuses to do something else than my non-TDD project. Why? Because I’m scared to do anything with it. Since I have no tests, I have spent (literally) countless hours fixing bugs only to have them come back into play the next time I fix another bug. I have no way of telling whether what I’m fixing is breaking something else that depends on it. Personally, I think that had I just bitten the bullet a year ago and started putting the tests ever just around the bugs I was currently fixing that I would be well ahead of where I am today on that project.

I’m starting to notice a trend here….

I agree. The funny part I’ve always thought about testing is that as someone learning it, you don’t really see the benefits. In fact, in most cases, the benefits don’t ever fully show themselves until you’ve been working on a project for a long time, or even better, need to come back to it.

Maybe you’re at the opposite end of the spectrum. You’re not skeptical of the claims, you’re curious. Maybe you’re curious like I was 2 years ago because making any changes to an old project is like pulling teeth. Or maybe your current project has hit a standstill because bugs keep creeping in and every change introduces two new ones.

My Story (in a nutshell)

I graduated from University in 2004. I had been working for an Oil and Gas company doing some development part time during the 3 years prior. After graduating I took my first job as a software developer in a small (2 developers, about 6 hardware/network/whatever guys, plus admin staff) company. I was taught to develop in ways I always somewhat questioned. After a while I started to read up on things. The only article that still stands out in my mind that I read was Martin Fowler’s article on Dependency Injection. I know I read some on the Open Closed Principle. And none of it made sense to me. I had too many stumbling blocks in my way:

• I didn’t learn anything in my Computer Science Degree except algorithms and some cool hardware stuff
• My current ‘mentor’ didn’t understand these things either
• I knew I had problems, but I couldn’t even define them even though I was reading about the solutions to my problems

Then I got lucky. I went looking for jobs because I knew there was a better way and I told everyone I interviewed with that. Then I was finally told at one interview that they knew exactly what I was feeling because they had just gone through that pain. They also told me that they had the answers I was looking for.

I took that job and it was the best thing I ever did.

It gave me the things I needed:

• People who understood where I was coming from
• A requirement to learn every day
• Mentorship

I truly believe that the easiest and best way to learn is to have someone with you guiding you in the right direction while also forcing you to go out on your own. I can understand people skepticism, I once had it. But then I got sick of fixing the same thing over and over. I realize that this is getting long so I’ll just end with another personal note: If I hadn’t taken that job and learned what I have over the last two years, I would no longer be in software.

The short story is, Testing saved my career.

Of course, I didn’t have a generate assembly info method, so I basically took Oren’s and ported it as well (sorry Oren, I’ll take it out if you want). At the same time, I took the opportunity to remove the dependency on configatron from rubicant as well. It just seemed like overkill to require configatron when it really wasn’t buying me much.

In the end, I came up with this, which on the whole I don’t think looks too bad. I personally like it better, but I’ve been on a bit of a vendetta against PowerShell scripts since I wrote my first one some time ago. I don’t know why, but the friction it gave me over writing ruby scripts just always rubbed me the wrong way.

require 'fileutils'
require 'rake'
require 'rubicant'
include Rubicant

base_dir  = File.expand_path(".")
lib_dir = "#{base_dir}\\SharedLibs"
build_dir = "#{base_dir}\\build"
buildartifacts_dir = "#{build_dir}\\"
sln_file = "#{base_dir}\\Rhino.Mocks-vs2008.sln"
version = "3.6.0.0"
human_readable_version = "3.6"
tools_dir = "#{base_dir}\\Tools"
release_dir = "#{base_dir}\\Release"
upload_category = "Rhino-Mocks"
upload_script = "C:\\Builds\\Upload\\PublishBuild.build"
mbunit_dir = "#{tools_dir}\\MbUnit"

task :default => :release do
end

task :clean do
  rm_rf buildartifacts_dir
  rm_rf release_dir
end

task :init => :clean do

	generate_assembly_info({
		:path => "#{base_dir}\\Rhino.Mocks\\Properties",
		:title => "Rhino Mocks #{version}",
		:description => "Mocking Framework for .NET",
		:company => "Hibernating Rhinos",
		:product => "Rhino Mocks #{version}",
		:version => version,
		:cls_compliant => false,
		:copyright => "Hibernating Rhinos & Ayende Rahien 2004 - 2009"})

	generate_assembly_info({
		:path => "#{base_dir}\\Rhino.Mocks.Tests\\Properties",
		:title => "Rhino Mocks Tests #{version}",
		:description => "Mocking Framework for .NET",
		:company => "Hibernating Rhinos",
		:product => "Rhino Mocks Test #{version}",
		:version => version,
		:cls_compliant => false,
		:copyright => "Hibernating Rhinos & Ayende Rahien 2004 - 2009"})

	generate_assembly_info({
		:path => "#{base_dir}\\Rhino.Mocks.Tests.Model\\Properties",
		:title => "Rhino Mocks Tests #{version}",
		:description => "Mocking Framework for .NET",
		:company => "Hibernating Rhinos",
		:product => "Rhino Mocks Test Model #{version}",
		:version => version,
		:cls_compliant => false,
		:copyright => "Hibernating Rhinos & Ayende Rahien 2004 - 2009"})

	mkdir release_dir
	mkdir buildartifacts_dir

	cp_r "#{mbunit_dir}\\.", build_dir
end

task :compile => :init do
	MsBuildRunner.new(:properties => { :OutDir => buildartifacts_dir },
					  :project_file => sln_file).run
end

task :test => :compile do
	begin
		MbUnitRunner.new(:mbunit_dir => build_dir,
					 :test_files => ["Rhino.Mocks.Tests.dll"],
					 :report_type => 'Html').run
	rescue
		fail 'Error: Failed to execute tests'
	end
end

task :merge do
	begin
		rm_f "#{build_dir}\\Rhino.Mocks.Partial.dll"
		mv "#{build_dir}\\Rhino.Mocks.dll", "#{build_dir}\\Rhino.Mocks.Partial.dll"

		sh "#{tools_dir}\\IlMerge.exe " +
			"#{build_dir}\\Rhino.Mocks.Partial.dll " +
			"#{build_dir}\\Castle.DynamicProxy2.dll " +
			"#{build_dir}\\Castle.Core.dll " +
			"/out:#{build_dir}\\Rhino.Mocks.dll "+
			"/t:library "+
			"/keyfile:#{base_dir}\\ayende-open-source.snk " +
			"/internalize:#{base_dir}\\ilmerge.exclude"

	rescue
        fail 'Error: Failed to merge assemblies!'
	end

	puts "done merge"
end

task :release => [:test, :merge] do
	begin
		puts "Zipping files"
		sh "#{tools_dir}\\zip.exe -9 -A -j " +
			"#{release_dir}\\Rhino.Mocks-#{human_readable_version}-Build-#{ENV['ccnetnumericlabel']}.zip " +
			"#{build_dir}\\Rhino.Mocks.dll " +
			"#{build_dir}\\Rhino.Mocks.xml " +
			"license.txt " +
			"acknowledgements.txt"

	rescue
        fail 'Error: Failed to execute ZIP command'
	end
end

task :upload => :release do
	if (File.exists?(upload_script) )
		begin
			log = sh 'git log -n 1 --oneline'
			MsBuildRunner.new({:properties => { :Category => upload_category,
											   :Comment => log,
											   :File => "#{release_dir}\\Rhino.Mocks-#{human_readable_version}-Build-#{ENV['ccnetnumericlabel']}.zip" },
							   :project_file => upload_script }).run

		rescue
			fail "Error: Failed to publish build"
		end
	else
		puts "could not find upload script #{upload_script}, skipping upload"
	end
end

If you want to give this script a try (I’ve tried everything but the upload piece, which for obvious reasons I couldn’t test) just follow these steps:

1. Get a copy of the rhino mocks source.
2. Make sure you’ve got ruby installed.
3. Make sure gem is up to date: “gem update –system”
4. Add github to your gem sources: “gem sources -a http://gems.github.com”
5. Install rubicant: “gem install mendicantx-rubicant”
6. Copy the above script into a file named rakefile.rb in the rhino mocks directory.
7. Run it: “rake release”

God willing, this will work. I’ve tried it on a couple of fresh systems, but have no good way of knowing if it works beyond my machines. If you do on the offhand decide to try it, please let me know below!

You know, sometimes, you really shouldn’t test your code.

What?

Yes. You heard me. You shouldn’t test your code.

Well, let me explain that better. I recently took a course where I was paired with someone where neither one of us knew what it was that we _really_ wanted to do. We started to flush out an API for wiring up a hand rolled IOC automatically, and every time we did so, we hit a brick wall. The reason is that we kept trying to ‘test first’.

Don’t get me wrong, I am a complete advocate of test first development. HOWEVER, if you don’t know what the hell you’re doing, you can’t really test first. Being able to test first implies that you can think ahead of yourself and write something that does exactly what you know you need.

In our case, we kept wasting time trying to write tests that just didn’t work with how we NEEDED to do things. How did we solve this dilemma? We sat down and spiked out some code. Just hammered it out and got something working. Now, let me tell you, we wrote some pretty damn horrible and untestable (except via black box testing) code. However, what we did gain was an insight into the process and steps we needed to take to accomplish our task.

However! We didn’t keep that working code we spiked out. Once we had a spiked set of code and a solid idea of what it was we needed, we were able to test and rewrite the code we’d spiked in a much better, tested and well designed manner that would have taken forever if we’d just kept banging our heads against the wall.

To reiterate:

1) TDD with no idea what we were trying to accomplish = 3 hours wasted.

2) Spiking out some code, getting our heads around the steps needed, wiping it clean and restarting the TDD approach with an idea of what we needed to do = less than 1 hour to completion.

Remember, testing first doesn’t mean you should beat your head against a wall just to write a test before writing some code. Sometimes, in order to write a test, you need to write some code first. I guess some people will write tests afterwards, I personally prefer to rewrite, as I find I spend just as much time fixing the code when retrofitting tests as I do just rewriting it out.

In the end, you just need to remember that even if you’re doing TDD, you shouldn’t be afraid to spike out code. It’s the best way to learn and give yourself some direction.

The MsBuild Task is used to create tasks which will use MsBuild. This should help with people who need to build WPF applications (since MsBuild is the only way right now), or (fingers crossed) migrate from MsBuild.

The MsBuild Task is used as follows:

   1: MsBuildTask.new(:task_name => :dependencies) do |msb|

   2:   msb.no_autoresponse

   3:   msb.target

   4:   msb.logger

   5:   msb.distributed_logger

   6:   msb.console_logger_parameters

   7:   msb.validate

   8:   msb.verbosity

   9:   msb.no_console_logger

  10:   msb.max_cpu_count

  11:   msb.ignore_project_extensions

  12:   msb.file_logger

  13:   msb.distributed_file_logger

  14:   msb.node_reuse

  15:   msb.properties

  16:   msb.file_logger_parameters

  17:   msb.project_file

  18: end

Each of setters matches a command line option for MsBuild. For more information on what each one does, please view the documentation at http://msdn.microsoft.com/en-us/library/ms164311.aspx.

Values that can only be set (for example, /noautoresponse) can be set to true (set) or nil (unset).

Values, such as /property that take a list of option settings, must be passed a hash where the keys are the options and the values are the option values. For example, to set the output directory and Warning Level for a csproj compile, you could use:

   1: MsBuildTask.new(:compile) do |msb|

   2:   msb.properties = { :OutputDir => ".\\Output", :WarningLevel => 2 }

   3:   msb.project_file = ".\\Project1\\project.csproj"

   4: end

As of yet, I haven’t added an MsBuild helper to help create this function. I will probably get this done fairly shortly.

MbUnitTask

Behind the scenes, what MBUnitTask does is copies over the minimal necessary support files from an MBUnit directory and then runs the tests. It uses the MBUnit Console Runner and is only tested with MBUnit 2.4. It is used as follows:

   1: MbUnitTask.new(:task_name => :dependencies) do |mbunit|

   2:   mbunit.mbunit_dir = "/path/to/mbunit" 

   3:   mbunit.test_dir = "/path/to/testing/dir" 

   4:   mbunit.test_files = ["tests.dll"]

   5:   mbunit.assembly_path => FileList["/assemblies/to/include/*.dll"],

   6:   mbunit.report_folder => "sets /rf:",

   7:   mbunit.report_name_format => "sets /rnf:",

   8:   mbunit.report_type => "sets /rt:",

   9:   mbunit.show_reports => "sets /sr:",

  10:   mbunit.transform => "sets /tr:",

  11:   mbunit.filter_category => "sets /fc:",

  12:   mbunit.exclude_category => "sets /ec:",

  13:   mbunit.filter_author => "sets /fa:",

  14:   mbunit.filter_type => "sets /ft:",

  15:   mbunit.filter_namespace => "sets /fn:",

  16:   mbunit.verbose => "sets /v{optionvalue}",

  17:   mbunit.shadow_copy => "sets /sc:" }

  18: end

Mbunit helper

   1: mbunit(name, dependencies, mbunit_dir, test_dir, test_files, opts={}) 

Usage is:

   1: mbunit(:run_tests, [:compile_tests], "/path/to/mbunit/dlls",

   2:         FileList["/test/dlls/test.dll"],

   3:         {:working_dir => "/dir/to/run/tests/in",

   4:          :assembly_path => FileList["/assemblies/to/include/*.dll"],

   5:          :report_folder => "sets /rf:",

   6:          :report_name_format => "sets /rnf:",

   7:          :report_type => "sets /rt:",

   8:          :show_reports => "sets /sr:",

   9:          :transform => "sets /tr:",

  10:          :filter_category => "sets /fc:",

  11:          :exclude_category => "sets /ec:",

  12:          :filter_author => "sets /fa:",

  13:          :filter_type => "sets /ft:",

  14:          :filter_namespace => "sets /fn:",

  15:          :verbose => "sets /v{optionvalue}",

  16:          :shadow_copy => "sets /sc:" } 

Runs the tests in test_files in the test_dir with the dlls from mbunit_dir using the options in opts.

For more information on the command line arguments for the mbunit console runner, please visit: http://docs.mbunit.com/help/html/gettingstarted/MbUnitConsoleRunner.htm

In addition, you can also install rubicant via gem:

   1: gem sources -a http://gems.github.com

   2: sudo gem install mendicantx-rubicant

You should only ever have to run the gem sources command once. This adds github to your sources of remote gems. From what I understand, there’s a ton of great projects there.

Now you don’t have an excuse to try it out!