List of Ruby and Ruby on Rails Tutorials

As I mentioned in a previous post, I have been working with Ruby and Rails to broaden my skills. While books are a great way to learn a new language, for Ruby and Rails, there are plenty of online tutorials to help you get started. Here's a partial list of Ruby and Ruby on Rails tutorials

Ruby
Why's (Poignant) Guide to Ruby: While I'm a .Net guy, I do know that every Ruby developer needs to read Why's (Poignant) Guide to Ruby. Its pretty close to a law. I hear your Ruby code won't run unless you answer some Microprose-esque like questions about Why's Guide to Ruby. In all seriousness, it is an excellent read and very informative, if not somewhat unconventional in the realm of Computer Language books.

Ruby in 20 Minutes: This is from the official Ruby website, and as one would expect, is an excellent introduction into Ruby. While I didn't time myself, the lesson did move pretty quickly and was easy to understand.

Ruby from Other Languages: Again, this comes from the official Ruby website and offers a comprehensive look at how Ruby compares with other languages.

Learning Ruby:If you are looking for a more classical training in the Ruby language, then Learning Ruby from a University of Maryland website is the closest I've found online.


Ruby on Rails


Setting up Rails on Windows: While I haven't gone through the tutorial myself, this seems to be a pretty comprehensive tutorial on setting up Ruby on Rails for a Windows development environment.

Getting Started: This comes from the official Ruby on Rails website, and while it explains a great deal about the Ruby on Rails methodology, it also requires a working database setup and provides little guidance for the user if things go wrong.

Tutorials Point: This sites starts at the beginning of Ruby development and introduces the reader to concepts that the reader will use, but may take for granted. In all, this is one of the better tutorials on Rails.

Rad Rails Tutorial: This tutorial is geared towards the users who use Aptana's Rad Rails plugin for Eclipse and Subversion. While I prefer Mercurial, I was still able to do this tutorial by skipping over the portions regarding Subversion.

Ruby on Rails Tutorial (book): This is a fairly comprehensive book regarding Rails that is still being edited. As such, there may be mistakes. But, the book covers many more advanced topics then any other tutorial on this list.


While these tutorials will not turn anyone into a Ruby or Ruby on Rails guru over night, they do provide a starting point for the Developer. Ruby is a new technology, but like any new technology, time and effort must be put in to understand how to use.

Setting up Ubuntu 10.4 for Ruby on Rails Development

In late July last year, I tried the impossible, setting up a Windows machine for Ruby on Rails Development. I spent an entire weekend on the project, and while everything seemed to work at first, once I started writing a simple application, I would receive random errors that I could never make much sense of. Part of the problem may have been with my system, which had Aptana Studio installed previously, but I had removed it after I realized it was just Eclipse with some fancy plug-ins (which could be installed on a standard Eclipse install anyway).

Most of my aggravation lied in getting the database setup. In the end, I was faced with numerous database errors that would crash the Ruby interpreter, and numerous other issues that made me vow to never try to develop a Ruby on Rails application again on Windows.

But, I've recently installed Linux on another machine, and with a few web site ideas bouncing around in my head, I thought it would be best to attempt to learn Ruby on Rails again. In the process of setting this machine up, I ran across this tutorial for installing Ruby on Rails on a Windows machine. While it sounds promising, I have a better alternative (Linux) on hand and won't torment myself with Ruby on Windows again.

(Note: This is not a definitive guide, but just the steps and errors I encountered while setting the machine up.) To setup Ubuntu 10.4 for Rails development, I first fired up Synaptic Package Manager and selected Eclipse, Ruby, Rails, and their corresponding decencies for installation.

Once these have all been installed, I navigated to Radrails.org and went to the Download page and followed the instructions for updating Eclipse. For Eclipse Galileo, navigate to Help > Install New Software. On the dialog that appears, I clicked the link "Available Software Sites", clicked "Add", then provided the URL provided on the Downloads page. Click 'Ok' on this screen and the previous one, returning to the 'Install' screen. In the drop down box at top, select the URL you just provided and once it loads, select the plug-in it lists below.

After the install is done, Eclipse will need to reboot. After it is reloaded, go to Window > Perspectives > Open Perspective.. and select the Rad Rails Perspective. Once this perspective opens, it will display a list of Ruby gems that need to be installed. Select OK to install the Gems.

I received numerous errors at this point, but I'm at a lost on how to fix it. I did copy the errors to examine another day.

Afterwards, I created a new Rails project, but I received an error stating that it could not install the latest version of Rails. But, I installed Rails in the first step, so as the instructions told me, I modified the config/environment.rb file to comment out the RAILS_GEM_VERSION variable, and re-ran the project. The starting project loaded, but as I was running through this tutorial, I ran into a couple of issues.

First, I received the following error:

Routing Error

No route matches "/say/hello" with {:method=>:get}

To fix this error, I modified the Config/routes.rb file to recognize the new controller 'Say'.

Unfortunately I made the fix and started receiving this error:

uninitialized constant ApplicationController

To fix this, I followed the instructions at http://www.hackido.com/2009/03/quick-tip-solve-uninitialized-constant.html, which solved the issue.

Despite a few issues I've ran into so far, my experience of Ruby on Rails on Linux is MUCH better then my experience on Windows.

Running Mercurial with Subversion

On the project I'm currently assigned to, we use Subversion as our version control system. Subversion is a great tool and is certainly a step up from the alternatives that we have used in the past. However, after reading a fair bit about Distributed Version Control systems (hginit), such as Mercurial, I've been wanting to play around with one of these systems in a real project. Code version control is not something that should be changed on a whim, so there's little hope for me to get Mercurial adopted department wide. But, the very nature of Distributed Version Control systems offer a way to utilize the system without forcing it upon others.

Distributed Version control systems offer 2 main benefits. First, they allow a user to keep a local repository of changes without having to pollute the central repository with changes that may break the build or unit tests. For those coding large components that take weeks to finish or those who are doing exploratory coding, checking code into a central repository is not feasible.

