I work with codebase that has revisions going back over five years. Like dog years, the age of code adds up quickly. A five year old source file is like fifteen in code years. In that amount of time, boat loads of engineers have come and gone, checked in fixes and bugs alike, have left comments, and removed methods. Code has been written and rewritten and refactored and removed in that time span. Third party vendors emerge, merge, and disappear.

The codebase is large, with thousands of class source files and millions of line of code with hundreds of third party resources. No one person alone knows the system inside out, it’s behavior is a mystery to some. To grasp it in your debugger or your mind you need the collective knowledge of the whole team. In such an environment, tests are that much more important. Test become a part of the collective knowledge, an opinionated specification, and essentially another team member, of sorts.

Debugging such legacy source code becomes like code archeology, but instead of finding ceremonial tombs encrusted with jewels you find unceremonious hacks littered with bugs.

After reading thousands of source files, like the matrix, you begin to recognize patterns, fads, and trends, like XML configuration files, to code generation, to dependency injection, to annotations, to configuration over configuration, to new languages, etc.

Along the way, your realize that if code is art, then having Picasso on your software development team would not necessary help keep defect count low.

Technorati Tags: code, softdev, software, development, archeology, programming, rant, art, hack

has a good tech talk on How to Design a Good API and Why it Matters that he does from time to time in the conference circuit. He outline that talk with one liners, he calls them bumper sticker API design. Below are some of my favorite bumper sticker API design advice, if I had a wide enough car.

• All programmers are API designers.
• APIs can be among your greatest assets or liabilities.
• Public APIs, like diamonds, are forever.
• APIs should be easy to use and hard to misuse.
• APIs should be self-documenting.
• Example code should be exemplary.
• You can’t please everyone so aim to displease everyone equally.
• Expect API-design mistakes due to failures of imagination.
• API design is not a solitary activity.
• When in doubt, leave it out.
• Keep APIs free of implementations details.
• Minimize mutability.
• Minimize accessibility.
• Don’t make the client do anything the library could do.
• Obey the principle of least astonishment.
• Use consistent parameter ordering across methods.

Technorati Tags: effective java, software, design, api, bumper sticker, bloch

Here is a recap of the top Ruby-related links for the month of July 2008. Links for The Rubyist are provided by A Rubyist Railstastic Adventure, a tumblelog.

The Good

• Building Rails Applications with Aptana RadRails
• Rails on IntelliJ
• Learn Ruby on Rails From Scratch: Week 1
• JRuby on Rails: Zero to Production in 15 Minutes
• On The App Store
• Rails Behind the Firewall
• What will be Ruby's legacy?
• Passenger Brings Rails Apps to Apache

The Bad

• Ruby developers don't scale
• Funny, some Rubyists are stupider than a piece of wood
• Multiple vulnerabilities in Ruby
• The Trifecta of FAIL; or, how to patch Rails 2.0 for Ruby 1.8.7

The Informative

• Ruby Hoedown 2008 Video
• Ruby at OSCON 2008
• Josh Peek officially joins the Rails core
• Ruby 1.9: What to Expect
• Interview with David Heinemeier Hansson: Rails Culture, Scaling Basecamp, and Building Successful Companies
• Ruby On Rails Creator On The State of eCommerce

The Threadful

• MRI Ruby + MySQL + Threads == Stop the world… JRuby doesn't
• Ruby Fibers Vs Ruby Threads
• Ruby on Rails 2.2 to be Thread Safe
• Q/A: What Thread-safe Rails Means

The Shoes

• Shoes
• Shoes Tutorial

The Miscellaneous

• Rails notes, from the .NET side
• Adhearsion - next killer app for Ruby?
• iPhone Config Utility on Rails, SproutCore Tools in Ruby
• Best Database Best Practices
• Favorite Programming Quotes by Anonymous Code Monkey

Feel free to take a look a back issues of The Rubyist.

Technorati Tags: rubyist, ruby, ror, ruby on rails, rails, shoes, dhh, hoedown, oscon

The Browser War is flaring up once again with the release of Google Chrome. Google Chrome is a new browser based on many freely available open source components such as WebKit and Firefox. Chrome is bare bones, chromeless, browser with very little UI fluff and decoration. It is interesting to note that the UI for the Google browser took a note from the companies colorful logo, the Chrome UI is very cartoon-like with a blue pastel color scheme.

