Brian On Software

This is the fifth and sixth post for "This Week’s Geek Links".  I’m making up for last week due to lack of time on my part to gather relevant material…sometimes it feels good to take a break from all this computing "machinery".

Highly recommended to watch this week

• "Blind Kid uses Echolocation to ‘See’"
  This is one the most amazing and humbling story I’ve heard in my life.  It’s about a young man, Ben Underwood, whose eyes were removed due to retinal cancer.  Though blind, Ben can really "see" well and do things beyond what people with sight can do.  For example, he plays video games, writes novels, is learning Japanese to study in Japan, uses Echolocation the same way we’ll use a GPS to guide our steps, etc.  He’s full of life and a symbol of great courage.  A must see!
  

Articles

• "How Hard Could It Be?: Lessons I Learned in the Army"
  Ex-Microsoft employee gone entrepreneur and prolific blogger, Joel Spolsky wrote an article for Inc.com in which he contrasts his experience in the army with the world of software development today.  I think his article is more aimed at software development managers, team leaders or anyone in a leadership position within a software development organization; so if you’re in that kind of position, this article is for you.  The main idea about Joel’s article is that, in most cases, higher positioned individuals tend to live in some "ivory tower" within the same team/organization and as a result, they tend to detach themselves from the reality of software development and to lose that special touch with their team members.  Lack of respect, patience, trust and reality toward an individual or a team member is a sure road to failure in many organizations, mostly within a start-up where the strategic and corporate foundation isn’t as solid as a company like Google or Microsoft.  I really liked the following piece he wrote because I think it summarizes well his point throughout this article:

Slumming may have been almost fun for you as you daydreamed about your retirement on a yacht in St. Tropez or about how you would someday regale the grandkids with stories of your salad days. But that smart programmer you hired who built your website from the ground up? Don’t you think she knows about the free gourmet meals at Google? (NASDAQ:GOOG)

I can always tell the founders who haven’t figured this out yet, because they’re disappointed in all their employees, firing good people left and right and constantly asking, "Why hasn’t Joe (or Jane) gotten this work done yet? I could have finished it in one weekend!"

• "Writing Better Code — Keepin’ it Cohesive"
  Software developer Matthew Cochran wrote a really good tutorial about the object-oriented principle of "Single Responsibility Principle".  Instead of writing a theoretical article about it, he actually did a good job explaining the principle with a real-world example using refactoring.  He walks you through all the changes he brought to an initial design and he explains the reason he chose some strategy over another all the way to the end of what he calls a "good enough design": a piece of code that is easy to read, easy to understand, easy to change and easy to test.  The focus of the article is that a well-designed piece of code, i.e. higher cohesive classes, can later improve the maintenance of the design down the road.  Tons of articles have been written on the subject, but just a few of them really bring the problem to the table with a realistic and simple example like Matthew’s article does.  Speaking of the example, it’s nothing too fancy, just real stuff that .NET developers tend to write many times over…you just need to know a bit about .NET and the System.Data namespace to understand the example.

Blog Posts

• "The Best Unit Testing Resources: Beginner to Expert"
  Ben Orenstein published a good resource about unit testing, TDD, related tools and more in this post.  Check out the links he provides as it might give you a better perspective on the importance of unit testing your code.  Personally, I don’t care much whether you write the tests before or after the code.  I prefer to write them before as it helps me to understand what I’m trying to do instead of questioning myself on how I’m going to do it.  The only thing I do care is that the test is being well written and its intent is well exposed.
• "The Years of Experience Myth"
  Jeff Atwood shares his insight in the subject of technical recruiting.  Most companies nowadays are looking for such a precise, if not perfect, candidate that has X number of years with a specific technology or has intrinsic knowledge of some tool that they actually miss out on some very good opportunities to hire individuals that are more than capable of achieving even greater things if only we would look past their current experience and see exactly what they can achieve.  Human potential doesn’t rest on one’s past or current experiences but on the will of learning, achieving and improving more in many levels (personally and professionally).  I’m glad my current employer had that same kind of vision when he hired me…that’s the same vision I’ll carry one of these days when it’ll be my turn to invite someone to join my team/organization. As Jeff brilliantly wrote in his post:

Somehow, they’ve forgotten that what software developers do best is learn. Employers should be looking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language — and serving them up interesting projects they can engage with.

• "When TDD Goes Bad"
  Yup, again on the subject of TDD.  Gojko Adzic published a post on various practices to keep in mind when writing and maintaining unit tests,  His post was largely influenced by one of Ian Cooper’s presentation at a user group.  This is some good stuff especially if you’re looking for ways to improve your TDD techniques.
• "6 Reasons To Develop Your Tests First"
  I couldn’t let this one go so easily, even if it’s about TDD.  This article promotes TDD by reflecting on the core benefits of the practice which the author has summarized in a list of six items to remember or to get acquainted with when starting out with TDD.  Even if a lot has been written on the subject, there are still many organizations that have never heard of it and could, without a doubt, greatly benefit from adopting TDD within their software process.  Here are the 6 reasons to develop your tests first, according to the author:

1. Preventing imagination overrun
2. Know when you’re done
3. Catch regressions early
4. Create more modular code
5. Cleaner code
6. Satisfaction

I’ve been a fan of John C. Maxwell ever since reading his excellent book on leadership The 21 Irrefutable Laws of Leadership, so it was without hesitation that I decided to read one of his other books on leadership and human potential.  Regardless of being just 120 pages, "Dare To Dream…Then Do It: What Successful People Know And Do" is a personal treasure that will ignite you to maximize your potential by helping you realizing your dreams.  What kind of dreams are we talking about?  YOUR dreams.  Whether it is to be a successful pioneer in your field of work, a better leader in your family and organization, an achiever of what some people might characterize of "impossible victories", rediscover or reveal your inner self, contributing your talent, wisdom and life to a worthy cause, or anything else for that matter, this book is truly an eye-opener to one’s heart.

One reason that makes this book so good to read is that it is filled with words and stories from highly successful leaders, innovators and creative thinkers all throughout history.   Take for example the following immortal and inspiring words from such people which you can cherish in this book:

• "Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to rank with those poor spirits who neither enjoy much nor suffer much, because they live in the gray twilight that knows neither victory nor defeat" – U.S. President Theodore Roosevelt
• "Keep your eyes on the stars, but remember to keep your feet on the ground" – U.S. President Theodore Roosevelt
• "Don’t let someone else create your world, for when they do they will create it too small" – Edwin Louis Cole, founder of Christian Men’s Network.
• "Never measure the height of a mountain until you have reached the top.  Then you will see how low it was" – Dag Hammarskjold, Swedish diplomat
• "Whatever things are true, whatever things are noble, whatever things are just, whatever things are pure, whatever things are lovely, whatever things are of good report, if there is any virtue and if there is anything praiseworthy — meditate on these things" – Apostle Paul writing to the Philippians (Philippians 4:8)
• "Early in life, I decided that I would not be overcome by events.   My philosophy has been that regardless of the circumstances, I shall not be vanquished, but will try to be happy.  Life is not easy for any of us.  But it is a continual challenge, and it is up to us to be cheerful — and to be strong, so that those who depend on us may draw strength from our example." – Rose Kennedy
• "Thought is the original source of all wealth, all success, all material gain, all great discoveries and inventions, and all achievement." – Claude M. Bristol, U.S. author
• "If you have built castles in the air, your work need not be lost; there is where they should be.  Now put foundations under them." – Henry David Thoreau, essayist
• "The time is always right to do what is right" – Martin Luther King, Jr., civil rights leader
• "At the Day of Judgment, we shall not be asked what we have read, but what we have done." – Thomas Kempis, German monk"
• "The most important single ingredient in the formula for success is knowing how to get along with people." – U.S. President Theodore Roosevelt
• "Treat a man as he appears to be and you make him worse.  But treat a man as if he already were what he potentially could be, and you make him what he should be." – Johann Wolfgang Von Goethe, German poet
• "If a man has talent and cannot use it, he has failed.  If he has a talent and uses only half of it, he has partly failed.  If he has talent and learns somehow to use the whole of it, he has gloriously succeeded, and won a satisfaction and a triumph few men will ever know." – Thomas Wolfe, U.S. novelist
• "Every man must at last accept himself for his portion, and learn to do his work with the tools and talents with which he has been endowed.  That some are more richly endowed that others should cause no concern, for in the final analysis it may appear that the mighty oak is of less importance than the tiny violet which blooms in humble obscurity at its feet." – Charles A. Hawley
• "Great works are performed, not by strength, but by perseverance.  He that shall walk, with vigor, three hours a day, will pass, in seven years, a space equal to the circumference of the globe." – Charles Johnson
• "So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable" – Christopher Reeve, actor

As for the stories, I learned so many things which I had no idea were actual inspiring acts.  For instance, I didn’t know that:

• Andres Segovia revolutionized the music industry by pursuing his dream about perfecting the art of playing the classical guitar and establishing that musical instrument as a key tool in the concert hall.  As John Maxwell justly writes about Segovia’s work, "When people discover their dreams and commit to them, there’s no telling what kind of impact they will make."
• Arnold Palmer, one of the greatest golfers of all times and a man which was named Sports Illustrated’s Sportsman of the Year in 1960 and Athlete of the Decade by an Associated Press poll, screwed up a "par five ninth hole" in a 1961 tournament.  And because of that single result, a bronze plaque was made and hung on that same golf course which states that Arnold Palmer, which was voted as the best sportsman the year before, took a 12 on that hole.  He really screwed up that shot.  Nevertheless, that didn’t stop Arnold Palmer to continue his passion for the game and winning more golf tournaments.
• In their first professional baseball debut, two NBL rookies were playing against each other that day.  Jim Greengrass who was playing for the Cincinnati Reds helped his team win with a score of 9-8 by hitting four doubles.  In the other hand, Hank Aaron, who was playing for the Milwaukee Braves, went 0 for 5.  I don’t know much about baseball, and I certainly don’t know who Jim Greengrass is,  but I have heard a lot about Hank Aaron and what he has accomplished simply because he didn’t let failure win over his dreams and achievements.  So next time you’re banging your head on the desk because your software design shows too much coupling between classes and its complexity is too high to make any significant change on the spot, don’t let it stop you from trying harder and imagining further solutions to your problem.

In essence, the spirit of the book can be summarized with these words by the author:

Successful people know and do things differently than unsuccessful people.  That is a fact.  If you have experienced a measure of success, you know this to be true.  It starts with the way you think and dream, and it continues with how you live.

Most revolutions throughout human history started out with a dream.  What kind of revolution do you want to live your life for?  I know some people who dream dreams, but then summarize their lives as a nightmare and a sad reality because they simply didn’t take that extra step to "instantiate" (hey, this is a blog about software development anyways, right?) that dream.

So, whether you’re a software developer, scholar, consultant or manager, what can the ideas from this book bring to you and your team?  For starters, if you’re a software development manager, the principles of this book will whisper in your heart that you should foremost trust your team and help your team members to grow both at a personal level and at a professional level, so that they can become who (not what, for the who defines the what in life) they’re really meant to be.  You want another challenge?  Help them to become better than yourself at what you’re doing, and if possible help them to achieve greater things that you have achieved in your life and career.  At the end, you will benefit more from it.  If you’re a software developer, a consultant or a student of the field, don’t be shy to step out of your comfort zone and share what you know (your experience) with others.  Offer to give a talk or a presentation at your next user group’s meeting.  Don’t be reluctant to write something you have in mind if it can help a couple of people (blogs are so easy to start nowadays).  Don’t regret writing that piece of software that could greatly contribute to the field or, even better, to the rest of the world.  Don’t be afraid to learn new things and to embrace failure while trying new stuff…as long as you’re willing to learn from it.  As stated by the author,

People will never be what they ought to be until they are doing what they ought to be doing.

There are so many other inspiring stories throughout this book that I’m voluntarily omitting from writing in this post, because I rather wish you read them on your own.  What you have read so far in this post is not even half of the rich content that John Maxwell has wrote in this book.  In closing words, I’ll mention it again: never stop dreaming big in life.  I love writing software and working with people with different skills, but whether I stay in this field all my life or not, one thing is for sure, I’ll never stop dreaming.