Another, less obvious benefit comes from how Distributed systems record revisions and perform merges. Whenever the code is checked into a local or central repository, a diff of the changes between the last revision and the new revision are stored. When a merge is performed, the code can replay the diffs to create a merged file. This will not solve every merge conflict, but it goes along way to make merges less painful.

Thanks to a Python package called hgsvn, I was able to download our project's code from the Subversion repository and place it in a local Mercurial repository in one easy step. The package hgsvn contains 3 scripts. The first, hgimportsvn, takes the URL to the SVN repository and then will download the code from the central into the current directory. After the code has been downloaded, it is then checked into a new Mercurial repository. This last part is done en masse and can cause problems if you have a very large code base and/or a very large file in that code base (as I would have very good reason to know).

If you run into this problem as well, 1 solution to try is to call hgimportsvn on the various sub-folders of the central project. In some instances, this can be made to work, but not in others and I can't find a rhyme or reason behind it.

The second script in the package is hgpullsvn, and it pulls the latest code from Subversion for the current directory and places it into the Mercurial Repository. Each revision in Subversion gets its own corresponding revision in Mercurial, and hgsvn keeps track of what Subversion revisions have been brought over to keep everything in sync. Unfortunately, it seems to overwrite in local changes that have not been committed into Mercurial, so ensure that Mercurial is up-to-date before running this.

The last script is hgpushsvn, and it commits any code you've checked into Mercurial into Subversion. While you can certainly use this tool, I've found it just as easy to use TortoiseHG to check the changes into Mercurial, and then use TortoiseSVN to commit those changes into Subversion when I'm ready.

Using Mercurial locally, Subversion on a central server, and hgsvn to synchronize the two, one can get a large benefit of using a Distributed Version Control System, without forcing the system upon others.

Challenges in Installing Mythbuntu 10.4

While I'm a .Net guy, I've been known to tinker with Linux now and again. I've built/rebuilt many machines using Red Hat 7.3, 9, Fedora Core 2, Fedora Core 4, and most recently, Mythdora (a Fedora Core release with MythTV bundled with it).

But, I've heard a lot of good things about Ubuntu, and there has been a lot of hype ahead of the Ubuntu 10.4. So when it came out last Thursday, I downloaded a flavor of it, Mythbuntu.

The installation of Mythbuntu had a couple of hiccups along the way however. On the first attempt, I realized that the system did not detect my main hard drive. After changing the pins on the Hard Drive to 'Master', I re-attempted the install, with the machine on its side. Here I ran into my first problem, before the install started, I received the error "Unable to find a medium containing a live file system".

Many posts suggest testing the CD, but as I already had reached the installation wizard, I was fairly certain that the CD was fine. After numerous attempts, I eventually re-arranged my Hard Drives and stood the tower up instead of having it on its side. This time the installation proceeded without an error.

There were only two other minor hiccups. First, I had an external hard drive which contained my entire Music library, plus a couple recordings that I saved. On XCFE, the windowing system that Mythdora installs by default, I could not get the Hard Drive to connect.

Each time, I've tried to install Linux in the past, I've always installed KDE and Gnome side by side. And each time I try to use Gnome, or some other windowing system, I find myself running back to KDE. While KDE is not always the most stable of the options (see below), it has access to all of the System Tools that I need in a nice Graphical interface. While any of the Administrative tasks could be accomplished in the terminal with commands and configuration files, I prefer the more Dummy-proof Graphical interface because when it comes to Linux, I am a dummy.

KDE, in this case, was the solution I was looking for. After I installed KDE and loaded KDE up, I was able to get the Hard Drive to connect by simply plugging in the drive.

The last glitch I encountered in the process was a minor nuisance. While copying the music files over, the Window Manager for KDE, Dolphin, crashed. While I don't know exactly what caused the error, I suspect that the total size of the files was the cause, as I was able to copy a smaller subset of the files.

In the end however, I am quite impressed with the changes that I see in the latest versions of the Linux kernel, KDE, MythTV, and with Ubuntu in general. The issues I encountered were minor enough that I could work around them. I'm not certain if Ubuntu 10.4 will upset the balance of the Desktop operating systems, but it is a step in the right direction.

The need for a Mentor in a Developer's early Career