Many of the features that are high lighted in Chrome are not necessarily revolutionary, instead I would say that the Google browser is retro-evolutionary. Chrome basically reduced the browser to the location bar, tabs, and content page.

The most touted features in Chrome are its crash control, incognito mode, and safe browsing. Chrome runs each web page on its own process so that if one page fails only that page is effected. Incognito mode is like Safari’s Private Browsing, aka Porn Mode, it allows you to surf the web without caching cookies and history of the sites you visit on your local computer. It’s safe browsing feature will help you to identify web sites with malicious code or applications. Many of these features are not entirely novel, so why would Google go to the efforts of creating a new browser?

What I think is novel is that Google decided to release yet another browser. The browser space is already crowded with Firefox, IE, Safari, Opera, Konqueror, and Flock to name just a few. It is clear that Google will align Chrome with its properties, search, applications, development tools, and user generated content sites. Seeing Google take this approach I wonder if other companies follow suit and release internet browsers that compliment their business. Can you imagine a custom browser from Adobe, Mcaffee, Oracle, Amazon, or EBay?

Via Noise to Signal

Technorati Tags: google, chrome, firefox, ie, browser, adobe, oracle

Vinh Phat was one of my professors in school. On the first day of lecture, he goes of into his philosophy of learning, a philosophy of life long learning, where the answers he gives are not the answers, but clues, for he says he is more a guide than a teacher. He went on to say…

You memorize the night before and forget the night after.

My job is to understand you, your job is to understand me.

Ask questions. But remember that, if you ask to much, you annoy yourself. If you don’t find the answer, you can drive yourself crazy. Ask yourself, why do I need to ask that question? And learn to be sensitive to the question and the answer. So that is how you learn, memorizing is the stupidest thing on earth.

Technorati Tags: learning, computer, science, programming, memorizing

Here is a pile of quotes and anti-anecdotes relating to software development and programming in general. The quotes where compiled by digging through the mining the rants from Juixe TechKnow. The collection of programming quotes is available as a PDF document and can be found on scribd.

Your code does not start at the compiler nor does it stop at the JVM.

One lesson that most developers don’t learn is to debug outside the debugger. As an engineer there are times when you need to troubleshot, problem solve, and debug not just your software from the comforts of your favorite IDE but the whole software stack, network, hardware, user’s environment, and even the user himself.

You can unit test and statically analysis software, but you can’t probe your users.

Every problem, issue, and bug experienced by the end user directly and indirectly with your software eventually needs to be implicitly and explicitly dealt with by your software development team.

I wish development teams spend more time streamlining their process rather than prematurely optimizing their code.

It is OK to have software with bugs, bugs can be fixed. It is not OK to have software with excuses!

Learn, plan, design, code, integrate, build, release, rinse, and repeat.

Management has a way of over emphasizing the blatantly obvious.

I’m a lazy loading type of programmer.

I’ve discovered that Windows security is an oxymoron!

I know that techies, myself included, are always bragging about how their code is poetry but I have never meet a poet laureate in a development team.

Remixing and mashing up Google Maps and Flickr is like the ‘Hello, World’ first program of Web 2.0 mashups.

Open Source code equals community.

As a rule of thumb, I never cache, pool, or use as singleton mutable objects.

Bugs by nature are out of the box, as a developer, you need to expand the box.

WWGD: What would Google do?

At some companies, the term Spec stands for Speculation.

I went to school to learn how to program software applications, which inevitably have bug defects. There was no course at my university on testing, debugging, profiling, or optimization. These things you have to learn on your own, usually in a tight deadline.

To most Java developers, Ruby/Rails is like a mistress. Ruby/Rails is young, new, and exciting; but eventually we go back to old faithful, dependable, and employable Java with some new tricks and idioms and we are the better programmer for it.

You might as well hire your your customers and pay them 50K/year because they are your new QA.

There is a saying, those who can, do; those who can’t, teach. It can be said that in software engineering, those who can, code, those who can’t, manage.

The greatest thing about Ruby on Rails is neither Ruby nor Rails, the best aspect of Rails is that it questioned the ‘best practices’ (and worst nightmares) of the current state of web development with its philosophy of Convention over Configuration and Don’t Repeat Yourself principle.