Think about your dreams.  Does it inspire you to work hard?  Does it motivate to take smart risks?  Does it build you up?  Will it benefit others around you?  As you move closer to fulfilling it, will it bring you closer to who you were born to be?  Those are all hallmarks of a healthy daring dream!

This is my second technical review for a book belonging to the "Head First" series from O’Reilly.  After reading and reviewing the excellent "Head First Design Patterns", it was hard not to push further my curiosity to read another Head First book.  I must say that since writing the review for "Head First Design Patterns", a friendly editor from O’Reilly offered me the opportunity to read and review any book I desire from the publisher, which I have accepted since reading about the field is one of my principles about becoming a key professional software developer.  That being said, I also need to point out that my reviews on any O’Reilly book will be purely objective, therefore I will write about my thoughts on the book, as well as what I liked and disliked about it, independently of my status as a reviewer for the publisher. All right, here we go…

Written by professional software developers Dan Pilone and Russ Miles, "Head First Software Development" brings the most important ideas and principles on software engineering today.  Instead of just dealing with one phase of the software development lifecycle (SDLC), it actually covers ALL the phases of the SDLC from gathering requirements, planning the different steps in a project, and dealing with user stories, to knowing how to manage your software process with continuous integration and test-driven development with mock objects.  The best part of it all is that it is written with the same unique, intelligent and sublime style of any other Head First book.

I was remembering my years as a software engineering undergrad, and all those classes that we had to attend weekly, while reading this book one night.  In fact, I realized that this book presents all the most important practices and principles a professional software engineer should be acquainted with in order to design, develop and deliver successful and higher quality software today.  Even though the book targets Java as the programming language for its examples, JUnit for its unit tests scenarios, Ant as its build engine tool, CruiseControl as its continuous integration server, you will find no problem at all to follow and understand the main ideas shared in this  book.  As an example, I’m more of a .NET developer that rather prefers to use other tools like NUnit, TypeMock, MSBuild and TeamCity instead.  In other words, it’s not the tool that makes the difference in your work, but rather the knowledge you have of the tool.  And since knowledge is universal, you will be very comfortable in following the main ideas behind each chapter even if you haven’t programmed with Java. 

Without stating it explicitly, Head First Software Development uses various key ideas from Scrum and XP, such as daily standup meetings, planning an iteration by playing planning poker, calculating and using a team’s velocity to better manage a project’s estimates, writing customer-focused user stories to gather requirements and manage requirements priorities, using a burn-down chart to view a project’s status within each iteration, driving the coding activity by writing tests first and applying refactoring, encourage and improve team communication with continuous integration, as well as customer communication by keeping her informed of the project’s "health status".  In a few words, the book can be summarized as a simple collection of various activities, ideas, guidance and principles to deliver software on time, on budget and on track with what the customer asked for.

Like all the other Head First series, this book also contains the popular "There are no dumb questions" sections which provide helpful answers and tips to various questions most customers and software developers ask or have being asked.  One such question/answer that forced me to get up from my seat and get a yellow highlighter was this one:

Question: What is you don’t have a next iteration? What if you’re already on the last iteration, and then a top priority feature comes in from the customer?

Answer: If a crucial feature comes in late to your project and you can’t fit it into the last iteration, then the first thing to do is explain to the customer why the feature won’t fit.  Be honest and show them you iteration plan and explain why, with the resources you have, the work threatens your ability to deliver what they need by the due date.

I was amazed by this answer, because I remembered a student once asking a similar question to a teacher at university and he couldn’t give the student a straight simple answer, but then again maybe because the professor was lacking real-world experience.  Anyhow, the answer given by the authors truly demonstrates that communication isn’t just a link between developers alone but that in fact that link must also include customer(s).  It’s their project(s) after all!  Now this is just one example of a Q&A you will find in this book…and there are a lot of them!

Another positive outcome of reading this book is that you don’t have to read all the continuous integration, test-driven development and user stories books available in the market to get up and going with these practices.  In fact, Head First Software Development successfully presents a good and thorough overview of all these practices for you to be able to understand the concepts and principles behind them, but most importantly, to be able to apply them within your own organization.  Then if you want to go more in depth about a particular practice, you can go ahead with a more specific book on the subject and not be lost in your reading.

I highly recommend this book to be part of a software engineering curriculum at both the undergraduate and graduate level.  I also think that this book will be a great plus for software development managers who want to improve their software development process by using sound, concrete, and realistic practices within their own organization.  Software consultants will no doubt also greatly benefit from this book, especially if they need to implement or recommend a proper solution in regards to a client’s software development process.  Being a software development trainer myself, I was very grateful to have had the opportunity to read Head First Software Development for the simple reason that I got to learn more than a few things in which I haven’t had much knowledge in.  Now, I can hardly wait to share what I’ve learned from this book with my students in the classroom!

The following is the Table of Contents for this book:

1. Great software development: Pleasing your customer
2. Gathering requirements: Knowing what the customer wants
3. Project planning: Planning for success
4. User stories and tasks: Getting to the real work
5. Good-enough design: Getting it done with great design
6. Version control: Defensive development
7. Building your code: Insert a tab into slot b…
8. Testing and continuous integration: Things fall apart
9. Test-driven development: Holding your code accountable
10. Ending an iteration: It’s all coming together…
11. The next iteration: If it ain’t broke…you still better fix it
12. Bugs: Squashing bugs like a pro
13. The real world: Having a process in life

My wife has a lot of family members living in the country in New Brunswick, Canada.  One of them sent her this funny illustration of what they seem to understand every time I go down there and tell them about my job with technology.

This is the fourth post for "This Week’s Geek Links"…aka my fourth-year-wedding-anniversary-week too!

Like last time, I’ll start this post by recommending some exceptional and inspiring videos that will challenge you as a professional, but more importantly as a human being.  I hope you’ll enjoy them!

Highly recommended to watch this week

• "Life Without Limbs – Nick Vujicic"
  A powerful testimony of what life is all about.  More information about Nick Vujicic can be found at www.lifewithoutlimbs.org.
  
  

Blog Posts

• "The Programmer Dress Code" (also checkout part two)
  I had a blast looking at the pictures of various famous programmers and seeing a pattern unfold before my eyes.  One of my new favourite bloggers, Justin Etheredge, shows a list of various pioneers in the software development world in a very funny way: from Dijkstra to Booch, these guys seem to belong in the same club where the rule is that you must have a beard, look sloppy or have very long hair.  And I thought we were just dealing with 1’s and 0’s…  By the way, don’t forget part two where the list continues.  After all, it’s not a bad way to learn a bit more about the history of computer science.  Great stuff!
