Sergio Pereira : featured

Tim Barcz in the house, brought his keyboard

sergiopereira — Fri, 08 Aug 2008 14:14:00 GMT

We are adding a new contributor to Devlicio.us. Join me and welcome Tim Barcz and his blog posts to our site.

Tim will be another Midwest blogger, reporting from Cedar Rapids, Iowa. He is the president of the CRIneta and always involved with the local and global .NET community.

I've met Tim at the ALT.NET Conference in Seattle earlier this year, where we had a chance to chat quite a bit. I've always liked the positive attitude of his blog and we share the same goal of finding and provoking passion for software development.

Tim is moving his previous blog over here and not a minute too soon. Welcome aboard, Tim.

Beginning Continuous Improvement, A Case Study

sergiopereira — Fri, 27 Jun 2008 05:11:00 GMT

by: Glenn Goodrich

This post is the winner of The Great Devlicio.us Giveaway.

The story you are about to read is true. The names and identities of the innocent have been changed to protect them and my job. No animals were harmed in the writing of this story.

Roughly three to five years ago I was an intermediate ASP.NET Webforms developer. I had produced several applications for various clients that were in different stages of test/production/maintenance /graveyard. Some of these applications were loved by my clients, others were tolerated, and still others were abhorred. The aspects all of these applications did have in common were a high level of difficulty to maintain and an almost violent resistance to change. Most of my clients tend to generate requirements in a management bubble so during the first round of testing, (if it existed) or the first weeks stumbling through production deployment, the user feedback was very large. Of course, the client always desired make changes accommodating this feedback, which is often where my real troubles began.

There had to be a better way. So, I started combing the web, hoping to find people that solved issues like mine. Googling phrases like “extensibility”, “webforms pain”, and “easy asp.net deployment”. If memory serves, the first fish on the line was Rails. I did the Rails “Hello World” and was amazed at how fast you could get going, how easy you could add views, and how much of my nerd life I had wasted. Realizing that my clients were not quite ready for Rails (“Ruby on what??? Where’s the msi?”) I started looking for MVC in .NET. This, as you’ve probably guessed, landed me at the Castle Project. Monorail was just what I needed. I could shoehorn it past my clients’ open source/never-heard-of-that worries, because it was .NET. But this was just the beginning.

The Castle Project also had the Windsor Inversion of Control (IoC) container, which led me to things like “separation of concerns”, “single responsibility”, and the “open-closed principle”. It really started me down the path of Test Driven Development (TDD) which was probably the single biggest positive change to my coding practices. It was a little bumpy at first, but once I saw that I could get all my code working before I even had a web site application AND I could really test it, I was hooked.

I started reading the Castle Forums as well as Hammet’s blog and Ayende’s blog. Figuring they weren’t the only really smart people out there, I started reading tons of blogs (CodeBetter, Martin Fowler’s Bliki, etc.) which showed me the endless world of better design practices. I started reading books that weren’t from Microsoft Press (nothing against them, but there are a lot of good books out there) including Head First Design Patterns, which was another huge A-HA! moment for my development career. I now read blogs everyday and have at least two books going at any moment in time. I read about Continuous Integration and CI Factory, as well as NHibernate and other OR/M frameworks. This was my first steps into Continuous Improvement.

So, where is this going? Is there a success story in our future? Before you object to the relevance of my opening statement, we have finally arrived at my success. We were handed a very large client from a business partner, partially because that partner could not satisfy the needs of the client. The client (who I will call BigCo) wanted a web-based application to put in front of their customer-facing employees to, basically, figure out if BigCo could provide any services to new clients. There were various factors that affected BigCo’s ability to provide services to a given customer, and the application would have to perform the logic that determined each of these factors. For this article, we will call the application ProviderApp. ProviderApp had to do the following:

Collect information about the customer. Find out where the customer lived. See if BigCo had the ability to provide services to that location. If the location was good, show the employee which of BigCo’s services were available. Persist the results of this interaction.

