Tim Barcz

Where Do You Want to Be In a Year?

Tim Barcz — Thu, 31 Dec 2009 17:31:00 GMT

This time of year is a time of resolutions and there certainly have been blog posts sprouting up about 2010 and what people are going to change about themselves. I’m however going to approach it differently…

Habit #2 of the The 7 Habits of Highly Effective People is “Begin with the end in mind”. Which has a key part I like:

“…If you don't make a conscious effort to visualize who you are and what you want in life, then you empower other people and circumstances to shape you and your life by default….”

Where do you want to be in a year?

My Answer:

By the end of 2010 I want…

to have learned more about the business.
to understand lean manufacturing/processes and it’s adaptation to the software development world.
to continue to read and learn more about marketing and the intersection of technology and marketing so that I can make more effective/informed decisions in my role at work.
to continue exploring enterprise architecture both in book form but also in the often messy real-world. At work I’d like to use my knowledge of technology and architecture to continue to work to bring disparate systems together to reduce human involvement.
to explore Ruby or F#, whichever seems to have real-world impact value to what I do.
move to Git for source control at the enterprise level
to be renewed as an Microsoft MVP
to speak fewer times but with more authority/knowledge

That’s me, how about you? Where do you want to be in a year?

Unit Testing Strategy: Hiding Out In the Open

Tim Barcz — Wed, 16 Dec 2009 15:38:00 GMT

Sometimes there are pieces of code that you want to test but you just don’t quite see how you can unit test it easily. I have illustrated one such example below where I am interacting with the file system.

Take the following snippet for example:

   1: public class FileRenamer : IFileRenamer

   2: {

   3:     public void RenameFile(IList<DomainFile> files)

   4:     {

   5:         if (files == null)

   6:             return false;

7:

   8:         foreach (var file in files)

   9:         {

  10:             var newName = string.Concat(file.FullFileName, file.Client, file.Site, file.DesagilationCount, ".file");

  11:             File.Copy(file.FullFileName, newName);

  12:         }

  13:     }

  14: }

I want to “unit test” that the correct file is created, but I really can’t. The “File.Copy()” is going to hang me up a bit because in order to verify the method worked I am going to have to go visually verify that a file was copied to a certain location. I could of course automate this but in either case I’m touching the file system, which is not a quality of a good unit test.

In reality, the only thing I really care about here is that the new file is named properly. However, as it sits, the new name is really coupled to the copy process and the hard disk. Let’s change that…

   1: public class FileRenamer : IFileRenamer

   2: {

   3:     public void RenameFile(IList<DomainFile> files)

   4:     {

   5:         if (files == null)

   6:             return false;

7:

   8:         foreach (var file in files)

   9:         {

  10:             File.Copy(file.FullFileName, BuildNewFilename(file));

  11:         }

  12:     }

13:

  14:     public string BuildNewFilename(DomainFile file)

  15:     {

  16:         return string.Concat(file.FullFileName,file.Client,file.Site,file.DesagilationCount,".file");

  17:     }

  18: }

What I’ve done here is move the logic of the new name creation to a new method. By extracting that single line to its own method, we’ve made the “untestable”, testable.

So at this point you may be asking yourself why this strategy is called “Hiding Out In the Open”? I call it that (is there another more formal name? possibly an xUnit test pattern name?) because we haven’t added the method to the interface (the “hiding” part) but we have made the method public so it’s visible to consumers (the “out in the open”).

Hiding

When I added the public method to the FileRenamer class, I *did not* add it to the interface IFileRenamer. That means anywhere where this particular class is referenced as an IFileRenamer that the new method (BuildNewFilename) won’t be visible (see below). Hence the usage of the term “hiding”:

Out In the Open

The whole point of this exercise was to gain some testability aspects for this particular class. Since the method is public, in our test method when we create an instance of our FileRenamer class, we now have the ability to test (see below):

Some Caveats

Some will argue that the renaming of the file is a separate concern from the copy. The separate concern would then be a separate class that is possibly used by the FileRenamer, in which case the new class would be testable. This is a fair argument and at times it’s a good strategy. I think it’s good to know the strategy so there are more tools in the bag when a curious situation arises.

