Sergio and the sigil

The Great Devlicio.us Giveaway

Posted by Sergio on 2008-06-05

Because there's more than one kind of hero

Update: The contest is now closed. We cannot accept any more entries. Wait for the winner announcement is a few days. Thanks for all the great submissions.

Here's your chance to win a well-deserved prize for being a good developer — and not just any prize. Devlicio.us, with the generous support from Microsoft (via Somasegar) and Addison-Wesley, is proud to present you with a contest that will dump a truckload of goodness at your doorstep. This ultimate prize package contains the following items.

  1. Agile Principles, Patterns, and Practices in C#: Uncle Bob's must-have work. This book needs to be part of your Agile and OOD bookshelf.
  2. Domain-Driven Design: Tackling Complexity in the Heart of Software: Eric Evans describes DDD and how your software design can benefit from it.
  3. Applying Domain-Driven Design and Patterns: Armed with the DDD knowlegde, now it's time to let Jimmy Nilsson show us how to implement solid .NET code.
  4. Patterns of Enterprise Application Architecture: In this classic, Martin Fowler lays down the law on how an enterprise application needs to be designed.
  5. Working Effectively with Legacy Code: We've all been there. It's hard and Michael Feathers does a great job in guiding us through the challenges and techniques to get you out of the quicksand.
  6. Implementing Lean Software Development: This book by Tom and Mary Poppendieck distills practices to optimize the development process.
  7. The Pragmatic Programmer: From Journeyman to Master: No list of this caliber would be complete without Andy Hunt and Dave Thomas' ultimate guide to developer proficiency.
  8. Visual Studio 2008 Team Suite + MSDN Premium: No need for explanations here. A $10K+ retail value item with all you'll ever need in terms of Microsoft technology.



The Contest

I hope the prizes got you excited. I actually envy you because I cannot participate. The contest is pretty simple.

  1. We are looking for success stories. Submit a true story that happened to you or your team where adopting good software development practices rescued a project or even the entire organization. The stories we want to award are the ones that demonstrate a direct relation between good practices or good design (or both) and successful solutions. Examples:
    • Continuous Integration saved my job.
    • DDD made my application survive the test of time.
    • My team went from grumpy to engaged after we introduced collective design ownership.
    • etc...
  2. Submit your stories by email or using the Contact link to any of the Devlicio.us bloggers between today (June 5th 2008) and ~2 weeks from today (June 20th 2008 by 5 PM ET GMT-4:00).
  3. The winner will be chosen by voting among the Devlicio.us bloggers. This might take up to 1 week.
  4. The winner story will be announced on Devlicio.us on or before June 20th and it will become a guest blog post on the blog to which it was submitted (so remember to protect the innocent in your story.)
  5. Shortly after that, the winner will be contacted for mailing address information and the prize will be shipped.
  6. Other stories might be selected to feature as blog posts as well - with or without any prizes.

Restrictions

The stories need to be of your own personal experience, within your team or your organization. Since the story has a chance of being posted in Devlicio.us, make sure the people and organizations mentioned in the story are OK with that or replace their names.

We think we can ship the prize anywhere but if you're not in the U.S. and there's some form of export or import regulation that prohibits the shipment of software or even the books, then we may not be able to send it to you.

Get to the writing already

We are anxious to hear your stories. Prizes like these don't come by often and we really want to reward someone for doing the right thing.

Coding style per project

Posted by Sergio on 2008-06-01

A few months ago, when I installed Visual Studio 2008 on my system, I opened one of my projects, did the usual project conversion, edited some files, created a few others, saved, tested, and checked in source control. Another developer working on the same project, also with VS2008, later edited some of the same files I had edited.

Then I went to do a diff to verify the changes and I saw what I always hate to see. He hadn't changed a lot of code, but he was using different style settings in VS and all the extra spaces around ifs, function arguments, etc were making it harder to find the important changes. To be fair, I was the one that forgot to adjust my default settings to be more compatible with our current coding style.

The situation above is not all that critical, but is certainly a big annoyance. Some diff programs will allow you to ignore white space differences but it is still sickening to see your source code with mixed code formatting style in the same file, sometimes in the same method.

