A series in C# would be most welcomed!!

Very useful videos. Thank you very much.

Will be nice to have a series in C# but with a different story. Anyway I have learned some new Eclipse tricks and see how Fit works, so thanks.

useful links.. thanks ill save this post.

Yes, C# would be great.

C# would be perfect :)

Greats videos. IMHO a series in C# is not necessary or are the TDD methods and processes significant different?

Actually I have been following you along building my own C# rpn calculator.

Personally I think there would be only limited value in redoing a them in C#.

The TDD flow and BDD style tests would very simliar in either language. I beleive most developers have little trouble adapting Java—>C#.

The main difference would just be the mocking framework?

Once again, thanks for putting these together!

Certainly, a C# version will be very nice to have.

C# nice to have.

I think, C# version will cost too much for a little value.

Thank you for nice work.

Nice series – I’m only through the first video so far but it’s nice to see the “transition from TDD -> BDD” as it helps people understand better how to structure tests in from a BDD perspective. Although I’ve been a .Net developer using C# for many years now, I think the example is simple enough that a complete redo for C# isn’t necessary. Perhaps one video hilighting some of the more advanced BDD/DDD tools on .Net (MSpec, for example) may be useful though, but this would be more of a tooling demo than major concepts.

Hum… Mixed opinions on a C# version.

The one commend about mocking tools I can quickly address. Use Moq for C#/.Net. Mockito seems to be heavily influenced by Moq (I think Moq came first, please correct me if I’m wrong).

Here’s a link to getting started: http://schuchert.wikispaces.com/Mockito.LoginServiceExample

I’ve used other libraries, and they are fine. I prefer Moq/Mockito. The examples as written in Java using Moq will closely translate (mostly syntax differences in the DSL) to Moq in C#.

I loved these videos. It was great to hear you explain the decisions you were making along the way.

I don’t see much value in repeating the same exercise in C# given its similarity to Java.

It would be interesting to see the RPN Calculator solved in Ruby or a different problem solved in C#.

Thank you very much for the time and effort you put into these videos.

What about Ruby?

Fantastic series!!

Thanks!

RE: Ruby

I do like the language. The last time I looked, the refactoring tools were simply not there. So I’m going to pass on ruby videos for now.

However… Check these out (and please understand these are OLD): http://schuchert.wikispaces.com/ruby.Tutorials

I’m a .Net devloper and I had no problems in understanding this series.

I’ve really enjoyed these videos so far (will watch the remaining four tonight). Thanks for doing them.

Regarding C# (I’m a .NET developer) I don’t think it would be worth the time. If a C# programmer can’t convert the code samples/IDE shortcuts in their head then they are likely to struggle with this series anyway. If the community really requires a C#/VS version then allow someone from the community to translate them on your behalf. Same goes for any other languages.

Thanks again, I’ve learned an awful lot already.

Videos are great! Can you provide direct download link?

btw, repeating these videos in C# will be the waste of time. C# developers won’t have any problems in understanding these videos.

A series in C# would be very helpful for someone who is try to sink in with the concept of TDD, please add it.

• Getting Started Download
• Adding Basic Ops Download
• Removing Duplication Download
• Extracting to Strategy
• Removing Dups/Refactoring Download
• Removing Dups/Tdd Download
• Abstract Factory Download
• Sum Operator Download
• Prime Factors Download
• Composing Math Operators Download
• Using FitNesse Download

Yes C# would definitely be more helpful. Thanks.

I have been running similar series for C# world. More detail at http://mahendramavani.com/archive/2010/04/06/virtual-learning-series-ndash-beginnerrsquos-guide-to-software-craftsmanship.aspx

Basically it’s a virtual learning series that covers one topic per week (Every Thursday 10:30 CDT) and later on I post code sample and video for future reference.

Hope that might help somebody over here who are interested in C# version of video

I spend most of my days in VB.Net but had no problem following these (extremely useful) videos – don’t see the need for a C# version myself.

It looks like the moq was impressed by mockito (like most c# libs :P )

k2k,

I though Moq came first. So it might be the other way around. Anybody actually know the timeline?

I’ve checked the first commit on the google code (there is one month gap – so not for sure)

looks like there is no right answer :) http://monkeyisland.pl/2008/02/01/deathwish/

anyway – great videos – i really enjoy’em :)