Some will argue that you’re increasing the surface area of your API when you make the method public. Again, a fair argument however, in most cases when dealing with the abstraction (the interface) this doesn’t rear it’s head. It’s a small insignificant side-effect. If you don’t like it don’t use it. Disclaimer: I strongly discourage this course of action if you’re building a public API that others will consume. In my case, 99% of software I write is used in house. If making something “public” really bothers you, then make it internal and use the “InternalsVisibleTo” assembly attribute to give your test assembly visibility.

Conclusion:

The original snippet of code above had some pieces that were hard to properly unit test. What we’ve done here employed a strategy I call “hiding out in the open” to the class under test to achieve a bit more testability. I think this is just another testing strategy to have in your back pocket. There should be few times when you need this particular strategy, but when you need it it does come in handy.

Ralph Waldo Emerson Would’ve Been a Great Developer

Tim Barcz — Mon, 14 Dec 2009 18:06:36 GMT

A very short quote I came across to start your week off and get you thinking about technology with the correct frame of reference:

“As to the methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.”

- Ralph Waldo Emerson (1803-1882)

Mr. Emerson would surely have made a great developer. We need to heed his advice.

As an exercise: think of how many different “methods” you can think of and then think of how many “principles” you can come up with.

Principles:

Single Responsibility Principle
Don’t Repeat Yourself
Dependency Inversion Principle
Liskov Substitution Principle
Open Closed Principle
Interface Segregation Principle

Methods:

ASP.NET
C# 2.0
C# 3.0
LINQ
LINQ to SQL
Entity Framework
NHibernate
SOA
StructureMap
Windsor/MicroKernel
Ninject
ASP.NET MVC
Ruby
IronRuby
W*F
Silverlight
And on and on and on…

“As to the methods there may be a million, but principles are few.”

Confessions of a First Time Manager

Tim Barcz — Sun, 13 Dec 2009 04:10:39 GMT

Many months ago I wrote a letter to upper management about principles of software development and the ways in which should build software. Since that time my role has changed within the company and for the first time in my career I’m managing a significant number of people (at a previous company I was an R&D Manager but the team was much smaller).

Below are a few observances/realizations I’ve had in the months since I’ve made the transition that I want to share with you:

Just cause you’re the manager doesn’t mean you know everything – Just because someone has tapped you to lead the team doesn’t mean “you’ve arrived”. You don’t automatically go from individual contributor to all-knowing edict maker.
Don’t Relax/Stay involved – Too many managers think because they’ve “arrived” they no longer need to keep pushing themselves. They think they are afforded some special privileges or don’t have to abide by the same rules others are held to. Not wise.
Rely on your team – This one is often hard. It was likely your contributions as in individual contributor that got you noticed for the management position and it’s often hard for an individual contributor accept the role change and not want to tackle challenges individually or continue to contribute. As a manager you’ll have to rely on your team to see the same level of success as a manager as you presumably did as an individual contributor. You’re no longer measured on what you do but rather how your entire team performs. This one is admittedly hard for me and I’m growing into this more and more every day.
Build your team – As an individual contributor you were primarily responsible for just one person, yourself. As project lead or a team lead you’ll have more responsibility but likely you won’t have people reporting directly to you. As a manager you’re now responsible for everyone on your team and giving them the opportunity to be the best they can. Give people the freedom they need to do great things.
Be honest - Don’t lie, shade the truth, or embellish. When you mess up, fess up, I believe the team will respect you more for it. ‘nuff said.
Never ask your team to do something you wouldn’t do yourself – Managers who require/ask team members to do something they wouldn’t do themselves are being unfair. Asking your team to work late while you get to leave every day at 5:00 is an amateur move. Asking the team to give up the weekend might be a necessity at times. Just make sure if you ask, you’re right there alongside of them.
Don’t be a bottleneck to change – The team shouldn’t always move at the speed of the manager. In general just because you don’t understand something doesn’t mean it shouldn’t be adopted. If you cut your teeth on VSS and were a ninja in VB.NET but now your team wants to move all projects to C# and this new thing called Git, don’t blindly say no. Technology moves fast, if you have a trustworthy team, you’re going to have to let go a bit and rely on the team (#3). Remember, you don’t know everything (#1) and you need build your team (#4), sometimes that may mean doing or trying something you don’t quite understand.
Don’t be afraid to push for change – While you shouldn’t be a bottleneck to change you shouldn’t be afraid to push for it either. As a manager you typically have a greater visibility to the team or the process and if you see something that could be improved you shouldn’t necessarily wait for someone on your team to bring it forward. You’re still part of the team
Hiring/Firing Sucks – Movies make firing seem like an easy thing to do and an ego-boosting power-trip. It couldn’t be further from the truth. The days I’ve had to let people go I’ve rarely slept the night before. There’s nothing enjoyable about the process of taking away someone’s livelihood. Hiring can be fun, but most often it’s time consuming and all the time you spend interviewing is wasted except on the one person you hire.