(Author's Note: I wrote this a couple of years ago after my mentor left the company. Shortly after he left, nearly every other Developer who felt the way my mentor and I did left the company. Demoralized, I abandoned this blog for about a year, but there are still some good nuggets of information here.)

The old saying “When it rains, it pours” has proven very correct rather recently. Not only have I been busy with a particularly nasty bug lately, but I also received news that one of the developers on another team at the company I work for was leaving. He's been a mentor to me since I started my career in development, so it is with great reluctance that I see him leave.

I have been giving a lot of thought to learning from the events that occur in my daily work. So, I've been reflecting on why I've felt such a kinship with my mentor (and why I keep referring to him a such), as well as why I think it's been helpful for me.

First, he and I have a lot in common. Besides a similar sense of humor, we also have a strong desire to not only write code, but write GOOD code. On several occasions when I walk by his office, he will point out the code which he is currently working on and show me questionable coding decisions his peers have chosen and what he is doing to correct them. Often we'll discuss an optimum solution, but often, with project time constraints being what they are, this is purely an academic discussion.

Second, of most of the developers I know, he is one of the few who seem to care about the craft. I'd say most developers fall into a category called “Code Monkey”. A “Code Monkey” might do designs, some coding, and be very proficient at it, but has little desire to learn beyond what the everyday tasks requires of him/her. A “Code Monkey” knows a few languages very well, but couldn't name, much less code in the latest “hip” language. The ''Code Monkeys" will never see this post though, because the very same desire to read blog posts and other writings from other developers demonstrates a desire to become better at our craft.

The developers who care to learn beyond the every day tasks, who desire to make things better, and are actively learning about new techniques and how to employ them are true Software Engineers in my book. They care about their chosen profession, and realize that the field is always evolving and requires a commitment to learning.

He's also the developer who introduced me to Code Complete. This book has proven an invaluable insight into the Development process and thanks to it, I've found and have been a daily reader to the blog Coding Horror. If you are not familiar with either the book or the blog, then I urge you to check them both out now. I'll wait.

Finally, he's been a good friend whom I've always been able to talk to. The nuances of corporate culture, development style, internal code systems and the like make it easier for us to relate to each others problems.

In the end, I know my fellow Software Engineer must move on to another company for a variety of reasons. Hopefully the two of us will be able to stay in touch. In the mean time, I will look forward.

In many classic tales, the hero of the story must lose his mentor before achieving greatness (Luke Skywalker and Obi-Wan Kenobi, Harry Potter and Albus Dumbledore, Frodo Baggins and Gandalf, just to name some more well known examples). Perhaps this is my chance to step out on my own and find my own path.

If you're staring out in development, I urge you to make friends with some of the Senior developers, either on your team or on others. The bond you make with them may provide you with knowledge and understanding that you would not have gained on your own.

A Software Engineer's Development Path

A couple of years ago, my employer jumped on the Personal Career Development band wagon. They hired a consultant, setup training for everyone, and encouraged everyone to set career goals and make plans to achieve these goals.

But most of the training focused on the typical 'soft' skills of career development, such as communication, project management, organization, etc. While this may be the typical career development tasks for business people, for those in IT, and especially software development, these tasks will likely be on the periphery. The bulk of a Software Development training will center around the technical knowledge, software development processes (which are unique and ever evolving), software design, and project estimation. The consulting company Construx has a very good Professional Developer Handbook that I'd recommend checking out.

Soft skills, such as communication, are important, but present a unique challenge. While conversing with other developers, the technical terms and jargon can be used to quickly explain an issue. But, when conversing with business people, this needs to be kept to a minimum, even if it requires explaining the situation in a verbose manner.

There is another matter to discuss regarding career development: job promotion. There are two typical routes a developer will take. The first route takes a developer from a Junior Software Developer to a Senior Software Developer. Eventually, this developer learns a great deal about the processes and management of a software project and becomes a project manager.

The second route sees a developer progress further until they become a Software Architect or a DBA, or a specialist in some particular technical field. Or perhaps they continue to be a Senior Software Developer. Whatever the title, the second route arrives anywhere but management.

As for me, I can't predict the future, and its hard to say where I'd like to end up. I've always liked the idea of becoming an Architect, but my experience with them has not always been a pleasant one. My current plan is to continue coding until the pace of change is faster then the pace at which I can keep up. At that point, I think a management role will suit me better.

Do you have an overall career plan that will lead you to one of these two routes, or do you have another destination in mind?

Reading Lists

The vast collection of Human Knowledge can be found in books. And sometimes, it feels like I have a large percentage of that knowledge in my book cases at home. Through Borders, eBay, Amazon, and Bookmooch.com, I have many places to get new books to add to my collection of Knowledge.

Yet this Knowledge goes to waste unless the volumes get to tell their story. That is why I have set up numerous reading lists for myself,  and following my policy of making goals public, I have placed the current book from each list in a sidebar with a link to this page and I will keep this list updated.

As you can see on the sidebar, I currently have four reading lists: Certification, Software Development, Classical Education, and Miscellaneous.

The Certification list contains the textbook necessary for the Certification I am currently working on. Right now, I am pursuing either the MCTS Asp.Net 3.5 or 2.0 certification. The 3.5 Certification is more current, but the books for the 2.0 are a lot cheaper on Amazon. Either Certification requires 70-536, which  is the test I am currently preparing for.

My Software Development reading list contains books on Software Development but aren't directly related to my Certification training. For this list, I am currently reading Mythical Man Month.

The Classical Education list contains books recommended by the book The Well-Educated Mind: A Guide to the Classical Education You Never Had. I came across this book a couple years ago thanks to the Book Lover's Page-a-Day Calendar. This Book describes the classical method of education and how to apply it to fiction novels, histories, autobiographies, plays, and poems. For each genre, it provides a reading list. Sadly, even though I've attempted 3 times to start this list, I've only completed abort half of the first book on the list, Don Quixote.

My Miscellaneous reading list includes any other book not on the other lists. Currently, I am reading Getting Results the Agile Way. Scott Hanselman tweeted about the book and I decided to look into it. The book describes itself as a system for managing outcomes that is easily incorporated into an existing System. Since starting this book, I have certainly found this to be the case. If you are like most people and need to get more at of your day, then you need to check out this book.

Technical Writing

Writing skills are a necessity in many different jobs, including Software Development. While it is one thing to be able to write code for a system, it is another to describe that change in writing. This can include the comments in the code, the check-in comments in the source control, a write-up of the fix in a bug tracking system, or a technical design. Each piece of documentation has a different use and target audience, and the first key for success is to understanding this and to write for your audience.

Inline code comments

Only developers will see your code comments. So feel free to use terms and language other developers world understand. The style, effectiveness and the format of code comments has been discussed and argued extensively. A Google search for "Comments in Code" returns a staggering 472 million results, so I will not attempt to discuss that here. But do remember that your audience can see the code themselves. Your comments will add nothing it they are simply repeating the code. What cannot always be conveyed through the code is why a particular coding method was used and the intent of the code.This is what your comments should explain when necessary.

Check-in Comments

Check-in comments are ained at other developers just like code comments. These comments should be short but informative. It should briefly describe what changed at a high level and for what defect or requirement so if another developer needs to know why a change was made they can reference the defect or requirement.

Defect Report

Defect reports will be read by other developers as well as testers, business analysts, and possibly support people. Writing for this large audience can be difficult at first, but I find the best approach is to write your response geared towards the non-technical folks first, and add more technical information in each subsequent paragraph as necessary. In this way, those who need just the basic information can get the information quickly, while other developers researching your issue at a later date will have all the logical and technical information that you have provided.

Technical Design

While college pretends to prepare yor for the real world, they never tell you quite how much of the time you will spend writing designs. I probably spend between 20 and 30 percent of my time reading or writing designs. The audience of your technical design may differ, but where I work, Developers, Business Analysts, and sometimes Testers will review designs, so the document must be accessible to all of them. Since Defect Reports and Technical Designs share the same audience, the guidelines for Defect Reports apply well to Technical Designs.

General Tips for Technical Writing

Remember that you're not writing the next great novel. Keep the language simple and use the same language or phrase to explain a task multiple times. There is no need to use a thesaurus to make each


10 Outline Document
20 Write Document
30 Revise Document
40 Goto 20

Software Development is unique in that in order to properly design it, you must first determine how to solve the problem. Once you have solved the problem in your head, you can begin to design it, but the process of designing it will reveal edge cases you didn't previously consider, and perhaps you will find places for improvement. Thus, you may find that you need to re-design your solution. The best way to write a technical design document is to follow the above process for a couple of iterations until you are comfortable with the document.


When writing for other developers, it is very useful to know the right terms. Every developer should know the name of common Design Patterns, technologies, and techniques, and using these terms in technical writing can allow the focus to remain on what is important, and not on the details of the Model/View/Controller design pattern.



Technical writing skills are a must for software developers. Unless you are working on a project by yourself, eventually you will need to tell someone else what the code does or what the code will do. However, even if you are the only developer on a project, code comments and documentation may save you if you ever forget why you wrote that dirty little hack in a method buried halfway down in the code base.

Idle Hands

I'm currently reading through Getting Results, a productivity book based on desired outcomes. One of its guiding principles is to eliminate Analysis Paralysis, a condition that occurs when a person, Department, or institution becomes paralyzed while analyzing a set of alternatives. So much analysis occurs that nothing gets accomplished, whereas a great deal could have been accomplished if action was taken, even if it proved to be the wrong decision.


The new book Rework by Jason Fried and David Heinemeir Hansson of 37 Signals also espouses this idea that action is preferable to inaction. With the phrase 'Planning is Guessing' in the book, it is clear that the authors put little stock in up front planning.

From my limited experience, I have to agree that the state of doing is preferable to analyzing. About 2 years ago the development project I was on came to a screeching halt while many requirements were discussed for inclusion into the next release. For reasons I'll never fully understand management spent several months planning and debating the direction of our product, when we could have designed, developed, and tested a major release to the product.

During this time, the development team had little to do. About once a week I would ask for more work to do, but my manages rarely had anything for me. We had a few support issues to work on, and a few internal projects to work on, but I found myself with alot at free time.

As a developer on this project, my hands were tied. Due to a bad release cycle a couple years earlier, developers were not allowed to touch the code unless they had a specific requirement. We could have re-written piles of the code and done away with the behemoth 1000 and 2000 line functions, but that was not a decision the developers were allowed to make.

Anyway, it was during this fine that it formed a couple bad habits that l still have today. I began subscribing to numerous blogs, reading online technical articles, and even a couple of books during the day while waiting for work. During this time, I was exposed to Why's (Poignant) Guide to Ruby and Getting Real, both very good books from the Ruby community.

Today, I still find myself habitual Checking for new blog posts throughout the day, even though I have plenty of work to do. It is even worse now then before, because I'm following many more blogs today then ever.

In addition to the wasted time by having a development team do nothing for a long period of time, one also risks them becoming lethargic and the possibility that they develop bad habits that do not easily disappear when work returns.

The Wisdom of Elders

I'm always surprises me whenever I'm told I've done a good job on something. Part of this is because I am my own toughest critic. I have not found an application where this trait has served me well, but it's who I am.

The other day, I was asked to take on a new responsibility at work. The task would require learning a new code library, but I jumped at the opportunity. My enthusiasm and willingness to take on new roles has really impressed the management at my company, but from my point of view, I've done nothing special.

Learning to me is second nature. I've been gifted with an insatiable appetite for knowledge in many fields. My many interests include computers, electrical engineering, history, writing, politics, astronomy, model railroading, geology, geography, photography, and gardening. There are so many sub-topics of computers that I'm fascinated with that I won't even try to list them all.

Part of my thirst for knowledge comes from two sayings my father told me while growing up. The first, which came from his grandparents, was that the day you did not learn anything new is the day you die. While morbid, it makes a good point. With this in mind, my family would go around the table at dinner and discuss one thing that we learned during the day.

The other saying my father shared with me when I was a teenager is that the one thing no one can take away from you is what you know. It is this saying in particular that really drives me to learn new things, and in a field that is constantly changing, like Software Development, if you are not moving forward, you are falling behind.

My father-in-law has also shared a couple tidbits of wisdom with me that are a bit more practical in nature. The first is to always have an updated resume. Unfortunately, we don't live in the 50s, when it would be possible for someone to work for one company their entire adult life. Nowadays, most workers will switch careers a couple times in their lives. Having a resume that is up-to-date will eliminate one necessary step for finding that next job.

I would even go so far as to suggest having a supplemental document to your resume that lists EVERYTHING under the sun that you can thing of that you know. I try to tailor my resume to the job I am applying for. While I'm not adding skills I don't have, I do emphasize skills highlighted in the job posting and removing skills that do not seem important.

An alternative to a supplemental document would be a CV. The Stack Overflow Careers site has a CV that you can fill out for free. So long as you remember to keep this document updated as well, I see no harm in using this instead of a supplemental document.

The final piece of wisdom comes from my father-in-law, who told me to dress as if I had been promoted to the next level up in the management chain. Thus, if you are not a manager, you should dress like one. If you are a manager, you should dress like an executive.

My work is very relaxed on dress code. In the summer, it is common to see people in khaki shorts, T-Shirts, and sandals. In the winter, Jeans, T-Shirt, and tennis shoes is the norm. So, when I started wearing Khaki pants, dress shoes, a button up shirt, and a sports coat, I certainly got a few remarks. I've dressed down a bit since the first day, opting for a T-Shirt under the sports coat. Since switching to this level of dress, I have felt a bit more confident and professional and that can never be a bad thing.

Build failed on an ILog Project without an error

I was recently working on an ILog project. ILog is one of many Business Rule Engines out there. Business Rule Engines are becoming more popular. How do I know? Because one Developer wrote Space Invaders  using a Business Rule Engine and Business Rules.

(As an aside, I'm not a big fan of Business Rule Engines because one of their touted benefits is that if will free Developer's time for other things. I have yet to see this benefit materialize on our project. However, they do have many other benefits, but that is another post for another time.)

While taking over the responsibility to maintain the business rules from another developer, I tried to build our rules project. Unfortunately the build failed without a message explaining why.

I exited the solution and reloaded. The reason for the build failure was displayed in the error list this time. In my case, the Model needed to be rebuilt. So I switched to the Business Object Model view and selected  Refresh. When I went to Build  the Solution, this time it succeed.

Each tool has its own quirks, and ILog is certainly no exception.

My goals for the next 3 months

What is not started today is never finished tomorrow

~Johann Wolfgang von Goethe

I like to set goals for myself and if I make them public. In doing so, I feel I'll put more effort to complete them. When I restarted this blog three months ago, I set several goals for myself. My first goal of the was to write 1 blog post a week on average. That worked out to 17 blog posts in all. I actually posted 21 blog posts in the last 3 months, so I did even better then I had planned.

I also planned to redesign my Blog. While it still isn't professional looking, it is an improvement over the old design. I still have a few revisions I'd like to add but these are small changes that I will make over time.

Next, I planned to finish Strunk and White's Elements of Style and to reach the halfway point in the Self-Paced training kit for the MS Certification Test 70-536. I Finished both of these goals with ease and I've even started on the second half of self paced training kit.

Finally, I wanted to get my Stackoverflow rating op to 300. As of March 1^st, it is 369.

As for the next 3 months, I'm going to build on the momentum I already have. I plan to write 20 blog posts in this quarter, starting with this one. Second, I'm going to finish the Self-Paced Training Kit for 70-536. Third, I'm going to finally read Mythical Man Month. Next, I'm going to get my Stackoverflow reputation up to 500. Finally, I'm going to make a contribution of some sort to the Open Source project (or create my own).

This time, I've chosen a more aggressive set of goals. But with all of the previous goals accomplished, I'm ready to tackle a new set of goals.

A few interesting links

Things have been crazy the last couple of weeks, so instead of a normal post today, I'm going to do a short little link post. Here's a few links I've found in the past couple of weeks that I've found interesting.


If you are currently training to take a MSDN Certification, you can currently get a free retake exam if you take both the first exam and the retake by June 30, 2010. You can find more about this here.


For my exam, I'm planning on just reading the Self-packed training kit, doing the exercises, and answering the sample test questions the book provides. However, I would also like to take another practice exam, so I will be using the free exams offered by Accelerated Ideas.


At my office, its the time of year for performance reviews. Like most geeks, I'd like to look nice, but I'm not quite certain how to go about it. I found this blog post on Lifehack particularly interesting. However, I don't agree with the author that non-pleated pants are more slimming then pleated pants. My worst looking pair of pants were a non-pleated pants. Most of my pants are pleated, and I don't think I look any worse for it.

There's also more information about men's fashion at this blog post on Wardrobe Oxygen, but I'm a little more skeptical of the advice presented here. I just don't think sandals are a necessary item for a men's wardrobe. I find sandals very uncomfortable, and not appropriate for the office, even one where the dress is business casual.


I came across an interesting blog post the other day regarding the writing style of popular blog posts. The author surmises that popular technical blogs are popular because they don't just share information, they also tell a story. While it would be nice to think that there are many people out there just waiting to read what we have to write, the reality of it is that they have to be drawn into your writing.


Finally, there is a new website that proves that interesting stories do indeed make for interesting reads.This site is a tutorial for the source code tool Mercurial written by Joel Spolsky. The site is very well designed and the tutorial is a fun read. Even if you aren't using Mercurial and won't be anytime soon, I'd still recommend that you read it.

Switching Projects

I've had to work on a couple of different Software solutions in my 5 year career. Each time I've made the transition I've felt like a fish out of water for the first couple of months while I learn what the software does, how the code works, and what processes and tools the team uses. In order to save some hassle during the next transition, here are a few tips and suggestions for transitioning to a new role to maintain an existing application.

1) Read through any documentation that the client is expected to read. This will give you an idea of how the product works (helpful in recreating/unit testing later) and introduce you to the terminology used by the software team and clients (useful in communicating with others).