So, BigCo wanted a prototype. Tapping into my new approach and knowledge, I started writing tests for my (persistent ignorant!) domain model. Customer, Address, ProviderResult, and other classes were the result. All clean and responsible only for themselves and fully tested. I used separation of concerns to partition out the factors into services, being sure to use interfaces. These services were also open for extension, but closed for modification. In fact, for testing, I actually wrote test-only providers, removing the need to invoke some needed external services that would be used in production. I had all the logic for the factors written and tested, all the domain model designed and tested before I had even created a web application. Also, thanks to CI, I knew when the build was broken immediately, so bugs didn’t have a chance to get stale, causing me to have to hunt for hours or days because I didn’t know when the bug was introduced. By the time I got around to the user interface (the web application) it was simply a matter of writing my views and consuming my services. Oh, and the act of writing pure HTML views was a breath of fresh air.

I finished the prototype a couple of days early, so we had to time to actually perform real user tests, which I don’t think I had ever seen before. The bugs found here were relatively small but made a big difference in our demonstration of the prototype. On demo day, BigCo was very happy with the prototype. They were not wowed, they were not dazzled. Their reaction is not the success story. The success story comes from the fact that I was relaxed on demo day, confident the software was solid. I had no anxiety about getting off the beaten path, which was new for me. In fact, I let the BigCo folks drive the application at the end of the meeting and told them to show it to whomever they liked later. There is no way I would have been confident enough in my previous life to let a client demo my “prototype” code.

At the end of the meeting, the BigCo people asked me how long it would take to “make this real”, which is when my success story really sunk in. I realized, right there in front of them, that the application was done. My answer was a matter of days, as I did have to write new providers for a couple of the services, since they were using different back-ends then the prototype, but that was it. They also asked about some changes, a question that would have usually caused my ulcer to start. Each of their requests was a trivial change, taking me a few minutes to incorporate.

I remember walking out of that meeting realizing I had taken a huge step in my career. We are still doing a lot of work with BigCo, and they are a happy client. I no longer fear change, and am still continuously improving.

Well, I didn’t mention DDD, because I haven’t gotten to it yet (it’s on the list, which seems to get longer all the time) but I hope you’ll consider my contribution. Either way, I had a lot of fun writing this.

Giveaway result

sergiopereira — Thu, 26 Jun 2008 17:29:00 GMT

We've just finished tallying up our votes for the Great Devlicio.us Giveaway and we are pleased to announce that the winner is Glenn Goodrich. We had enough entries to make the contest worthwhile and we decided to give prizes for every story. Everyone got one of the books in the original list and the 2nd place also got Visual Studio Team System. You see? I told you that you should tell us your story.

Some people asked if there will be a contest where they could submit horror stories instead of success stories. Well, I'm considering running a contest for that, but I'm afraid the prize will be limited to a bag of Doritos.

Glenn runs a very nice blog and his story, which will be posted here tomorrow, shows that the quest for a better way to develop applications or, in broader terms, the constant pursuit of improvement should be in our DNA.

I'll quote from his story:

... Head First Design Patterns, which was another huge A-HA! moment for my development career. I now read blogs everyday and have at least two books going at any moment in time. I read about Continuous Integration and CI Factory, as well as NHibernate and other OR/M frameworks. This was my first steps into Continuous Improvement.

...I was relaxed on demo day, confident the software was solid. I had no anxiety about getting off the beaten path, which was new for me.

Congratulations to Glenn, we are very happy that the prizes are being given to such deserving hands. You make us proud, Glenn.

Be sure to check back tomorrow with the full story.

The Great Devlicio.us Giveaway

sergiopereira — Thu, 05 Jun 2008 23:02:00 GMT

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.

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.
Domain-Driven Design: Tackling Complexity in the Heart of Software: Eric Evans describes DDD and how your software design can benefit from it.
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.
Patterns of Enterprise Application Architecture: In this classic, Martin Fowler lays down the law on how an enterprise application needs to be designed.
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.
Implementing Lean Software Development: This book by Tom and Mary Poppendieck distills practices to optimize the development process.
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.
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.

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...
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).
The winner will be chosen by voting among the Devlicio.us bloggers. This might take up to 1 week.
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.)
Shortly after that, the winner will be contacted for mailing address information and the prize will be shipped.
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.

Designing With Lambdas - Part III

sergiopereira — Tue, 29 Apr 2008 19:30:00 GMT

In the previous two installments of the series we discussed how we can use lambdas to encapsulate more processing logic and to create contextual APIs. In this post I will show another example of the latter.

Navigating directory structures