• "The programmer who programs least, programs best"
  A simple post with an effective message.  This time around, Justin Etheredge writes about a very natural technique to avoid spreading bugs into our code: write less code!  Today, programming languages and compilers offer higher level constructs that we can use in less code, but for some reason (maybe due to the lack of knowledge for a given platform) I still see developers reinventing the wheel and adding much more code to do the same job instead of using what’s already in their toolbox.  Writing less code to do the same job is one factor that differentiates good programmers from professional programmers.  Less code to write means less impact on maintenance, more isolated unit testing and higher test coverage, better readability and less refactoring to do.  Highly recommended reading material for this week!
• "Becoming a Better Developer"
  In this 11-part post, Rob Walling writes about what he thinks it takes to become better in your job as a software professional.  He doesn’t go into specific details such as knowing this programming language or that new platform.  Instead, he brings the basics up front, such as being good and doing good to your co-workers, realizing that there is more to life than code, not being afraid to try new job roles (just to see if you’re missing out on something in your career), etc.  Each of the 11 parts aren’t too long to read and the main ideas are easy to grasp.  Here are the parts, as listed on his website:
  
  • Part 1: Making Fans
  • Part 2: Know Your Core Competencies
  • Part 3: Enjoy the Panorama
  • Part 4: Know What You’re Building
  • Part 5: Don’t Use a Dull Knife
  • Part 6: Become a Manager
  • Part 7: The Jigsaw Puzzle
  • Part 8: Know Your Archetype
  • Part 9: How to Criticize a Software Developer Without Getting Punched
  • Part 10: What Do Your Colleagues Think of You?
  • Part 11: Get a Massage (and Get Your Boss to Pay For It)

When Visual Studio updates its MSDN documentation to "reflect your recent changes", it throws a dialog box right in your face asking you to wait (or waste) several minutes.  Now I must say that there are some things in life that I accept without much stress, difficulty, and impatience; such as forgetting my wallet at home when it’s my turn to pay the cashier for my full basket of groceries and there are six other people waiting in line behind me because it’s rush hour, or when I’m accidentally inhaling the nasty cigarette smoke from the guy in front of me in the waiting line for the 105 city bus, or when I’m filling an online registration box for the 1000th time.  I can live with that.  On the other hand, something I can NOT stand is when an application shoves a dialog box IN MY FACE…and that dialog box is modal and buttonless! That’s what happened to me this afternoon. While waiting for Visual Studio to finish up digesting the changes to its own MSDN documentation, I realized that I was wasting 10 minutes of my life for this thing to finish.  

So there I am sitting, waiting and wasting 10 minutes of my life looking at that stupid green progress bar.  Suddenly, my mind is thinking out loud "Hmm…I wonder what occurred in the world during those 10 minutes…".  After doing some "research" on the web, this is what I found what happened in our planet while waiting for that annoying dialog box to disappear:

• The tropical forests lost 1500 acres of life due to human harm
• 1070 people died (various causes)
• 100 children died due to malnutrition
• 7 people died in a car accident
• 2550 babies were born
• 2 person learned how to program with Ruby
• 8 people committed suicide
• 10 people were murdered
• 50 people died because they had contracted AIDS
• 14 people died due to cancer
• 150 people said "Doh!" (I’m one of them)
• 3 couple divorced
• 2 couple married
• A lion killed a zebra to feed her cubs
• 4 people changed careers
• 2,835,281 people got spammed
• 2,000 people said "I love you" to their partners…only half of them replied back with an "I love you"
• 30 people wasted 10 minutes of their lives on YouTube
• 300 people wasted 10 minutes of their lives on FaceBook (I’m one of them)
• 2 developers managed to integrate their projects under Cruise Control
• 4 developers managed to integrate their projects under Team City (Go, JetBrains!)
• 1 person understood the concept of closures
• 2 people were wondering what is more efficient: C# or VB.NET?
• 20 developers were still coding with .NET 1.1
• 2 people subscribed to Jeff Atwood’s feed
• Britney Spears surely did something stupid (correction: I didn’t need to research this for a fact…)

What else happened in the world while I was waiting for that useless dialog box to disappear?

NOTE TO MICROSOFT: Stop wasting my time with useless "features" like this one.  Whoever wrote the user story for this one should get fired.  Give me an "Ignore" button so I can continue working while Visual Studio is updating whatever needs to be updated.  No wonder I have an ulcer…

For the past few months, I have been using Windows Live Writer, a desktop blog publishing application, to write and publish my posts. This free utility encouraged me to abandon the awful WYSIWYG text editor of WordPress for writing my posts. Don’t get me wrong, I love WordPress as a blogging platform, but its HTML text editor sucks!

Windows Live Writer allows me to freely manage a post without being dependent on the browser. This means that I don’t need to be connected on the Internet to start writing a post. You can think of it as being a blog client to your blogging platform (WordPress, Blogger.com, etc.), the same way that Microsoft Outlook is an email client to various email providers (Gmail, Hotmail, Yahoo Mail, etc.). In other words…"Write As You Go!".

With Windows Live Writer, you can automatically save a post locally, come back to it later, check for grammar errors before publishing it, publish the post as a draft, edit a post, manage multiple blog accounts, add and remove plugins to facilitate some tasks, write your own plugins for it, etc. Talk about flexibility!

As stated by Wikipedia,

Windows Live Writer introduces the Provider Customization API that enables both rich customization of Windows Live Writer’s behavior as well as the opportunity to add new functionality to the product. Currently Windows Live Spaces, WordPress, and TypePad have all taken advantage of this API to expose additional service-specific features within Windows Live Writer.

Currently, Windows Live Writer is compatible with the following blogging platforms:

• Windows Live Spaces
• Blogger
• LiveJournal
• TypePad
• Wordpress
• All blogs that support RSD (Really Simple Discoverability)
• MetaWeblog API
• Moveable Type
• Community Server

Written in managed code, you can also use a tool like Reflector to view the internals of the application. This is incredible useful if you’re planning on developing plugins for it. On the subject of plugins, I am very impressed with the following ones:

• Blog This for Firefox
• Paste from Console
• Amazon Book Lookup Plugin
• Paste from Visual Studio

Click here to see the whole list of currently available plugins.

There are of course some improvements and new features that could be implemented to make it better.

1. For instance, whenever I insert a new table, I get to define its width in pixels only, NOT in percentage. What’s up with that? Is it a new ‘best practice’ to define a HTML Table’s width in pixels only?
2. Another improvement could be to add an image toolbar so that we can edit the image on the fly (cropping it, adding shapes to it, etc.) whenever we insert one, pretty much like the Picture Tools ribbon in Office 2007. Resizing is fine, but not enough. For the moment, I have to copy an image to the clipboard, paste it in Paint.NET, edit it, then copy it again to the clipboard and finally paste it in Windows Live Writer. I should be able to do this from within the application, the same way any word processor software allows me to do.
3. A last improvement could be to give me the possibility to choose the browser I’d like to view my posts in. Just because Internet Explorer is set as my default browser, that doesn’t make it my primary browser!

You can read more about it in the team’s blog.

Firefox has a built-in feature that allows you to recover any previous session in case it should crash.  Internet Explorer doesn’t.  Why not?  I hate it when Internet Explorer hangs for some unknown reason and stupidly loses my current session including all the tabs I had previously open.  Instead of restarting itself with my previous session, it just sits there asking me if I would like to send a report to Microsoft informing them about this problem.  No wonder I have an ulcer!

Anyhow, as I was looking around for a way to restore my previous session in IE, I suddenly felt calmer.  Why?  Because of IEHistoryView, that’s why!  This is a free tool that lists all the URLs I have visited with Internet Explorer.  The data source for the list is the history index file which is automatically populated by IE each time that you type a URL in the address bar or click on a link inside the browser.  Check out the following screenshot for a peek of IEHistoryView in action.

The company behind this wonderful tool is NirSoft.  As stated in the company’s website:

This utility reads all information from the history file on your computer, and displays the list of all URLs that you have visited in the last few days. It also allows you to select one or more URL addresses, and then remove them from the history file or save them into text, HTML or XML file. In addition, you are allowed to view the visited URL list of other user profiles on your computer, and even access the visited URL list on a remote computer, as long as you have permission to access the history folder.

These guys also have some pretty interesting tools to offer, which I’ll definitively blog about…suddenly I have found my love for computers once again.  Now it’s my turn to fire back at IE…

This is the third post for "This Week’s Geek Links".

Like last time, I’ll start this post by recommending some exceptional and inspiring videos that will challenge you as a professional, but more importantly as a human being.  I hope you’ll enjoy them!

Highly recommended to watch this week

• "The Pleasure Of Finding Things Out".
  Filmed in 1981, this interview by the BBC with the late Richard Feynman will delight and inspire anyone who would like to share something of the joys of scientific discovery. Feynman is a master storyteller, and his tales — about childhood, Los Alamos, or how he won a Nobel Prize — are a vivid and entertaining insight into the mind of a great scientist at work and play. I was curious about this character while listening to an audio version of his extraordinary book "Surely You’re Joking, Mr. Feynman!".
• "The Boy With The Incredible Brain".
  This is the breathtaking story of Daniel Tammet. A twenty-something with extraordinary mental abilities, Daniel is one of the world’s few  … all » savants. He can do calculations to 100 decimal places in his head, and learn a language in a week. This documentary follows Daniel as he travels to America to meet the scientists who are convinced he may hold the key to unlocking similar abilities in everyone. He also meets the world’s most famous savant, the man who inspired Dustin Hoffman’s character in the Oscar winning film ‘Rain Man’.

Blog Posts

• "‘Commit’ like your life depends on it"
  Russ Miles, co-author of Head First Software Development, writes about the importance of updating your code base from the source repository before committing your changes.  The "Works On My Machine" syndrome doesn’t work when working in a team.  So if your current repository doesn’t oblige you to update before committing, this article will explain you the why and the how of doing this.  Be sure to read the comments too!
• "Software Consultants Care Too (well, great ones do)"
  In this other post, Russ Miles shares his vision of what is a great consultant and how he differentiates himself from the good consultant.  I really like the following line he wrote: "That’s the real difference.  A good consultant does the job, a great one delivers above and beyond."  I’m currently a consultant and I strongly believe in Russ’s principles: a consultant should care about his work, his professionalism and his client.  A consultant should help his client beyond what the client requested of him in some circumstances.  Great post!
• "At the heart of great software are great people"
  And yet another post from blogger and author Russ Miles.  So far, I’m liking his writings because even though what he’s writing about has been written many times already by other people, it needs to remain constantly on the surface for the newcomers to see.  This principle is about knowing and accepting the fact that people are behind the creation of software.  Not tools, not processes, not technologies.  People.  As he says: "All the techniques we concentrate consider the people involved, because without people you just don’t have any software being written".  Another good post!

Articles

• "Melinda Gates goes public"
  We haven’t seen nor heard much about Bill Gates’ wife in the public eye as of late.  In this article, Fortune Magazine interviews Melinda French Gates, one half of the The Bill & Melinda Gates Foundation, a world-wide philanthropic organization.  She’s stepping up the public eye for a good two good reasons: to publicly declare war on the world’s deadliest human diseases and to serve as a role model for her children.

Screencasts/Webcasts

• "Examining Why Agile Software Development Works"
  One of my software engineering heroes, Scott Ambler won a Rock Star award for his talk on choosing the right processes over choosing the right technologies.  He also discuses on Scrum, agile change management, database refactoring, database testing, Agile Model Driven Development and agile documentation strategies.  You must register for a free account the Sun Developer Network, but it is worth it!  On a lost note, his talk is geared towards Java technologies, but his principles still apply in .NET!
• "Designing .NET Class Libraries"
  This is by far the best video on sound API design principles with .NET.  Here, Krzysztof Cwalina, PM in the .NET Framework Team at Microsoft Corp., presents best practices for designing frameworks that are reusable object-oriented libraries.  The guidelines are applicable to frameworks ranging in size and in their scale of reuse from large system frameworks to small components shared among several applications. They started as a small set of naming and design conventions, but have been enhanced, scrutinized, and refined to a point where they are generally considered the canonical way to design frameworks at Microsoft. They carry the experience and cumulative wisdom of thousands of developer hours, over three versions of the .NET Framework.  NOTE: This video is almost four hours long!  I actually saw it in a span of three days.  I recommend watching this video during lunch with your team…nobody will be disappointed.  You can also download the whole presentation here (460 Mb).