2) Walk through the software and play around with it. As mentioned above, you will eventually be expected to navigate around the software to unit test it and to recreate defects. The more you become familiar with the project at the beginning, the easier your task will be later. But remember, when doing your testing, make certain you do so on a stable build. Encountering defects while you are still learning the system can be confusing.

3) Setup your development environment and download the source code, following any documentation that your team might have. I really like the suggestion Joel Spolsky made on the StackOverflow podcast #80, if the documentation is inaccurate, fix it. If it isn't detailed enough, add to it. If it doesn't exist at all, then write it yourself.

4) Are there any special design documents, a wiki, or some other supplementary documentation for the code? While these documents are rarely kept up to date, they may explain how certain key features of the software work.

5) Learn the basic structure of the code, and learn what the key methods and classes are. It's best to try to learn this on your own, but if you make an effort to learn the code before asking another member of the team for help, most of the times they will be happy to help you.

6) Learn who the key people for the project are. There's always key people for any project, the project leader, the lead developer, and often there's a business analyst, and a lead QA Engineer. It is important to know who these people are and understand how you will be expected to interact with them on designs, code hand-offs, and defects.

7) If there are any Third Party utilities used by the software, learn where they are used and make certain you understand how to use them. Some may be as simple as an external library, while others may as complex as Document/Report generation tools or Business Logic tools. It would be foolish to expect you could become an expert in these tools, but you should at least know what each do.