That kept me thinking: why aren't code format style settings part of the project? Imagine if you work for two different clients, with different standards, or that you are a contributor to Open Source projects that also have different opinions about code format. It's too easy to forget to adjust your settings every time you switch projects, even if you export and save the appropriate VS settings to import as needed. Any IDE with so many options as VS should offer an option to save any settings that deal with the actual code be part of the project. A developer should be able to explicitly ignore or change the project settings but not by default.

With that problem in mind, I thought it would be useful to just adopt the practice of exporting the VS settings that are relevant to the project coding style and checking that in source control too. Here's what I did.

Fire up the the Import and Export settings wizard and choose only the settings that relate to code formatting and for the languages the project uses, for example C#, HTML, and XML. In this case we will just do the C# settings.

 

Right here we hit a limitation in VS. There's no way to select only the code formatting settings for C#, so we will export all of them anyway. Once we do that, save the file to the project directory (like MyProject.vssettings) and add it to the project or solution. Open it in VS (it's just XML) an stare at the plethora of settings that are saved.

<UserSettings>
	  <ApplicationIdentity version="9.0"/>
	  <ToolsOptions>
	    <ToolsOptionsCategory name="TextEditor"
	    RegisteredName="TextEditor">
	      <ToolsOptionsSubCategory name="CSharp"
	    RegisteredName="CSharp" PackageName="Text Management Package">
	        <PropertyValue name="TabSize">4</PropertyValue>
	        <PropertyValue name="AutoListMembers">true</PropertyValue>
	        <!-- ...(snip)... -->
	        <PropertyValue name="AutoListParams">true</PropertyValue>
	      </ToolsOptionsSubCategory>
	      <ToolsOptionsSubCategory name="CSharp-Specific"
	    RegisteredName="CSharp-Specific"
	    PackageName="Visual C# Language Service Package">
	        <PropertyValue name="NewLines_QueryExpression_EachClause">1</PropertyValue>
	        <PropertyValue name="Space_Normalize">0</PropertyValue>
	        <PropertyValue name="WarnWhenMembersCauseCompilerGeneratedReferences">1</PropertyValue>
	        <PropertyValue name="CollapseInactiveBlocksOnOpen">1</PropertyValue>
	        <PropertyValue name="Watson_MaxExceptionsToReport">1</PropertyValue>
	        <PropertyValue name="EditAndContinueReportEnterBreakStateFailure">1</PropertyValue>
	        <!-- ...(snip)... -->
	        <PropertyValue name="RemoveUnusedUsings">1</PropertyValue>
	        <PropertyValue name="Rename_Overloads">0</PropertyValue>
	        <PropertyValue name="EncapsulateField_SearchInComments">0</PropertyValue>
	        <PropertyValue name="ProgressDialogDelaySeconds">2</PropertyValue>
	      </ToolsOptionsSubCategory>
	    </ToolsOptionsCategory>
	  </ToolsOptions>
	</UserSettings>

Upon closer inspection, we can more or less recognize each settings by their names. Let's remove the ones that don't seem to be related to code formatting. This is more or less a value judgment on the importance of some of the settings. My choice was to keep TabSize, IndentStyle, and InsertTabs in the first subcategory and, for the second subcategory, I'm keeping any of the setting whose name starts with NewLines_, Indent_, or Space_ and also the item named SortUsings.(I should probably just write a macro to do that at some point)

After all this sanitizing, my settings file is reduced to the following:

<UserSettings>
	  <ApplicationIdentity version="9.0"/>
	  <ToolsOptions>
	    <ToolsOptionsCategory name="TextEditor"
	    RegisteredName="TextEditor">
	      <ToolsOptionsSubCategory name="CSharp"
	    RegisteredName="CSharp" PackageName="Text Management Package">
	        <PropertyValue name="TabSize">4</PropertyValue>
	        <PropertyValue name="IndentStyle">2</PropertyValue>
	        <PropertyValue name="InsertTabs">true</PropertyValue>
	      </ToolsOptionsSubCategory>
	      <ToolsOptionsSubCategory name="CSharp-Specific"
	    RegisteredName="CSharp-Specific"
	    PackageName="Visual C# Language Service Package">
	        <PropertyValue name="NewLines_QueryExpression_EachClause">1</PropertyValue>
	        <PropertyValue name="Space_Normalize">0</PropertyValue>
	        <PropertyValue name="Space_AroundBinaryOperator">1</PropertyValue>
	        <PropertyValue name="NewLines_Braces_Method">1</PropertyValue>
	        <PropertyValue name="Indent_CaseLabels">1</PropertyValue>
	        <PropertyValue name="NewLines_Braces_ControlFlow">1</PropertyValue>
	        <PropertyValue name="NewLines_Braces_AnonymousMethod">1</PropertyValue>
	        <PropertyValue name="Space_WithinOtherParentheses">0</PropertyValue>
	        <PropertyValue name="Space_AfterBasesColon">1</PropertyValue>
	        <PropertyValue name="Indent_Braces">0</PropertyValue>
	        <PropertyValue name="Space_WithinMethodCallParentheses">0</PropertyValue>
	        <PropertyValue name="Space_AfterCast">0</PropertyValue>
	        <PropertyValue name="NewLines_Braces_CollectionInitializer">0</PropertyValue>
	        <PropertyValue name="NewLines_AnonymousTypeInitializer_EachMember">1</PropertyValue>
	        <PropertyValue name="NewLines_Keywords_Catch">1</PropertyValue>
	        <PropertyValue name="NewLines_Braces_ObjectInitializer">1</PropertyValue>
	        <PropertyValue name="NewLines_Braces_ArrayInitializer">0</PropertyValue>
	        <PropertyValue name="Space_WithinExpressionParentheses">0</PropertyValue>
	        <PropertyValue name="Space_InControlFlowConstruct">0</PropertyValue>
	        <PropertyValue name="Space_BetweenEmptyMethodDeclarationParentheses">0</PropertyValue>
	        <PropertyValue name="Indent_UnindentLabels">1</PropertyValue>
	        <PropertyValue name="SortUsings">1</PropertyValue>
	        <PropertyValue name="NewLines_ObjectInitializer_EachMember">1</PropertyValue>
	        <PropertyValue name="Space_WithinMethodDeclarationParentheses">0</PropertyValue>
	        <PropertyValue name="Space_BetweenEmptyMethodCallParentheses">0</PropertyValue>
	        <PropertyValue name="Space_BeforeSemicolonsInForStatement">0</PropertyValue>
	        <PropertyValue name="Space_BeforeComma">0</PropertyValue>
	        <PropertyValue name="Space_AfterMethodCallName">0</PropertyValue>
	        <PropertyValue name="Space_AfterComma">1</PropertyValue>
	        <PropertyValue name="Space_BeforeBasesColon">1</PropertyValue>
	        <PropertyValue name="Space_AfterMethodDeclarationName">0</PropertyValue>
	        <PropertyValue name="Space_AfterDot">0</PropertyValue>
	        <PropertyValue name="NewLines_Braces_Type">1</PropertyValue>
	        <PropertyValue name="Space_AfterLambdaArrow">1</PropertyValue>
	        <PropertyValue name="NewLines_Braces_LambdaExpressionBody">1</PropertyValue>
	        <PropertyValue name="Space_WithinSquares">0</PropertyValue>
	        <PropertyValue name="Space_BeforeLambdaArrow">1</PropertyValue>
	        <PropertyValue name="NewLines_Braces_AnonymousTypeInitializer">1</PropertyValue>
	        <PropertyValue name="Space_WithinCastParentheses">0</PropertyValue>
	        <PropertyValue name="Space_AfterSemicolonsInForStatement">1</PropertyValue>
	        <PropertyValue name="Indent_CaseContents">1</PropertyValue>
	        <PropertyValue name="Indent_FlushLabelsLeft">0</PropertyValue>
	        <PropertyValue name="Space_BetweenEmptySquares">0</PropertyValue>
	        <PropertyValue name="Space_BeforeOpenSquare">0</PropertyValue>
	        <PropertyValue name="Space_BeforeDot">0</PropertyValue>
	        <PropertyValue name="Indent_BlockContents">1</PropertyValue>
	      </ToolsOptionsSubCategory>
	    </ToolsOptionsCategory>
	  </ToolsOptions>
	</UserSettings>

It sucks that I still have to remember to load the settings for each project before making changes in that project, but at least I don't have to remember which individual settings to use for each project.