Hi, awesome videos! But there is one thing i dont understand, why not use an enum instead of the factory? It will result in less code, and typesafe code. And alot less tests needed.

Micke,

Excellent question, with a whole lot of backdrop. Here’s a touch of that…

First, here’s a stat from Jerry Weinberg: 2/3 of all 1-line bug fixes introduce new defects. This is in one of his books and I personally confirmed it with in via email.

Of course, this number does not consider a situation where you have a huge regression suite of automated tests, even so, changing code is dangerous.

Second, you can look up for numbers, but approximately 80 – 95% of all product cost is done in what is classified as “maintenance”. So we spend more time in maintenance, than “building” – whatever the hell building means.

Requirements change, apparently well after we’ve released it, this is no surprise. It is dangerous to change existing code.

Closed (stable, not changing) enumerations are fine. However, like the open API of the RPN calculator, the enum will be open, which requires testing any time it changes.

So to me, an enum is basically the same (in terms of coupling and maintenance) as an open API when the enum is essentially selecting the operator (or operation, or whatever). Notice, the enum in this case identifies the type.

In practice, many people do not understand that switching on type can be a problem. In a factory, no, but elsewhere, it can lead to partial duplication of a switch.

So the enum really can lead to problems.

Here’s one problem. Imagine if the enum changes. Say the developer keeps the operators in alphabetical order. A change to an enum will force the client code to recompile. Forcing recompilation is a good way to greatly increase coupling, and also deployment size, and time to be ready to deploy. Anything we can do to reduce the size of a releasable component is a good thing for long-lived systems.

NOW, let’s go into counter arguments against what I just wrote.

1. The calculator is not likely to be a component, but a complete solution, so testing the whole thing and releasing it is probably not going to cause problems.

2. You are correct about a lost of type safety. This does not bother me. I’ve deployed solutions in statically typed languages and I’ve also released solutions in dynamically typed languages. I’ve been on projects where both worked and both failed. Not because of static typing (in the case of failures and successes).

3. In this case, we are strictly using the enum for selection of creation of a type. Not really a problem since this is one case where switching on a enum (or a string) is a reasonable solution.

But again, I get back to the open-ended nature of the enum. That does bother me (like the open-ended API). So when I see an open-ended enum, I think of it as a code smell. Remember, code smells are not all bad.

But for this particular solution, is it overkill? Probably. But then it’s not really a big deal, and I see this as nearly idiomatic, so this bit of over design does not bother me. Later on, it sure makes programming the calculator easy.

And to go one step further, what if we add the the factory the ability to ask for the names of all operators? And then add to each operator a description of what it does?

Finally, the enum in the calculator bothers me, but what if someone wanted to adapt it to have such type safety? Put it in an adapter, in client code. So the client code can own that. Or, I can imagine both interfaces. A typesafe that may or may not be up to date with all of the actual features, and the dynamic API.

In any case, I can say that you hit the nail on the head of a point that many people do not like about this problem the way I like to do it. Keep the idea in your back pocket. If it fits, use it. If it’s overkill, don’t use it.

+1 for c#

I agree next time you decide to do another TDD series, Visual Studio and C# would be nice, but still the principles are the same. Good work Brett!

Yes, C# would be really great. +1 for c#.

Thanks.

I’ve not watched this yet (I will when I have a moment!), but it would be great to see the series with C#, so I’ll add my vote!

Thanks for doing these videos. I’ve always found I hit a stumbling block when trying to get into TDD and things like this really help get me going.

Nice series. +1 for C# too.

Just for your info, people can also use ClipNabber (http://clipnabber.com/) to download videos from vimeo for offline viewing.

I very much love all your writing way, very helpful ?

M2TS to MKV Converter is the best software for user to convert M2TS to MKV file, With the powerful M2TS to MKV converter,you can convert M2TS to MKV with best quality and convert M2TS to all the video formats.m2ts to mkv converter

Great series that I’m finally catching up on. I think that the false starts enhance the usefulness of the videos. If you redo, you might pretend to make those same false starts. The only think you mihgt change are the times you made typos.

Bull-puncher knickers is always at leisure wear the limelight, cowboy comfortable and cool and refreshing knickers shading effect, it is become big period of change garments according to the spring love and melody. Loose t-shirts , vests even swimsuit can matching, become do not fall convention of change garments according to the collocation of the election.