Have you ever wonder how some intrinsic mechanisms of the C# language actually work, i.e, generics, iterators and delegates?

What about the different syntax and constraints of the C# language?

Do you want to know more about the CLI, the CTS and the CLS, and how they participate in the .NET Framework, than just being satisfied with what their acronyms stand for?

Did you know that you can learn more about the C# programming language and the Common Language Infrastructure for free?

As a matter of fact, both the C# programming language and the Common Language Infrastructure are ECMA standards which are publicly available for anyone to download free of charge. ECMA, which stands for European Computer Manufacturers Association, is an international, private standards organization for the Information and Communication Technology and the Consumer Electronics. As stated in their website,

The aims of ECMA are:

• To develop, in co-operation with the appropriate National, European and International organizations Standards and Technical Reports in order to facilitate and standardize the use of Information Communication Technology (ICT) and Consumer Electronics (CE).
• To encourage the correct use of Standards by influencing the environment in which they are applied.
• To publish these Standards and Technical Reports in electronic and printed form; the publications can be freely copied by all interested parties without restrictions.

The C# Language Specification standard (ECMA-334) is currently in its 4th edition, and "specifies the form and establishes the interpretation of programs written in the C# programming language". It emphasizes on:

• The representation of C# programs;
• The syntax and constraints of the C# language;
• The semantic rules for interpreting C# programs;
• The restrictions and limits imposed by a conforming implementation of C#.

Click here to download the C# Language Specification standard as a PDF (553 pages, 2.6MB)

The Common Language Infrastructure standard (ECMA-335) is also in its 4th edition. It consists of the following parts:

• Partition I: Concepts and Architecture – Describes the overall architecture of the CLI, and provides the normative description of the Common Type System (CTS), the Virtual Execution System (VES), and the Common Language Specification (CLS). It also provides an informative description of the metadata.
• Partition II: Metadata Definition and Semantics – Provides the normative description of the metadata: its physical layout (as a file format), its logical contents (as a set of tables and their relationships), and its semantics (as seen from a hypothetical assembler, ilasm).
• Partition III: CIL Instruction Set – Describes the Common Intermediate Language (CIL) instruction set.
• Partition IV: Profiles and Libraries – Provides an overview of the CLI Libraries, and a specification of their factoring into Profiles and Libraries. A companion file, CLILibrary.xml, considered to be part of this Partition, but distributed in XML format, provides details of each class, value type, and interface in the CLI Libraries.
• Partition V: Debug Interchange Format.
• Partition VI: Annexes – Contains some sample programs written in CIL Assembly Language (ILAsm), information about a particular implementation of an assembler, a machine-readable description of the CIL instruction set which can be used to derive parts of the grammar used by this assembler as well as other tools that manipulate CIL, a set of guidelines used in the design of the libraries of Partition IV , and portability considerations.

Click here to download the CLI standard as a PDF (556 pages, 3.2MB)

Other noteworthy standards that might be of interest are:

• The C++/CLI Language Specification (ECMA-372). This Standard specifies requirements for implementations of the C++/CLI binding. The first such requirement is that they implement the binding, and so this Standard also defines C++/CLI. Other requirements and relaxations of the first requirement appear at various places within this Standard. Click here to download the C++/CLI Language Specification as a PDF (304 pages, 1.57MB)
• The Eiffel Programming Language (ECMA-367). This document provides the full reference for the Eiffel language. This Standard covers only the language, with an emphasis on the implementation aspects. Click here to download the Eiffel Programming Language standard as a PDF (194 pages, 3.4MB)
• The Microsoft Office Open XML File Formats (ECMA-376). This Standard defines Office Open XML’s vocabularies and document representation and packaging. It also specifies requirements for consumers and producers of Office Open XML. The standard is available as a 5-part series and there’s also an Office Open XML overview document available on the ECMA website.

For a more detailed list of the available standards published by ECMA, check out the ECMA Standards List section.

Next time you have a job interview, a research project or a commercial project to deliver and you need to know more about the C# language and the CLI, save yourself the money and download the standards free of charge.

Does your code compiles successfully? Good. How about your application’s performance? Could it use some improvement? Did you take some time in answering these questions before releasing it to the Quality Control team or to a potential customer?

You must’ve heard and read about it many times over since the .NET framework was shipped in early 2002. Unfortunately, I still see some .NET developers using the String class as a concatenation harlot in some contexts where using a StringBuilder would be a better match instead.

This post is about knowing when and why you should use the StringBuilder’s appending function in some cases and the String’s concatenation function in others. I’ll be using Red Gate’s ANTS Profiler to profile a simple C# console application to see exactly how much execution time was spent in each string concatenation method for both the String class and the StringBuilder class.

The StringBuilder Class

Before going further into the discussion, I think it is worthwhile to define the purposes of each class. Let us start with the StringBuilder class.

According to the .NET Framework API MSDN documentation, the StringBuilder class represents a mutable string of characters. In order not to reinvent the wheel, let us see what the remarks are about this class ^[1]:

This class represents a string-like object whose value is a mutable sequence of characters. The value is said to be mutable because it can be modified once it has been created by appending, removing, replacing, or inserting characters.

Most of the methods that modify an instance of this class return a reference to that same instance. Since a reference to the instance is returned, you can call a method or property on the reference. This can be convenient if you want to write a single statement that chains successive operations one after another.

A StringBuilder object maintains a buffer to accommodate the concatenation of new data. New data is appended to the end of the buffer if room is available; otherwise, a new, larger buffer is allocated, data from the original buffer is copied to the new buffer, then the new data is appended to the new buffer.

The String Class

As for the String class, the MSDN documentation has these remarks to say about it ^[2]:

A string is a sequential collection of Unicode characters that is used to represent text. A String object is a sequential collection of System..::.Char objects that represent a string. The value of the String object is the content of the sequential collection, and that value is immutable.