This should provide you with a rough outline of what to do when you are assigned to a new project. Depending on the work load you are given, you may not be able to accomplish everything on this list, at least not initially, but everything on this list is important and should be done eventually if you want to be able to contribute to the project at a high level.

The current state of your Development Team

If you're a manager of a software development project, how do you gauge the morale and mood of the team? I mentioned in a previous post that my boss recently took the direct approach and asked us all to answer a series of questions relating to our morale and such.

For this approach to work though, I'm pretty certain everyone needs to be honest. Given the current working environment (high unemployment, worry of layoffs, pay cuts, etc.), its unlikely that many, if any of the team members provided accurate results. There's just too high a risk that the information could be used maliciously. Personally, I provided a lot of well thought out responses that are true, but I certainly didn't share all of my thoughts on the questions and I carefully edited the responses. Wouldn't you?

I suppose the answer to that question is “It depends on the situation.” What kind of work environment is it, what's the culture of the company, what's the history of the company, what is the management team like, and how the question was asked. In some corporations, the level of distrust between management and employees may be too high to get useful responses from an employee directly.

But surely there are other ways to find out the current state of your team besides asking the team members directly? None of my other managers has ever asked the team what their morale is directly like my current manager, but surely they still had a good idea of what the team's morale was like?

And I think the answer to that is quite simple; all of my previous managers tried to engage the team members in meetings or in hallways. By talking to each members of the team on a regular basis over a long period of time, they were able to discern when the attitude of the team had turned sour and try to improve it when needed.