This time around we will try to create a safe way to browse and create directories without losing track of the current location. When we write code to read files or directory information from a directory structure, and we need to look into more than one directory, we have to be careful to always be sure of what the current working directory is or use only absolute paths. Neither approach is without its inconveniences.

What I'll try to show here is a way to enforce the working directory as a lambda context. That can be a mouthful so let me try to put it in simpler terms. I'd like to have a way to assert that when a particular code runs, the working directory will be changed to a specified location, and after that code finishes the working directory is restored automatically.

Without lambdas, the context setting could resemble the following:

string previousDir = Environment.CurrentDirectory;
try
{
	Environment.CurrentDirectory = @"c:\myapp";
	DoStuff();

	try
	{
		Environment.CurrentDirectory = 
				@"c:\myapp\subdirs\resources\images\toolbar";
		DoOtherStuff();
	}
	finally
	{
		Environment.CurrentDirectory = @"c:\myapp";
	}

	DoMoreStuff();
}
finally
{
	Environment.CurrentDirectory = previousDir;
}

All those try and finally are there to make sure we restore the appropriate working directory after we are done with each one. I don't know about you, but having a lot of those in my code would add a lot of noise, obscuring the real intent of the code.

What if we could, once again, encapsulate this pattern in a function that accepts a delegate? Here's what a way more revealing code would look like.

Dir.Change(@"c:\myapp", path =>
{
	//we're in c:\myapp
	Dir.Change(subdir =>
	{
		//we're in c:\myapp\subdir
		string dirName = DateTime.Now.ToString("yyyy-MM-dd");
		//we can ask it to create the directory if 
		//  not found (the "true" parameter)
		Dir.Change(dirName, true, dailyLogDir =>
		{
			//we're in c:\myapp\subdir\2008-04-29 (for example)
			using(StreamWriter wr = File.CreateText("logfile.txt"))
			{
				wr.WriteLine("Hello file.");
			}
		});

		//we're back in c:\myapp\subdir

		//we can pass in a deeper path
		Dir.Change(@"resources\images\toolbar", imagesDir =>
		{
			//we're in c:\myapp\subdir\resources\images\toolbar
			//listing all files here
			foreach(string file in imagesDir.GetFiles("*.png"))
				Console.WriteLine("Toolbar icon: " + file);

		});
	});
});

Within each Dir.Change block we can be certain that the current working directory will be the one we specified (unless your own code intentionally changes it.) When the code block finishes, we will be back to whatever directory we were before the block, guaranteed.

Note in line 4 that the name of the directory can be gathered from the parameter's name subdir. This is not always possible because we could be dealing with multi-level directory changes (line 22) or dynamically generated directory names (line 10). Additionally, the rules for naming directories are not the same as for naming C# identifiers. For these reasons, it's also possible to pass a string containing the name of the desired directory.

Here's the code that makes this possible.

public static class Dir
{
	public static void Change(Action<DirectoryInfo> execute)
	{
		Change(false, execute);
	}

	public static void Change(string path, Action<DirectoryInfo> execute)
	{
		Change(path, false, execute);
	}

	public static void Change(bool createIfNeeded, Action<DirectoryInfo> execute)
	{
		string path = execute.Method.GetParameters()[0].Name;
		Change(path, createIfNeeded, execute);
	}

	public static void Change(string path, bool createIfNeeded, 
							Action<DirectoryInfo> execute)
	{
		string previousDir = Environment.CurrentDirectory;

		try
		{
			if(createIfNeeded && !Directory.Exists(path))
				Directory.CreateDirectory(path);

			var di = new DirectoryInfo(path);
			Environment.CurrentDirectory = path;
			execute(di);
		}
		finally
		{
			Environment.CurrentDirectory = previousDir;
		}
	}

	public static bool TryChange(string path, Action<DirectoryInfo> execute)
	{
		if(Directory.Exists(path))
		{
			Change(path, false, execute);
			return true;
		}
		else
		{
			return false;
		}
	}
}

So there you have it. Another example of incorporating lambdas to design APIs that attempt to reduce code noise and eventually read more naturally. Hopefully you're starting to see a pattern here in terms of what a context can be and how lambda-aware APIs can help formalizing that context.

Redmond, the center of the ALT.NET universe