You’ll notice that many are intertwined and I think at the heart of many of these is pride. Pride is a dangerous beast, avoid it at all costs. Whether it means you have a trusted friend or colleague keep you in-check or you do frequent self-assessments, don’t let pride seep it.

Please note that these are my personal observances that I’ve taken mental note of while on this journey. Your mileage may vary.

I Just Cloned, Why Did Git Change My Files?

Tim Barcz — Mon, 30 Nov 2009 04:35:00 GMT

Being new to Git I got thrown off a few weeks ago when cloning a remote repository and immediately seeing changes after the clone completed. Scratching my head a bit, I reached out on Twitter and James Gregory came to the rescue.

How is it that right after a git clone <url>, git status shows modified files? (http://twitter.com/TimBarcz/status/5920294511)

What James showed me was that there is a setting core.autocrlf on your system which needs to match the remote repository. If it does not match, when you clone the directory files will be changed.

After experiencing this myself and coming across it again the other day, I thought I’d put a quick video together showing the problem and the fix, since I suspect others will have it at some point as well.

Git - Core.AutoCrlf Setting from Tim Barcz on Vimeo.

To recap: when cloning a new repository, always perform a “git status” command right after the clone. If you see modified files, a core.autocrlf mismatch is likely the culprit. Change your setting, clone again, and you should be good to go.

Devlicio.us Lands Another - Rob Reynolds

Tim Barcz — Mon, 23 Nov 2009 04:05:00 GMT

One of the goals of the devlicio.us community is to bring you some of the best developers and content in the developer community. Over the past few months Devlicious has added a few new people to it's growing blogging community. If you haven't noticed already, we've added another, Rob Reynolds.

Rob is from the Kansas City area where he works at a bank where he says, "The doors are always locked and there is no money inside." I met Rob about a year ago at the Alt.NET Open Spaces conference in Seattle. Rob and I hit it off immediately as we share a lot of same passions for IOC, SOLID, DI, and other neat acronyms.

Rob is an automation expert and is continually looking for ways to use automation so he can focus on more interesting things. "Automate your life" is his mantra. He automates everything from his bills and retirement to computer backups, database restores and everything code.

Rob is also heavily involved with the open source projects and manages a number of projects including UppercuT, RoundhousE and Bombali. He's contributed to other OSS projects (MSBuild Community Tasks, Tarantino) and is also a committer for AutoTest.NET.

When it comes to continuous integration and automation Rob is your guy. I'm thrilled to be blogging alongside him and have the opportunity to learn with and from him. Please join me in welcoming Rob to the Devlicio.us community.

Resharper 5.0 - Bookmarks

Tim Barcz — Fri, 09 Oct 2009 18:35:00 GMT

Today it was announced that Resharper 5.0 will soon be introduced as part of the public EAP (Early Access Program). As one on JetBrains .NET Academy Experts I’ve had access to Resharper 5.0 for a few weeks. While in the coming weeks and months you’ll hear quite a bit from developers who are trying out Resharper 5.0 I wanted to alert you to one of my favorite features at this point.

Bookmarks

I read a lot more code than I write. When exploring new projects, doing code reviews, tracking down a bug, I like to mark different paths the flow of execution may take. Most often to keep track of call stacks and what goes where, I usually end up using a piece of paper with a pencil drawing lines to various methods and interfaces. I could use Visual Studio which has had the concept of bookmarks for some time. You can put a bookmark in code which creates a bit of a mark in your file that you can come back to later.

The problem with these bookmarks is that they’re flat and don’t and you get options of previous or next, but never the opportunity to define what “next” means? Hopping from bookmark to bookmark may not actually follow any intended path you meant to take when you placed the bookmark.

Resharper 5.0 introduces the concept of bookmarks where you can set order.

Now I can happily bounce around code and easily inspect different control flows in a much more controlled fashion.

ReSharper has been part of my toolset now for several years and I think what they’re doing is great. While ReSharper 5.0 is a bit buggy at times I like it and the improvements it brings. I am looking forward to further EAP releases of ReSharper and encourage you to check them out as well. Should be coming by the end of this month.

Git…Command-line or GUI?

Tim Barcz — Wed, 07 Oct 2009 19:15:02 GMT

A short quick post to get some feedback from you, the reader.

I’m working to learn and transition to Git (using Jason Meridth’s great series on Git). Up to this point I’ve been using the command-line only, working to learn Git on the command-line before I rely on a tool or GUI abstraction. Recently I’ve been going through some refactoring on a project where I’m using Git. Right now I’m slow, really slow. Renaming files/classes for example is cumbersome to say the least.

I got to wondering if knowing the command-line is even useful anymore or it just a geek badge of honor that a few developers like to point to proudly when talking about skill sets? Some part of me feels like using a tool like GitGUI or TortoiseGit is “cheating”. Ironically I admire Git because it seems to let me work the way I want to work; branch often, local commits, easier merging and yet right now the command-line use of Git is my primary roadblock. It is at this point that I start thinking I should give up on the command-line since an SCM tool shouldn’t be intrusive and move to a GUI tool and give up my chances at fifth degree black belt geek.

So what do you think?

Use command-line go slow now but know the tool very well.
Use GUI and go faster, however always be reliant on the GUI abstraction

Is using a GUI “cheating”?

Ship Software With Value

Tim Barcz — Tue, 29 Sep 2009 18:49:24 GMT

The blogosphere has gone a bit crazy the last few days with posts responding to Joel Spolsky’s latest article about "The Duct Tape Programmer". Bloggers everywhere are tossing their two cents in and saying what parts of Joel's post was good and what wasn't good. Once noticeable trend is that many have jumped on the "just ship it" bandwagon.

There’s a quote mentioned by Jamie Zawinski in the article:

“Yeah,” he says, “At the end of the day, ship the f---ing thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.”

I don't know Jamie and I imagine the context that the comment was made in was based around some pre-existing level of candor with the person he was speaking. We really don’t know what “…ship the f---ing thing” means in the context of that conversation and what level of quality is expected in that scenario. I would agree with Joel/Jamie that shipping products is important and that often developers (myself included) run the risk of becoming too entrenched in a design or beauty and all too easily miss the point of developing software...which is to ship a product that adds value. However...”shipping” is only part of the picture. As someone responsible for the value of the product my team ships, I’m keenly aware of what affects shipping early can do (both the positive and negative).

I'm reading a lot where people say "just ship it" but I've been part of teams where shipping too soon costs more money in the long run (and sometimes not even “the long run” but a few days/weeks down the road). These pro “ship it” bloggers surely must be talking about non-critical business systems when we say "just ship it"; would you want to ride on a plane where the flight control systems were sent out with bugs? Even a measly 1% failure rate of airplane system is unacceptable and is enormously expensive both in dollars and reputation for an airline.

The point is that shipping is the point but not the whole point, it's only one aspect of a well delivered software product. Shipping software with value is the point. Ship too soon with bugs and the value gained by shipping is potentially lost. Conversely shipping late provides no value at all. Neither lobbing a piece of crap over the wall at your customers early, nor refactoring your code till it shines is the point, neither should be considered a success. There’s a sweet spot that you need to find. Keep in close contact with your customer, if you pay attention they’ll let you know when you’ve crossed into either extreme.

Testing URL Generation on Routes in MVC Framework

Tim Barcz — Thu, 27 Aug 2009 05:15:00 GMT

Today I wrote some code to output URLs in a certain manner in an ASP.NET MVC project. The code I wrote was extremely simple, but I struggled, I mean S-T-R-U-G-G-L-E-D, to write tests against the new code and ensure correctness. I could easily very visually that it was working but the amount of setup and kludge around ViewContext, RequestContext and ControllerContext was causing me to pull my hair out.

I tweeted my frustrations as I packed up and left work for the day and got the following responses soon thereafter:

@TimBarcz outbound routing is still hard, sadly (from @subdigital)

@TimBarcz …a way to test #aspnetmvc a helper to reduce the ridiculous noise/setup would be helpful (from @ehexter)

Determined to not give up I pulled down the MVCContrib source and started to peck away. I’m working on committing and finalizing the code but here is a sneak peak of the changes. Hopefully you agree that it is an improvement.

Before:

   1: [Test]

   2: public void Should_correctly_generate_session_url()

   3: {

   4:     new RouteConfigurator().RegisterRoutes();

   5:     var builder = new TestControllerBuilder();

   6:     var context = new RequestContext(builder.HttpContext, new RouteData());

   7:     context.HttpContext.Response.Expect(x => x.ApplyAppPathModifier(null)).IgnoreArguments().Do(new Func<string, string>(s => s)).Repeat.Any();

   8:     var urlhelper = new UrlHelper(context);

   9:     string url = urlhelper.RouteUrl("session", new { sessionKey = "this-is-the-session", conferenceKey = "austincodecamp" });

  10:     url.ShouldEqual("/austincodecamp/sessions/this-is-the-session");

  11: }

After:

   1: [Test]

   2: public void should_be_able_to_generate_url_from_named_route()

   3: {

   4:     OutBoundUrl.OfRouteNamed("session").ShouldMapToUrl("/sessions");

   5: }

And

   1: [Test]

   2: public void should_be_able_to_generate_url_from_controller_action()

   3: {

   4:     OutBoundUrl.Of<FunkyController>(x => x.New()).ShouldMapToUrl("/Funky/New");

   5: }

Much, much cleaner and easier on the eyes.

It’s not quite done yet and has some holes (accepting additional route values, etc) but it’s worthy of discussion and once completed should make one very frustrating aspect of testing in MVC even easier.

Zero Defects In Software, Setting a Higher Bar

Tim Barcz — Wed, 26 Aug 2009 18:04:37 GMT

Several months ago I published a letter to upper management about improving software processes. In that post I laid out what our team needed to do to be more effective at our jobs. Since that letter nearly five months ago, I have been promoted to management myself and now manage the team. While some might say I’ve gone to the dark side, I would vehemently disagree. The role certainly has changed me but I like my role because I still am a developer and know that high quality solutions do mean dollars in our pockets because we’re able to adjust/react more quickly.

I just got done reading an article over my lunch break and it caused me to shake my head in one key spot (emphasis mine):

It’s very difficult, if not impossible, to build and maintain a dynamic web site that works flawlessly every moment of every day for every customer. Between implementing new content, changing technology, managing internal stakeholders, and designing for customers who have different objectives, learning styles, and backgrounds, you could never produce a 100 percent error-free site. After all, to err is human.

Have we really set the bar that low with quality in software? I think we need to raise the bar. A few months ago I took a stand with my letter to management, here is a similar email I wrote to my team recently which works to combat the thought process and acceptance of poor quality so rampant in our industry:

All,

As a developer I've worked on systems and rarely, if ever, have we set the bar so high as to have zero known bugs in the system. I think often this is looked at as "too lofty" or "impossible". Well, the development team here currently has one bug and is fast approaching zero. It IS possible.

In our department we often talk of "demonstrating competency and expertise". The flip-side of setting such high expectation is that we can shatter our reputation quickly with even a few small issues or bugs. Chris has said that developers are like airline pilots and that you only hear about them when something goes wrong. There's a lot of truth in that. You expect a pilot to get you somewhere safely - people expect our software to work.

I think we should not shy away from holding ourselves to an excessively high standard. Frankly, I'm more familiar with how to do it as a developer having years of building software to gain knowledge and experience from. I don't have all the answers on how do this from the other aspects but I don't think this means we stop trying. I think quality should be the first and highest goal. Speed should follow quality. If you're keeping a high quality standard and feel overwhelmed that the work is backing up behind you and you can't ensure the highest quality, please don't hesitate to talk to me about it and we'll see if priorities can be reworked.

As a team we're setting a positive direction for our department and its future. As we continue to refine our processes and expectations within each subgroup be aware of the lasting impact of the work we do. Be vigilant about improvements in the process we can make. If you see areas where you see quality slipping, pull the "red cord" and stop the process from going further until the quality is fixed. We want anything that leaves this department to be of the highest quality, whether a proofing round or a final product build. Don’t rely on other departments to back us up. If we operate in this manner we'll only build further credibility and reputation within the company.

Tim

What about you? What’s your stance towards bugs? Think zero defect is too lofty?

RhinoMocks Exploration : RhinoMocks “Caching” Values?

Tim Barcz — Fri, 21 Aug 2009 22:26:00 GMT

Occasionally on the RhinoMocks mailing list a question pops up about various pieces of the framework that people struggle with. This post is the first in hopefully an ongoing series where I address specific underpinnings of RhinoMocks to you, the reader. I’ll do my best to explain the inner workings of the code and what is going on under the covers while trying to keep it “real”. If you have specific things you want to see, let me know and I will do my best to put together the tutorial.

That said, let’s get started…

Occasionally a question will come in about RhinoMocks caching a value and that something must be a bug in the framework. Consider the following very simple test where we want to return the current date/time from a property getter. You have a component with a gettable time but no setter. In order to fake this out we use the Stub() method return a "known" value.

   1: [TestFixture]

   2: public class TimTests

   3: {

   4:     [Test]

   5:     public void DateTimeDive()

   6:     {

   7:         var stub = MockRepository.GenerateStub<IFoo>();

8:

   9:         stub.Stub(x => x.Current).Return(DateTime.Now);

10:

  11:         Thread.Sleep(5000);

12:

  13:         Console.WriteLine(stub.Current);

  14:     }

  15: }

16:

  17: public interface IFoo

  18: {

  19:     DateTime Current { get; }

  20: }

What time do you suppose is written out the console given the Thread.Sleep cal? The common thinking is that the Stub() method stores a method to be called to return the value at the time of execution when in reality what is happening is that the stub.Stub(x => x.Current).Return(DateTime.Now) line is evaluated at runtime at the time the Stub is set. Therefore, in the above code, the Console.WriteLine(stub.Current) will actually write the time from 5 seconds (5000 milliseconds prior) when the stub call was made. In other words, when Stub() is called, the resulting value is calculated and ready to be returned, it's not deferred for execution.

What is going on is that deep in the bowels of RhinoMocks there are things called Expectations, MockStates, and Recorders. In the code above, when Stub() is called, what happens is a two step process (but appears as one, given the fluency, or dot-dot notation, of the call).

    1. An expectation is created with a null return value (stub.Stub(x=>x.Current))
    2. The expectation is updated with the known return value (.Return(DateTime.Now))
    (Note that if you try to write code without the second piece, you will get an InvalidOperationException when you try to use the stubbed property stating:
        failed: Method 'IFoo.get_Current();' requires a return value or an exception to throw.
        System.InvalidOperationException: Method 'IFoo.get_Current();' requires a return value or an exception to throw.
        C:\dev\OSS\rhino-tools\mocks\Rhino.Mocks\Expectations\AbstractExpectation.cs(342,0): at Rhino.Mocks.Expectations.AbstractExpectation.ReturnOrThrow(IInvocation invocation, Object[] args)
        C:\dev\OSS\rhino-tools\mocks\Rhino.Mocks\Impl\StubReplayMockState.cs(63,0): at Rhino.Mocks.Impl.StubReplayMockState.DoMethodCall(IInvocation invocation, MethodInfo method, Object[] args)
        C:\dev\OSS\rhino-tools\mocks\Rhino.Mocks\Impl\ReplayMockState.cs(118,0): at Rhino.Mocks.Impl.ReplayMockState.MethodCall(IInvocation invocation, MethodInfo method, Object[] args)
        C:\dev\OSS\rhino-tools\mocks\Rhino.Mocks\MockRepository.cs(678,0): at Rhino.Mocks.MockRepository.MethodCall(IInvocation invocation, Object proxy, MethodInfo method, Object[] args)
        C:\dev\OSS\rhino-tools\mocks\Rhino.Mocks\Impl\RhinoInterceptor.cs(96,0): at Rhino.Mocks.Impl.RhinoInterceptor.Intercept(IInvocation invocation)
        c:\OSS\Castle\Tools\Castle.DynamicProxy2\Castle.DynamicProxy\AbstractInvocation.cs(202,0): at Castle.DynamicProxy.AbstractInvocation.Proceed()
        at IFooProxybc98a6ed8f1b4aa3b9ea36d89f80e6af.get_Current()
        C:\dev\OSS\rhino-tools\mocks\Rhino.Mocks.Tests\TimTests.cs(43,0): at Rhino.Mocks.Tests.TimTests.err()
    There is an "expectation" created when the call is made and that expectation is added to a recorder (There are ordered and unordered method recorders, by default (the most common scenario) you will be using unordered recorders). These recorders record the mocked object (our stub object here), the method being called, and the "expectation". The call to .Return(DateTime.Now) updates the expectation with the desired return value. In the RhinoMocks framework this code is very simple but it's important to note this value is executed at the point this code is run.

   1: public IMethodOptions<T> Return(T objToReturn)

   2: {

   3:     expectation.ReturnValue = objToReturn;

   4:     return this;

   5: }

You can see from the code above that setting up a return value simply updated the expectation's return value.
I hope you've followed the above code. The RhinoMocks codebase is not simple per se and you do not need to understand it in depth to use it but I think in this case it help (as I see it often pop up on the mailing list).

So what do you do if you want something to be called in a delayed fashion? In our example I want the call to IFoo.Current to represent the DateTime.Now when I call it (as opposed to when I set it up). To do that, simply use the "Do()" method. Here is an example that provides the same functionality as above, only the return value of the Stub is deferred until the stub is actually called.

   1: [Test]

   2: public void Realtime_results_with_Do()

   3: {

   4:     var stub = MockRepository.GenerateStub<IFoo>();

5:

   6:     stub.Stub(x => x.Current).Do(new Func<DateTime>(() => DateTime.Now));

7:

   8:     Thread.Sleep(5000);

9:

  10:     Console.WriteLine(stub.Current);

  11: }

I hope this helps a bit with the confusion around RhinoMocks and perceived "caching" of values. If you have questions about this or other areas of RhinoMocks, I would love to tear into them for you, just ask!

Invoke.CallFor(()=> Speakers).For(IowaCodeCamp.Version(4))

Tim Barcz — Fri, 21 Aug 2009 03:48:00 GMT

Not too long ago Iowan developers had to travel to other states to get to a code camp. Now, a few short years later, Iowa, on November 7th, is having it's fourth Iowa Code Camp in Des Moines. I'm writing today to officially announce that we are now accepting speaker submissions for the event. I encourage you to think about what excites you about .NET and software development and how you can impact software developers in the Midwest with your topic. Code camp attendees are typically talented developers who demonstrate their dedication to their craft by coming to a learning event on a weekend. High quality content, such as that topic that just popped into your head or that topic you've been waiting to speak on, are the kinds of sessions our attendees are looking for.

To submit a session or three, simply go to http://iowacodecamp.com/Speakers.aspx and follow the instructions there.

The deadline to submit is September 23

A few quick notes:

Speaker and session selection is done by the Iowa Code Camp leadership. We'll accept as many sessions as we can hold and will work to balance between advanced and beginner level topics
You may (and are encouraged) to submit more than one abstract

Special note to new speakers or people interested in speaking at a code camp for the first time:
Code camps are a great way to enter the world of speaking and "dip your toe in the water". If you've thought about speaking before and have a topic you're knowledgeable about, consider taking the next step and submitting a session. Iowa Code Camp welcomes new speakers and works hard to provide a very friendly environment to present for the first-time presenter.

Moving to Kanban : A Mentoring Session

Tim Barcz — Thu, 20 Aug 2009 03:49:00 GMT

After my recent post about our software team moving to Kanban I got an email from Derick Bailey asking how he could help with our transition. Derick graciously offered to meet with our team and help with any questions we may have and provide guidance as someone who has traveled this path before.

We met for a little over two hours on Monday and recorded the discussion. You'll find that we bounce around a little bit which is because what you're hearing is a team working in Scrum learning about Kanban. This wasn't scripted. It is a teams honest questions about how one would go to Kanban and how to put the right pieces in place to make it succeed.

Derick and the guys at LosTechies have set up the hosting for this on PabloTv: Check out the first Adopting Kanban video

Book Review: Web Design for ROI

Tim Barcz — Fri, 14 Aug 2009 13:19:00 GMT

So I've been on a kick lately to publish book reviews of books I've been reading. I hesitated at writing this review given the nature of the book tends to be more around design than it does around code. I decided to write the review for a few reasons:

Designers, who also code, may read this blog
If you work on a web site you should care about the design since it will affect the success of your site as well the way you code

I wouldn't normally have picked up this book, instead favoring usability books by Jakob Nielsen or Steven Krug or other well known usability personalities. However, back in May I went to the ACCM Conference (Annual Conference of Catalog and Multichannel Merchants) and sat in a day long seminar by the authors of this book, Lance Loveday and Sandra Niehaus. Both were very knowledgeable and presented their material well and as such I was interested in the print version of the seminar, this book, Web Design for ROI.

Part I - The Big Picture

The first part of this book talks about some of the principles of what design can do and the state of web site design as a whole. If you're reading this page chances are good that you have worked for sites that pay little attention to design. If you have not worked for such a company, you can easily think of one in which you are a customer.

There is a good case made for revisiting design aspects of the site as an investment in future profitability. Quite often a site that is "up" is considered done and work soon begins on the next set of features without really watching to see how a page or set of pages is performing. Are people finding what they are looking for? Is it clear on a page what someone should do next? This book presents the idea that web design is never done and really it's a constant effort to tweak pages to see changes in the analytics.

Chapter four introduces the idea of user testing which, after being exposed to it a several years ago has been a closet interest of mine. Analytics are brought into the picture here too but again all stuff that is pretty basic if you're already in the web space and are actively tracking users and patterns. If there is one thing I learned from this section is that even the most minor changes to a web page, things most developers would scoff at, can have a dramatic effect on the performance (ROI) of a page.

Part II - Design Guidelines

This section of the book goes through different pages on an e-commerce site, landing pages, checkout, product detail pages, and of course the home page. I liked how each of these pages were featured in their own chapter. Throughout this section I appreciated the full color screen shots of examples. My only issue was with the softness of some of the advice. Granted it may be presented this way because design is really a case-by-case basis and there is really no one-size-fits-all. Or it could be that the authors feared putting concrete advice in the book only to see their advice (and book) quickly become outdated. I'm not sure.

Conclusion and Final Thoughts

This book was a very quick read and did add to my knowledge a bit but more importantly got me thinking about design and usability, which is always a good thing. If you're looking for a few ideas and conversation starters with your design staff then I would pick it up. If you're new design and analytics this book can be a good primer as the various terms and definitions are given in the sidebar at times and inline. If you're in the e-Commerce space already and have been doing design for some time, I think you may be disappointed in the book because many concepts are things you would probably already know. The problem for me may lie in the intro where the authors talk about who this book is for

"These days it takes a village of people to inspire, envision, create, and maintain a web site. This book is for everyone in that village. We've attempted to make the book useful and accessible to people with a range of experience levels"

In my opinion they cast their net so wide they missed the mark. Having sat in on a seminar with Lance and Sandra, I can confidently say they know their stuff and some of that came through in the book. The problem ultimately lies in the quote above. With making this book appeal to everyone it appeals to very few because it never achieves the depth that I've seen that both Lance and Sandra have. Ultimately Lance and Sandra have a wealth of information and quite honestly I would have liked to have seen possibly two books which go into much deeper depth than this single book which scratches the surface.