But as a manager, asking employees directly is probably not the best approach unless you're certain your team trusts you enough not to use the information maliciously.

Recommended Reading

Here's my recommended reading list, with computer science or computer engineer students in mind, as well as junior Software Developers.

Code Complete by Steve McConnell
A must read for all Junior programmers, Code Complete covers everything you need to get started in professional software development. My College education was very heavy on the theory and didn't cover much of the actual practice of Software development. This book helped bridge the gap and should be required reading for seniors in a Computer Science program.

Design Patterns by Gamma, Helm, Johnson, and Vlissides
This is the ultimate book on software design. Its over 15 years old, but it is still packed full of useful information. You'll find that many of the common libraries that you come across use some of the patterns laid out in this book, and it is helpful to understand their convention. I've always found this book to be a little difficult to read because all of the code samples are in Smalltalk, but if you can learn enough
Smalltalk to understand the samples, this book should make sense to you.

Refactoring by Martin Fowler
If you've done maintenance programming of any kind, you'll have an appreciation for the principles and steps defined in Refactoring: Improving the Design of Existing Code. This book explains many common Refactorings, reasons why you might want to do them, and suggestions on how to perform Refactoring on large projects.

Refactoring to Patterns by Joshua Kerievsky
Ideally, you should read this book after reading Refactoring and Design Patterns, but I actually read Refactoring after this book. I was still able to understand this book, which is a huge achievement both for the author of this book, Joshua Kerievsky and the author of Refactoring, Martin Fowler, who came up with very simple and easily understood names for his common refactorings. With better examples then that provided in the original Design Patterns book, I was able to fully understand the power and beauty of the Design Patterns.

Web Technologies by Jeffrey C. Jackson
If your College experience is/was like mine, then you covered regarding Web development. With nearly everything on the web these days, understanding the technologies behind it is essential. This book covers many different Web Technologies, including HTTP request, HTML, CSS, JavaScript, Java Server Pages, and Web Services. This book serves as a good introductory or intermediate text book on the Web.

Mythical Man Month by Frederick Brooks
This is the quintessential book on project management. The lessons taught in this book are so important, that you may have already learned them from others or through other books, as this has been a very influential book. But just as you might choose to read Poe's The Raven despite having seen it parodied by dozens of cartoons and shows, so to is it important to read the original source for many ideas in project management and software development.

201 Principles of Software Development by Alan M. Davis
I've just picked up this book a few weeks ago. It is a very simple read. Each of the principles takes about just a few sentences to explain, and then the author provides a link to the original source of the principal. If you've run out of books to read on software development, this one just might point you in the direction of a few other great books.

Dreaming in Code by Scott Rosenberg
All of the other books are pretty technical and can be difficult to read. Dreaming in Code reads like a story because it is one. It is the story of a software project named Chandler. The book follows the course of the project for the first couple years after its inception. The book outlines delay after delay, and gives an insite into the software development process and shows that even the smartest programmers may miss the mark.


I have a few other books I'm currently working on, but reviews of them will have to wait for a second installment at a latter date.

If you are looking for a good introductory book for a particular language for cheap, Barnes and Noble used to publish and carry a series of books on different languages, but they do not appear on their shelves. Since I live next to a Borders, I rarely find myself in a Barnes and Nobles so I haven't verified that they still carry these books.

Validating a Phone number field with Regular Expressions

Validating user input is a very common task when building a program with a user interface. While this task may appear daunting at first, it can actually be quite easy. Once you know of a good approach.

Regular expressions were born in the Unix world, but they can Be of great benefit anywhere. Regular expressions are complex and intimidating, but once you have mastered the basics they can be used in many tasks.

Let's look at a common usage of Regex: to validate user input. In the following code, we need to verify that the string phoneNumber contains a valid US phone number. First we need to verify that only numbers are imputed into the system.


private boolean IsUSPhoneNumber(string phoneNumber)
{
return Regex.IsMatch(phoneNumber, @"^(\d+)$");
}


Doing a quick test reveals that indeed a string of 123456789 is considered valid. However, so is 123 or 1234567890. Clearly we need to verify length of the string in addition to content. The following code will ensure this:


private boolean IsUSPhoneNumber(string phoneNumber)
{
return Regex.IsMatch(phoneNumber, @"^(\d{10})$");
}


While this is an improvement, there is still much more to consider. What if the user places the area code in parenthesis? This is a fairly common practice and should be accounted for.


private boolean IsUSPhoneNumber(string phoneNumber)
{
return Regex.IsMatch(phoneNumber, @"^([(]{0,1})(\d{3})([)]{0,1})(\d{7})$");
}