sergiopereira — Thu, 17 Apr 2008 14:12:00 GMT

...at least for the next three days

Tomorrow I'm hopping on a plane to Seattle/Redmond, WA to take part in the second ALT.NET Open Spaces Conference. I had the chance to be at the first one last October in Austin, TX and what a great experience that was.

My main motivation to attend the event in Austin was to learn from the more experienced folks how they adopted these practices and culture in their organizations. I wanted to participate in discussion about creating interest in self-improvement in my organization, my local .Net community, and eventually in the global .Net ecosystem.

The sessions I took part in included mostly these topics, like how can we help MSDN and MSDN Magazine become a great vehicle for spreading into the .Net community, among other things, practices that go beyond what Visual Studio shows in its Add » New Item, and the lessons that we can learn from the non-.Net space. The March 2008 issue of the magazine was a glimpse at what types of techniques and tools we could be seeing applied by more .Net developers, helping create more maintainable applications and more scalable development and support processes.

This time around I'm hoping to be in discussions that are more specific of Agile processes. I want to understand how to get started and how demonstrable Agile value really is. I'm tired of reading from people that quickly attached themselves to the Agile label just because it looks like the thing to do at the moment. I, for one have never experienced Agile in any organization I worked at. This event will give us a great opportunity to hear and question some of the people that are really employing Agile and experiencing some form of benefit from it. I want to make sure Agile isn't just another bandwagon.

There's always the risk that events like this become the proverbial echo chamber, where folks that think alike tap each other's back, celebrate their common thinking, and waste time discussion irrelevant technicalities. I'm happy to see a lot of blue badges and even people that I'm sure will be there to challenge ALT.NET to put up or shut up. One such individual is JDN — if you read the altdotnet mailing list you're familiar with his point of view. I think that is a good thing.

So, if you happen to be there too and see me, come and talk. That's why we are there for, right. And I'm not one of these guys that can only talk about software. I could spend hours chatting about other things like soccer and .... and ... darn it! Nevermind :)

Designing With Lambdas - Part I

sergiopereira — Sat, 12 Apr 2008 21:25:00 GMT

When our programming language of choice gets a new feature, it's usually not that hard to start using that feature right away from a consumer's point of view.

I could use the introduction of generics in .Net 2.0 as an example. When I wrote my first C# 2.0 piece of code, it already made use of the existing generic classes and methods, especially the ones in the System.Collections.Generic namespace such as List<T> and Dictionary<TKey,TValue>.

But it took a little more time until I learned how to design my own classes offering generic functionality. Reaching the balance of when to create generic classes, when to create generic methods, or when not to use generics only comes with some exercise.

I think this will be the case with lambdas for many people, including myself. Detecting opportunities to apply lambdas can make all the difference between a class that is a joy to use and one that is just the same old thing.

Processing lines in a file

My first example will be a more concise and less error-prone way of processing lines in a text file. Consider this hopefully familiar piece of code.

using(StreamReader rd = File.OpenText("Data.txt"))
{
	string line = rd.ReadLine();
	while(line != null)
	{
		DoSomething(line);
		// do more stuff with the line text

		//move on
		line = rd.ReadLine();
	}
}

How many times have you written something like this over and over? I know I did. If I were to compare the various times I implemented this, I would probably notice that the only thing that is different is the logic inside the while block. This should be a clue that a delegate or lambda could help make this pattern reusable.

But how do we create a reusable method that performs this common task without providing the logic inside the while? The last paragraph gave away the answer: delegates.

Let's create a helper class with a method to encapsulate the pattern at hand.

public static class FileUtil
{
	public static void EachLine(string fileName, Action<string> process)
	{
		using(StreamReader rd = File.OpenText(fileName))
		{
			string line = rd.ReadLine();
			while(line != null)
			{
				process(line);
				line = rd.ReadLine();
			}
		}
	}
}

The body of the EachLine method is almost the same as the original implementation we started with. The difference, as expected, is that we replaced the DoSomething(line) with a call to process, which is a delegate of type Action<string>, meaning that it expects a function that accepts a single parameter of type string and does not have a return value.

Using our new method, we can rewrite the original example like this.

FileUtil.EachLine("Data.txt", line => DoSomething(line));