A String object is called immutable (read-only) because its value cannot be modified once it has been created. Methods that appear to modify a String object actually return a new String object that contains the modification.

Performance Analysis

As stated in the beginning of this post, I am using a very simple application to note the performance differences between the StringBuilder class and the String class when performing multiple concatenations. The application exercises both these classes in two ways.

Concerning the String class, I am performing the following code with a different number of concatenations defined by XX:

    private static void ConcatenateString_XX_Times()
    {
      string s = string.Empty;

      for (int i = 0; i < XX; i++)
      {
        s += "test";
      }
    }

Concerning the StringBuilder class, I am performing the following code with a different number of concatenations defined by XX:

    private static void ConcatenateStringBuilder_XX_Times()
    {
      StringBuilder sb = new StringBuilder();

      for (int i = 0; i < XX; i++)
      {
        sb.Append("test");
      }
    }

NOTE: In both cases, XX defines a number with the following values: 1 to 20 inclusively, 100, 1000, 10 000 and 100 000.

The following figure shows a summary generated by ANTS Profiler which represents the execution time (in seconds) each method took to perform on a Dell Inspiron 9300 (1.86 GHz Pentium M CPU with 2GB ram).

Figure 1. A summary of the execution time it took to run each method

Here's the same representation shown in Table 1 (for the String class) and Table 2 (for the StringBuilder class). I have omitted showing the results for the first 20 concatenations because both the String and StringBuilder seem to have taken approximately the same time to perform their corresponding methods (compare lines 11-30 for the String class and lines 35-54 for the StringBuilder class).

Table 1. Summary of the time taken to run each concatenation method for the String class for 100, 1000, 10 000 and 100 000 string concatenations

Table 2. Summary of the time taken to run each concatenation method for the StringBuilder class for 100, 1000, 10 000 and 100 000 string concatenations

Table 3. Proportional differences between the String and StringBuilder classes for 100, 1000, 10 000 and 100 000 concatenations

We can interpret the above table as follows:

• In the first round, the StringBuilder and the String classes are pretty well the same when concatenating 100 strings in a for loop.
• In the second round, we are multiplying the previous number of concatenations by 10 (100 x 10 = 1000). As we can see, the StringBuilder is taking approximately 10 (0.0029/0.0003 = 9.66, which we'll round to 10 for simplifying our reasoning) times as much time than the first round to concatenate 1000 strings (following a direct proportional line right? In fact, 10 times more strings to concatenate => approximately 10 times more time to complete, therefore a 1:1 ratio) In contrast, the String class is taking 36.25 (0.0145/0.004 = 36.25) times as much time than the first round to concatenate 1000 strings. Therefore, we can say that for 1000 string concatenations, the StringBuilder is 362.5% faster than the String class! Let us continue...
• In the third round, we are again multiplying the previous number of concatenations by 10 (1000 x 10 = 10 000). As we can see, the StringBuilder is taking (again) approximately 10 (0.0295/0.0029 = 10.1724, which we'll round to 10 again for simplifying our reasoning) times as much time than the previous round to concatenate 10 000 strings (the ratio 1:1 still applies!) In contrast, the String class is taking 54.14 (0.784/0.0145 = 54.14 approximately) times as much time than the previous round to concatenate 10 000 strings. Therefore, we can say that for 10 000 string concatenations, the StringBuilder is 541.4% faster than the String class! Let us continue...
• In our last round, we are yet again multiplying the previous number of concatenations by 10 (10 000 x 10 = 100 000). As we can see, the StringBuilder is taking (AGAIN!) approximately 10 (0.297/0.0295 = 10.0678) times as much time than the previous round to concatenate 100 000 strings (the ratio 1:1 still applies!) In contrast, the String class is taking 240.76 (189/0.785 = 240.76 approximately) times as much time than the previous round to concatenate 100 000 strings. Therefore, we can say that for 100 000 string concatenations, the StringBuilder is 2407.6% faster than the String class! Ok, that's enough for now.

In computer science, we use the Big-O notation to evaluate an algorithm's performance. For instance, we'd say that up to 100 000 string concatenations (because that's how far we've gone with our tests), the StringBuilder's Append method gives us O(n) or linear performance. On the other hand, due to the immutable nature of the String class, everytime we concatenate a string to it in a loop, we end up with roughly O(n²) or quadratic performance, which in itself is a performance disaster compared to O(n). This observation is only valid for our context. We should try the same test with more than a million string concatenations to see if our observation still fits.

In order to respect the DRY principle, I'm not going to show the IL code generated when using a StringBuilder's Append method or a String's Concat method because you can find such information on several posts (see the Reference section at the end of this post) alread, but I do recommend to take some time to view the internals when invoking both of these methods using a tool like ILDASM or Reflector.

Discussion and conclusion

Some people that wrote a post on the same subject recommend to use the StringBuilder class over the String class if you are concatenating a predetermined number of strings. For instance, Mahesh Chand recommends to use the StringBuilder if you have to concatenate a string more than 10 times and he supports his recommendation with a pretty simple and realistic demo. In his excellent article on the same subject, Jouni Heikniemi concludes that there's a "magic number" that helps deciding when to use the StringBuilder's concatenation over the String's, and that number is between four and eight concatenations. Finally, in his thorough and very well detailed article on the same subject, David Cumps concludes with the following:

• If you can avoid concatenating, do it!This is a no brainer, if you don't have to concatenate but want your source code to look nice, use the first method. It will get optimized as if it was a single string.
• Don't use += concatenating ever.Too much changes are taking place behind the scene, which aren't obvious from my code in the first place. I advise to rather use String.Concat() explicitly with any overload (2 strings, 3 strings, string array). This will clearly show what your code does without any surprises, while allowing yourself to keep a check on the efficiency.
• Try to estimate the target size of a StringBuilder.The more accurate you can estimate the needed size, the less temporary strings the StringBuilder will have to create to increase its internal buffer.
• Do not use any Format() methods when performance is an issue.Too much overhead is involved in parsing the format, when you could construct an array out of pieces when all you are using are {x} replaces. Format() is good for readability, but one of the things to go when you are squeezing all possible performance out of your application.

Though I firmly agree with the previous recommendations, I think that we should also consider what the MSDN documentation has to say about the performance and memory allocation of both classes:

The performance of a concatenation operation for a String or StringBuilder object depends on how often a memory allocation occurs. A String concatenation operation always allocates memory, whereas a StringBuilder concatenation operation only allocates memory if the StringBuilder object buffer is too small to accommodate the new data. Consequently, the String class is preferable for a concatenation operation if a fixed number of String objects are concatenated.

In that case, the individual concatenation operations might even be combined into a single operation by the compiler. A StringBuilder object is preferable for a concatenation operation if an arbitrary number of strings are concatenated; for example, if a loop concatenates a random number of strings of user input. ^[1]

If it is necessary to modify the actual contents of a string-like object, use the System.Text..::.StringBuilder class. ^[2]

My conclusion is that you shouldn't use the String class to concatenate multiple strings just to properly align and format your code (the visual aspect of the code). Even if you're concatenating 8, 9 or 10 strings inside a method, prefer the StringBuilder's Append method, especially if that method will be invoked repetitively.

I also believe that using tools like Red Gate ANTS Profiler, JetBrains dotTrace Profiler and the Microsoft .NET CLR Profiler to analyze your application's performance, and memory allocation will help you further in improving your design and implementation code, as well as pinpointing those bottlenecks in your application.

Sometimes a successful compilation just isn't enough.

References

1. "StringBuilder Class", MSDN Documentation, Microsoft Corp.
2. "String Class", MSDN Documentation, Microsoft Corp.
3. "StringBuilder and String Concatenation" by Mahesh Chand (2002)
4. ".NET String vs. StringBuilder - Concatenation Performance" by Jouni Heikniemi (2004)
5. "String Concatenation vs Memory Allocation" by David Cumps (2007)
6. "Immutable types: understand their benefits and use them" by Patrick Smacchia (2008)
7. "Everything Is Fast For Small n" by Jeff Atwood (2007)
8. "Big-O Notation", Wikipedia

This is the second post on "This Week’s Geek Links".

I’ll start out by recommending you to watch these two videos which have nothing to do with software development, but everything to do with courage, humility and living. The normal structure of this post follow the links to these videos.

Highly recommended to watch this week

• "How To Achieve Your Childhood Dreams"
  Carnegie Mellon University Professor Randy Pausch gives a full lecture at CMU on how to achieve your childhood dreams, and why it’s totally acceptable to dream beyond limits. It is such a unique and inspiring moment in his life because Prof. Pausch has cancer and doesn’t have much time too live (he was diagnosed with the disease on August 2007, and the doctors told him that he had about 7 months to live). WOW! It feels so good to see a human being so full of life given these circumstances. He surely affected my way of thinking about life in more than one way! One thing about his lecture that I’ll never forget is the "brick wall of life"…you’ll understand better when you see this video.
• "Time Management"
  Once again, Professor Randy Pausch gives another talk in front of a full auditorium at University of Virginia. His talk is on time management, and what better person could give a talk like that than someone who doesn’t have much time in his hands? Prof. Pausch gives pragmatic ways and useful tips on how to better manage your time, optimize your results and minimize stress in a simple, intelligent and funny manner. I pray that he’ll have many more years to live. Feel free to share it amongst your friends and co-workers.

Blog Posts

• "ASP.NET MVC Example Application over Northwind with the Entity Framework"
  Brad Abrams writes about these new technologies from Microsoft. If you have VS2008, ASP.NET 3.5 Extensions, ADO.NET Entity Framework Tools DEC 07 Preview and the Northwind sample database. The article itself is well presented and partitioned with lots of screenshots. Not a bad intro!

Articles

• "How Difficult is it to Write a Compiler?"
  Laurence Tratt wrote a very simple article focusing on the higher-level steps required to build a compiler in its most general approach. I have never wrote a compiler before but his article sure gave me a little push to try to one of these days. Laurence describes how most of the ‘popular’ compilers in use today are using a set of three basic stages: 1) creating a parse tree from an a source code input, 2) generate an abstract syntax tree from the parse tree and, 3) turn the abstract syntax tree into object code. If your next programming challenge is to design a compiler (maybe for the fun of creating one?), this article will surely help you on the way.