This code checks to see if there is zero or one parenthesis, 3 digits between the parenthesis and 7 digits after.

But, there are still other possibilities to consider; such as, what if the user uses white spaces to delineate the different sections of the phone number?


private boolean IsUSPhoneNumber(string phoneNumber)
{
return Regex.IsMatch(phoneNumber,
@"^([(]?)(\d{3})([)]?)([ ]?)(\d{3})([ ]?)(\d{4})$");
}


Or if periods are used?


private boolean IsUSPhoneNumber(string phoneNumber)
{
return Regex.IsMatch(phoneNumber,
@"^([(]?)(\d{3})([)-]?)([ ]?)(\d{3})([ -]?)(\d{4})$");
}


Or dashes?


private boolean IsUSPhoneNumber(string phoneNumber)
{
return Regex.IsMatch(phoneNumber,
@"^([(]?)(\d{3})([)-.]?)([ ]?)(\d{3})([ -.]?)(\d{4})$");
}



The final code snippet will validate most US phone number formats, in just 1 line of code. There are certainly other methods to validate a phone number, but can they be written in 1 line of code?

Team Building Exercises

My current manager recently posed several questions to the team that he wanted candid responses too. He's new to the organization, but he seems genuine in his efforts to improve our process. Several of his questions have gotten me thinking, which I'll turn into blog posts over the course of the month. The first I wanted to discuss is about team building exercises.

My manager asked for suggestions for a team building exercise that we could do. He never explained what he hoped to get out of the exercise but I'm sure it is the generic "get to know each other, build team cohesiveness" mumbo jumbo. On previous team outings we've played laser tag and gone bowling. I believe the team building value in these activities was minimal and was mostly chosen for the entertainment value.

So, what activities could a development team do together in the sake of team building? Here's a few suggestions that I have, though I've not been able to put into practice.

One idea is team lunches. Getting everyone together in one room for an hour in a relaxing environment can be good for the team. The boss doesn't even have to pick up the tab (though it doesn't hurt). An alternative to this would be a lunch pitch-in, where everyone brings in something to eat.

Another alternative is to have a brown bag lunch every so often and select someone to present information on a specific topic. Perhaps a particular design pattern, or new technology, or a new programming technique could be demonstrated. Maybe there is some new internal software being developed that the team could benefit from learning about in a relaxed setting.

If your development projects are like mine, they could use some internal documentation. You can address this issue as a team building exercise by setting up a documentation tool, like a wiki, and ask the developers to submit articles to the wiki. So long as the productivity doesn't suffer you could even create a contest for the best written article, or the best diagram.

Estimation poker itself can be a fine team building tool as well, and it provides some useful output; Estimations for code changes that have been hashed out in a group. Some more information on estimation poker can be found here.

Finally, my current manager has started a new team building exercise with us, he gives us a series of hints about a person on our team and we have to guess who it is. We've done this a couple of times and is a great way to learn about each other.

What team building exercises have you attempted or thought of?

Writing my way to better health

I've made a few references to the PDA that I own. I've found it very handy to use in many places where a laptop is too bulky, like the car or exercise bike. The last six blog posts were either written or edited while on the exercise bike. This is great multitasking that would be difficult to do with a laptop, though there are items out there for this task.

There are a few down sides to working in this fashion. First, because I am spitting my focus between two tasks, one may suffer. I can usually keep a good 10 or 11 mph pace on the bike, but I've found myself going at a more leisurely 8 or 9 mph pace.

Second, the device lacks grammar and spell check. I'm forced to do my best on my own, or hold off checking until I transfer the post to the PC.

The device also lacks internet access so I must wait to do any research or programming until I am on my laptop.

Finally, while the device does its best to translate my chicken scratch hand writing into text, my writing is a bit illegible, especially when on the bike.

Despite these drawbacks, I am getting blog posts done and I'm getting some great exercise while doing it. Given the results, I will deal with drawbacks.

Technical Sources

As a developer. There are many new technological that we encounter from time to time. After several years in the industry, I have found  many good resources to help me get up to speed on anything new.

The first site I recommend is TechRepublic. I found this site back when I was in Desktop Support. While they cater largely to IT people, they do offer articles on Development and Project Management. They cover largely .Net Development, though they do offer some articles on  Java development.

I recently came across another great site called infoq.com. This Site has many in depth articles, video lectures and interviews on a wide variety of development topics. They also have great Customization for their registered users and registration is free.

I follow a large number of blogs. These blogs I've found helpful on a number of occasions. Here is a partial list of my favorites:
  Coding Horror
  Joel on Software
  The Endeavor
  Software by Rob
  Rob Conery's Blog
  Brent Ozar - Too Much Information
  Scott Hanselman's Computer Zen
  Coding4Fun
  10x Software Development

There are a couple of good aggregation sites that often have links to good articles and blog posts. Every so offen, I find a new blos to follow from these sites:
    Reddit.com
    Digg.com
    Hacker News

MSDN has never been one of my favorite sites. The information is often difficult to find, and when I was writing this blog, the site appeared as plain text with very little styling. However, the information on the site is excellent and very helpful (when you can find it). I recommend using Google to search msdn by adding "site: msdn.com" to any of your searches for anything .Net or Microsoft related.

Finally, for ant question development related. I have to recommend Stackoverflow. I've been using this Site to over a year now and I an very pleased with the results I get. The community is great, and it just might be the largest Development community site on the Internet.

Hello World Applications

Convention dictates that the first application a developer is exposed to for a language is the classic "Hello World!" application. While this is useful to learn how to display text to a screen or console at runtime, it provides very little value otherwise. It also does not provide an obvious avenue for the developer to build upon the application to finer tune his skills.

When leaning a new language or technology it is useful to play around with it in a serious program. I try to do this for each new technology I come across. Below is a short list of suggested applications to write when you are trying to master a new language or technology. The list is broke into 4 parts. Web applications, Desktop applications, Mobile applications, and Server . 

Web applications

• Blog
• Online Store
• Photo album
• Fantasy League Software

Desktop Applications