Not bad. In this particular case, because we are just forwarding the line parameter to DoSomething, the call can be further simplified taking advantage of C#'s new shortened delegate creation syntax.

FileUtil.EachLine("Data.txt", DoSomething );

There you have it. Hopefully this assists someone in their journey in this new lambda thing.

Automation FTW

sergiopereira — Fri, 28 Mar 2008 01:12:00 GMT

One of the things I often discuss with other developers is how little (on average) we automate our work-related tasks.

Think about this. We make our living automating our users' activities:

We write applications to replace manual processes.
Our programs send notifications so that they users don't need to waste time checking for process status.
We make our programs talk to each other and to third party systems so that the slow and expensive human interaction is avoided,
In more general terms, we go through great lengths to ensure our users are adequately empowered and hopefully more productive.

Contrast that to the way we historically see developers conducting their daily chores.

We often work with incredibly powerful IDEs or text editors with macro support or even an extensibility model. When was the last time you employed a macro?
How many times will that manager will have to send you that updated Excel spreadsheet or CSV file until you write a script to verify each line instead of the tiresome and error-prone manual check you have been doing?
Aren't you tired of keeping track of which files changed since last time you updated the application? Have you ever thought your Source Control Management tool could make this much simpler?
Are you kidding me? You're writing that same SQL query for the Nth time? How hard is to save this query for a change?
If your work cycle looks like this: Save, Build (wait), Debug (wait), Click, Click, Click, Type, Type, Click, Verify result, OK; someone needs to introduce you to a unit testing tool immediately.

I'm as guilty as the next guy of falling in one of the the above anti-patterns. The way I found to make these traps the exception, not the norm, was to make them less comfortable than the automated alternative. The key in the entire process is lowering the automation entry barrier by learning. It also helps if you cultivate a positive attitude toward learning.

Here's my laundry list of steps to make those CPU cores earn their salt and leave my own processing power for more challenging things. I have some of these items pegged but I'm not done with all of them yet.

Take the time to explore and learn the capabilities of your IDE/text editor. Find a cheat sheet and print it. Learn one or two interesting keyboard shortcuts every day. Learn how to write/record a macro, it's usually so easy that you'll be ashamed you hadn't done that before. Some tools even have strong user communities sharing macros. See how your IDE can be extended, if it's beyond your reach, maybe there are third party productivity add-ons that will boost your productivity and pay for themselves quickly (if not already free.)
Other applications, like MS Office apps, also have a rich extensibility and automation model behind them. If that application insists in being part of your workflow, investigate how you can show it who the boss is.
One of the best things I've done in the recent years was to add a scripting language to my toolbox. I highly recommend that. If possible pick a scripting language that is reasonably different from your primary development language, it will make the learning phase more interesting. I'm currently working with C#, so I thought Ruby would be an interesting language for scripting tasks, and that's what I use most of the time.
Be adamant about using your SCM as part of your deployment process. Learn how to do labeling/tagging, diffs, updates, etc not only using the GUI but also through an API or the command line. You'll be writing scripts against your SCM in no time and the weight of tracking changed files will be lifted.
I tend to include a tools directory within each project directory structure where I keep (among other things) all the scripts I create to assist development and maintenance of the application. These files can be SQL scripts, Ruby scripts, .bat files, and anything that can be repeatedly executed. Some scripts turn out to be generic enough that I keep them in a common location, such as c:\projetcs\tools.
I won't attempt to get yo hooked on TDD or Continuous Integration here, that's something for another day. I will say, though, that if you don't already use an automated unit testing framework, you owe yourself a closer look into that. Why write several test applications or run the entire application all the time to manually verify that everything still works when there are tools to automate this? Take a look at JUnit/NUnit (the xUnit family), RSpec or whatever there is in your language of choice.
No text about software development automation would be complete without at least mentioning build automation tools. Tools like Ant (NAnt), MSBuild, Make, Rake go a long way toward providing complete solutions for automating the build, testing, packaging/deploying of an application. Very few things are more satisfying than executing go.bat and seeing your application being compiled, configured, and tested in a fraction of the time that it used to take when you did all this manually.

As many things in life, the hardest part is getting started. Once you have your first one or two tasks automated, you will be more aware of tasks that can be automated and you will be more confident that you can indeed automate this task that you were just about to start for the second time.