How do you handle this situation? Do you just live with the inconsistencies or is there an alternative way to deal with this issue? Are you using StyleCop (a.k.a. MS Source Analysis) or something like it to enforce some or all of the rules?

The Fluent Interfaces or DSLs Conundrum

Posted by Sergio on 2008-05-21

Maybe I'm just behind the curve on this one, but I don't understand the fascination with building internal DSLs (or the so-called fluent APIs) in C#. The argument is usually that they are expressive and readable but, since these are subjective assessments, I happen to disagree on both counts. They would need to bring some other values to the table to convince me to use them without being annoyed.

I think C# is not well suited for this task and maybe we should just stop trying to imitate what we see in other languages.

The idea that we can create classes named Is or Returns or With just rubs me the wrong way. At the present moment I hope this trend is just a fad. I'm willing to be proven wrong and suddenly "get it." Time will tell.

Take the following snippet using Rhino Mocks.

With.Mocks(mocks).Expecting(() =>
{
    Expect
	.Call(dependency.GetSomething("p1"))
	.IgnoreArguments()      
	.Repeat      
	.Once() 
	.Return("result");
    dependency.DoSomething();
})

Imagine yourself trying to setup this expectations. You know that when calling dependency.GetSomething("parameter") it should return "result". How would you discover that the With class is your starting point? Then look at the lambda code. I'd imagine your first reaction would be to look for a method in Expect that would take both the method call and the result. I'd say your first reaction is appropriate, after all this is still supposed to be C# code.

Maybe the desire behind these fluent interfaces is to make the API have a little more keyword wannabes at the expense of tolerating all the punctuation and ceremony that comes along.

In other languages this type of APIs are more popular because the language lends itself more adequately to this design. I'm not an Objective-C programmer but take a look at this line.

[expect call:[dependency getSomething:@"p1"], repeat:1, returns:@"result"];

Or in Ruby, probably leveraging the method_missing goodness behind the scenes:

dependency.expectCall.getSomething("p1", 
	:ignore_arguments => true, 
	:repeat => :once,
	:returns => "result"
	)

For a Objective-C or Ruby developer the above translations probably read more natural than the C# version for a C# developer.

I'm using Rhino Mocks as an example because it is fairly popular. I'm not trying to pick on it. Just to give another example of a fluent interface, recent versions of NUnit come with the Constraint Model for assertions:

Assert.That( ex3, Is.Not.SameAs( ex1 ) );

Again, classes, properties, and methods being used as quasi-operators, trying to blur the lines between language features and the custom API. But C# fights back and makes clear that it is not open for these kinds of extensions and throws a bunch of punctuation at you. To me this just doesn't feel fluent. It doesn't read like English nor like C#. It's more like some schizophrenic middle-of-the-road compromise.

It's possible that this desire to write fluent interfaces and DSLs becomes just a gateway to a more appropriate language like IronRuby or even Boo (to stay in the .Net universe.) Or, who knows, maybe C# changes to be more friendly to these designs. I will not be surprised if, in a few years, we look back at all these implementations and feel a little embarrassed for trying so hard to recreate an experience that is just not viable. Equally, I will not be surprised if I'm proved wrong, jump on the bandwagon, and regret having ever written this piece.

And the winner is... VB.NET ?!

Posted by Sergio on 2008-05-18

Every time I see an updated version of the TIOBE index it strikes me differently. Sometimes I'm surprised to see some programming languages in the TOP 20 that I didn't even know existed (happens all the time,) sometimes it's the realization of the languages on the rise like Ruby and Lua in recent years.

Take a look at this month's list.

1 Java 20.176%
 
2 C 15.292%
 
3 (Visual) Basic 10.782%
 
4 PHP 10.637%
 
5 C++ 10.484%
 
6 Perl 5.869%
 
7 Python 4.613%
 
8 C# 3.963%
 
9 Ruby 2.851%
 
10 Delphi 2.641%
 
11 JavaScript 2.411%
 
12 D 1.314%
 
13 SAS 0.738%
 
14 PL/SQL 0.625%
 
15 Pascal 0.498%
 
16 Lisp/Scheme 0.449%
 
17 Ada 0.431%
 
18 COBOL 0.411%
 
19 Lua 0.393%
 
20 FoxPro/xBase 0.385%
 