• Developer Tools
• Recipe Keeper
• Blog Editor

Mobile Applications

• To do list
• Workout assistant

Server Applications

• Instant Messaging
• Distributed job application (like Seti @ Home, to calculate primes or other mathematical tasks)

Finally, regardless of platform there is always the opportunity to contribute to an open source project. There are many great open source projects out there that need help from programmers just like you and I.

Handspring Visor vs. Dell Axim x5

In a previous post, I mentioned that I had destroyed my old trusty Handspring Visor and had replaced it with a Dell Axim X5. I've already compared the different Operating Systems of the two devices, so here is my comparison of the two devices themselves.


Size and weight: While the Dell is slightly more ergonomical, the Handspring is the smaller and lighter of the two PDAs.

Battery life: The Dell's Battery life is superior to the Handspring's, but this is more of a comparison of apples and oranges. The Dell has 2 rechargeable batteries; the second to backup the data in case the first dies. The Handspring uses 2 AAA batteries, which can be replaced more easily. The batteries in each lasted about 1 or 2 weeks, but I've found myself using the Dell much more often.

Screen: The Handspring has a 4 color screen (4 different shades of gray) while the Dell has a true color screen, supporting 65,536 different colors.

Stylus: The Dell's stylus is a little flat and can be awkward to use. The Handspring's stylus is a simple cylinder but it feels more natural to hold and use.

On-board memory: The Handspring Visor Deluxe contains a total of 8 MBs of storage, while the regular model only has 2 MBs. The  Dell has 32 MBs of Read-Only Memory (for use by the OS and the various applications) and another 32 MBs of storage space.

Expansion slots: The Handspring has an expansion slot for use with Springboard modules. These proprietary modules offer many options, including a modem, camera, and memory. The Dell comes with two expansion slots, a Type II Compact Flash slot and an SD Card slot. Both the Compact flash and SD slots became standard so they offer many different options and are more readily available, including memory and WiFi. These also have the added benefit of working with many other devices. I have at least half a dozen different devices that use SD Cards around the house. (Note that the SD slot on the Dell only supports cards up to 1 GB in size. The Compact flash slot supports at least 512 MBs.)

Synchronize with PC: Both devices offer synchronization cradles to copy data from the PDA to the PC. I used this option extensively with the Handspring, but only rarely with the Dell. Since I use an SD card on the Dell I use this to copy data from the PDA to the PC.

Navigation buttons: Each PDA has Navigation buttons to the most common applications. There are also scroll buttons to scroll up and down. On the Dell, there are also horizontal scroll buttons and a second set of vertical scroll buttons on the side of the case.

To Do lists: Finally, I wanted to discuss a very important application, To Do lists. The Palm OS has a very simple, yet effective to do list. The To Do list that comes with Pocket Windows 2002 is very powerful, but the user interface is very cumbersome.


All in all, the Dell Axim x5 is a superior device due to its screen, battery life, expansion slots, and
onboard memory. The Handspring Visor has several benefits, including a simpler interface and batteries that are easier and cheaper to replace. While both are great devices, they have both been going for around $20 on eBay, and at that price, the Dell Axim x5 is definitely the better deal.

Comments Disabled

Jeff Atwood of Coding Horror fame has attested to the benefit of comments to blogs. Yet after the loss of his site over a month ago, he still has comments disabled. I've always found his blog posts interesting and often controversial. While conversation of his blog posts can come from other sources such as Reddit, Digg, and Hacker News, the most obvious location for these discussions is on the blog itself.

As a blogger, one of the worse things you can do for you and your readers is to disable comments. Comments turn a lecture into a discussion and no matter how much experience or brains you have, there is always someone else who is knows more then you do. Not only will you and your readers benefit from a discussion but you will get feedback on your writing to make you a better blogger.

But Jeff already knows all this, since he's written about it a few times. For the sake of the readers of his blog, I hope Jeff re-enables comments soon. Jeff his always come across as a conversation starter not a lecturer and he should stay that way.

Pizza

It's Friday, so time for a break from the normal development post. I'll have some new posts starting next week.

Pizza is a topic near and dear to many a developers heats. But finding a good pizza at a great price can be hard. Thankfully, one of the cheaper pizza chains has made a change to their recipe that makes the decision easy. In terms of price and value, Dominoes new pizzas are by far the best deal out there. If you haven't tried their new recipe yet, I encourage you to do so.

If price were not an object. This is the order I world rank the Pepperoni Pizza of several national and regional chains.

• Pizza Hut
• Dominoes
• Papa Johns
• Donato's
• Little Caesar's
• Noble Roman's

Note that I'm a little harsh on Noble Roman's because their sauce does not agree with my stomach. Otherwise, they have good Pizzas.

I'm not a big fan of Peppeoni Pizza. I love Supreme pizza, and comparing this pizza yields different results

Donato's
Papa John's
Pizza Hut
Noble Roman's

I've left out Domino's and Little Ceasar's because I've never had Supreme form these stores.

What do you think of Domino's new Pizza? How would your Pizza rankings differ?

The one thing worse then a bad Source Control system

Source Control is a necessity on any software project of any significant size. Not only does it allow multiple developers to work on the same source at the same time, but it provides a historical record of the code and a backup in case a change needs to be undone later.

Choosing a Source control system for your project is a big deal and should not be done lightly. There is a massive penalty for changing systems. The historic data that is retained within the source code repository often cannot be migrated over to a new system. This means that all of the previous changes can't be backed out if needed down the road. The old source control system can be kept running for a while if needed, but management will eventually ax the server in the next round of cost cutting measures.

For this reason I believe that it is far worse to charge Source Control Systems then it is to continue to use a system that is a poor fit for the development team. One development project I once worked on has used 4 different source control systems in the history of the project, making it truly difficult to track down the history of a particular snippet of code.

I used to never comment where my code changes began or ended and left the majority of the discussion for the code check-in time. But for long lasting code projects, they will out live their original source control system. In this case another way to track changes is necessary even if it is at the expense of the cleanliness of the code.