• "How to Use Design Patterns: A Conversation with Erich Gamma"
  In this three-part article, Bill Venners talks with Erich gamma on what he thinks people should actually do with patterns? What should their attitude be about patterns? How can people use patterns to do a better job? What is the real value? He also dives into the approach that was taken to write the Design Patterns book and how it was influenced by Christopher Alexander’s work on construction/building design.
• "A Guided Tour of WPF"
  Josh Smith has published a very informative series of articles that will no doubt help you to learn a lot about WPF (Windows Presentation Foundation) if you’re starting out with that new technology. At work, we’re currently migrating an old VB 6 application to a .NET version with WPF. We were thinking of going with GDI+ for drawing and managing the UI elements, but after reading Josh’s articles, it is without a doubt that we’ll jump on the WPF train. His articles and the MSDN documentation concerning WPF are a good combination to properly learn and use WPF in your .NET applications!
• "The WPF Thought Process"
  Written by the same author of the "A Guided Tour or WPF", this article shows you the inner thoughts a novice developer to WPF goes through when tackling a UI-centric problem. At the end, it really shows the power and simplicity of WPF over other UI technologies such as GDI+.

Podcasts

• "Interview with Erich Gamma"
  Software Engineering Radio interviews Erich Gamma, one member of the GoF and distinguished engineer at IBM, on the Eclipse IDE architecture core and everything else related to Eclipse. He also shares with us how and why the JUnit tool came to be (very interesting stuff), as well as his new project and passion: the Jazz project, a technology for collaborative software development.

Screencasts/Webcasts

• "Kent Beck on Implementation Patterns"
  InfoQ interviews software crafstman Kent Beck on the subject of his new book, Implementation Patterns (which you can read a sample chapter here), and also talks about what it takes to be Agile and what it really means to be Agile. There’s also a good conversation around software patterns and why there an important concept to understand in software development. I really enjoyed this interview and most importantly the last thing Kent said: "And that’s what I think: patterns will make a difference when people write about stuff they care about". The video is half an hour long.

News

• "Microsoft bids $44.6 billion to buy Yahoo"
  Wow, now that’s a lot of money…I guess there’s more to software than 1’s and 0’s…