This month, although not new, what hit me was the state of the .Net languages. I'm definitely a C# guy. You'd have to tempt me with serious money to get me doing VB.Net again (IronRuby, on the other hand, would be a different story ;)

Although I'm not exactly surprised to see the .Net languages being dwarfed by other heavy hitters like Java and C, which enjoy a little more platform-independence, it's always an humbling effect seeing VB that far ahead of C#.

The interesting thing with this index is how it is built. It serves as a good thermometer to what kind of support you can expect to find on the Internet for that language. That's why it surprises me in relation to Visual Basic in particular.

I understand the index lumps together VB.NET, VB6, plain Basic, etc, but the non-Net versions of VB have been considered legacy for so long now that I tend to think VB.NET is indeed what is pushing Visual Basic to the top.

Maybe it's just because "Visual Basic" or "VB" as much easier search terms than "C#", "CSharp", "C-sharp", etc.

I've been reading about .Net online for almost 8 years now and C# has always seemed more prevalent than VB.NET in article, samples, documentation, and Open Source projects.

What about you? Anything interesting in this list? Is VB really the bomb?

Give JavaScript a chance

Posted by Sergio on 2008-05-03

Let me be the first one to admit taking way too much time to give in and embrace JavaScript. This language is arguably one of the most widely deployed and most misunderstood at the same time. There must be an award somewhere for this amazing feat.

I don't know what causes developers to avoid JavaScript in this day and age. I mean, back in 1995 when it was being introduced, I could understand the disdain. Back then it was a new language with a poorly chosen name (no, ECMAScript doesn't help either) and, probably the biggest problem, a lot of pain associated with the bug-laden and incompatible browser implementations of both JavaScript and the DOM.

Today, on the other hand, I don't see a really justifiable reason for a web developer avoid writing rich JavaScript. We have a very viable install base of browsers with decent implementations of JavaScript and the DOM (not perfect nor uniform, but doable,) we have better development tools, incredible browser extensions, debuggers, unit testing helpers, documentation generators, and, what in my opinion made JavaScript a true professional language: great libraries.

My hat goes off to Prototype.js, Scriptaculous, jQuery, Dojo, YUI, ASP.NET Ajax, etc. The folks behind these libraries really helped JavaScript adoption and boosted developer productivity. They pushed the language to its limits and amazed us with what could be accomplished with a language we used to simply copy, paste, adjust, and pray it worked.

I read this somewhere that I can't remember now, but it's a perfect analogy: You wouldn't write .Net code without the BCL, so why write JavaScript without good libraries?

I see a lot of effort being put into, once again, taking JavaScript away from the developer's code editor, and I honestly don't like that.

Things like GWT, Volta (me too, me too), Script#, and RJS (plus helpers) sound like too much work only to not let developers use JavaScript directly. Why do I need a to write code in one language just to produce code in another language that is perfectly usable? JavaScript is not Assembly, MSIL, or Java byte-code. We can actually write, document, test, debug, version, and deploy JavaScript.

I don't know what is your reason not to use JavaScript but maybe it falls into one of the following categories.

  • You think JavaScript is hard: It's not, I swear. Think about this for a second, JavaScript is considerably smaller than C#/Java/Ruby/VB. Maybe the problem you have is that you are being fooled by the curly braces and thinking JavaScript relates to C or Java or C#. JavaScript only has superficial similarities with those languages. The best advice I can give is to get yourself a good JavaScript book. There aren't many good books but I'll leave links for a couple at the end.
  • It's a lot of effort to get anything done: Just pick a JavaScript library and play with it. There's a wealth of solid solutions and widgets for all sorts of things.
  • I like to write all my code in C# (or VB, or Java, etc) I don't want to get into the debate about polyglot programming in this post but afraid you're setting yourself up for grief and failure. You don't want to ride your mountain-bike in the sand dunes or drive our sedan on the train tracks.
  • But my users can turn off JavaScript in their browsers: That never stopped people from writing VC++/MFC, Java, .Net, or even VB6 applications. You'll have the same problem if you're letting your JavaScript be generated on your behalf.

If you think you need to brush up you JavaScript but don't have a lot of time right now, I'd recommend at least watching the videos linked below.

Links

Libraries

Books

Tools

Videos