However, for the open-source project, standardization in the required tools is critical, otherwise new developers would have no way to contribute.

Here’s a good read on various build systems, such as Ant, Maven, and even the newcomer — Buildr.

If you are currently working as a programmer, what kind of a programmer are you? an “80%” or “20%”? If you’re not familiar with these types, you may want to read this or that.

Here’s a snippet from iBanjo:

The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools.

The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. They went to school, learned just enough Java/C#/C++, then got a job writing internal apps for banks, governments, travel firms, law firms, etc. The world usually never sees their software.

In “Implementing Toyota’s Product Development System,”

[Toyota engineers’] overarching goal is to generate a constant flow of new products, so instead of assigning a team to focus on developing one in particular, work is concentrated at the subsystem level. The idea is that subsystems can be mixed and matched to create a whole host of possible new products, fostering creative possibilities.

and…

This approach has definite advantages when a new product reaches the testing stage. If a subsystem proves unworkable, a proven subsystem is always available, which eliminates the need to double back. All knowledge is captured and reused in future projects.

Even acknowledging that something won’t work is good because it identifies a path for engineers to avoid in the future.

Toyota Development System virtually eliminates risk and promotes a myriad of creative possibilities for new products.

This can also be applied to software development, as part of the agile process.

When the CIO of Google, Dr. Douglas Merrill, speaks, you listen…

and my hand slaps my face proving that the hand can still successfully slap the face. If only there were not so many commits kicking off the slap suite.

Dstamat at ELC provides a whirl wind of the many options that have come to existence in Ruby automated test land.

As I started to see my test suite slow down, Mocha to the rescue (FlexMock would have done the job too). My controller tests became focused, and my models were simply mocked and stubbed away from them completely. What if I wanted to test my views ?
Enter Selenium and Watir. Now I could even test to make sure my blind_downs were working when a user clicked on my links from browser X, Y, Z. Half way into setting up Selenium, RSpec hit the scene.

Test::Unit, Mocha, Rspec, RCov, Heckle. Throw ci_reporter in the mix for testing in continous integration (CI) setups such as pulse. Rock and roll for what rails has pulled off in the testing arena and more rock and roll considering the benefits gained by all ruby development.

There are so many amazing tools are available that incubate quality and live in complete automation. The learning curve is there, time to implement is there, but the pay off is huge and shouldn’t be ignored.

The vague and partially relevant point of this post is to illustrate the agile software development (r)evolution that passionate Rubyists have manifested in such a short amount of time. The creation, porting, adaption and adoption of these testing tools / frameworks alone should clearly exemplify this.

It’s an exciting time to be writing software

dstamat, I must agree. I’m completely enthralled.

There’s a NY Times article on Google’s “20% time” that gives engineers time to work on their own projects that they’re interested in, other than working on their day-to-day projects.

Here’s some key points taken from the article:

1. “People work better when they’re involved in something they’re passionate about, and many cool technologies have their origins in 20 percent time.”

2. When people are interested in the same thing, they will self-organize (a pinciple of agile process).

3. “If you have a great technical idea, you don’t have your V.P. send out a memo telling everybody to use it. Instead, you take it to your fellow engineers and convince them that it’s good. Good ideas spread fast, and this approach keeps us from making technical mistakes. But it also means that the burden falls upon you to spread your idea.

4. “When you give engineers the chance to apply their passion to their company, they can do amazing things.”

Another good read from Test Obsessed.

Here’s some key points from the blog entry:

1. “TDD tests are unit and sometimes code-level integration tests. But TDD itself is a development approach rather than a testing approach.”

2. Distinction between developer tests and acceptance or system tests — developer tests are code-facing, and a result of TDD; and acceptance tests are business-facing.
**Note: One of the mistakes that Agile teams tend to make is attempting to substitute unit tests for acceptance tests, or vice versa.

3. Being Agile means delivering a continuous flow of value. To achieve that continuous flow of value, we have to use development practices that provide the visibility and feedback needed to make frequent, incremental changes.

4. “Mary Poppendieck says that speed requires discipline. I extend that to agility in general: if you want your team to be Agile, it must also be disciplined. Agile doesn’t mean “do whatever feels good.”

5. “Many teams have found that embedding XP-like practices within Scrum is an incredibly powerful combination.”

6. “The bottom line: automated testing at all levels can be difficult, but the alternatives are worse. Without automated testing, both code-facing and business-facing, the manual testing burden becomes too large, the team begins incurring technical debt, and velocity slows.”

By the way, here’s another good read that came from one of the comments, testing.

From O’Reilly Radar,

The survival of most projects depend on working software, at least initially, and so if there is money or time many people will spend it on development. Unfortunately, people say they will “figure that ops stuff out soon”, but what they mean is “when we’re totally screwed!!!” It doesn’t have to be that way…

The blog entry mentions Puppet, a system configuration management/server automation tool written 100% in Ruby. We’re using that at work. It’s awesome. :)

Here are some links I gathered from that article on using Puppet:

Puppet, iLike and Infrastructure 2.0
Infrastructure 2.0

I have always been interested in security. Tonight I ran across this post publicizing the white paper on cross-build injection (XBI) vulnerabilities. Some of the listed examples of XBI attacks were OpenSSH, Sendmail and Irssi. If you build software, you definitely want to read this paper and find out the recommendations to mitigate your risk from this kind of attacks.

Holy Cow! 27 Videos from the Google test automation conference 2007 with so much important information that my head is spinning (and I only watched a small portion =). Automation, testing strategies, mocking, continuous integration, UI automation, complex distributed system, and many different levels and types of testing explained. These really drive the importance of quality automated testing in many different forms that really push software and systems from many different angles.

The keynote gives a good overview of overall stratagies and the importance of processes like quick build / test turnarounds and developer testing.

Answer is:

More info.

Via Curious Cat Management Blog,

I see building improvement capacity of the organization, which largely means building the capacity of the people, as an extremely important focus of improvement efforts. As he mentions, it is at times, important to slow down the pace of change to ensure that people can adopt and incorporate the new concepts fully. If not the improvements tend to only take effect on the surface. Improvements in results are important but it is also critical to have management improvement concepts adopted as the natural way of doing business.

I agree with this assessment. :)

Don’t ask for the information you need to do the work; ask the object that has the information to do the work for you.

This article does a good job of verbalizing some of my realizations regarding data flow in OO design. link

Here’s an account on development team size by Jay Fields of ThoughtWorks. Very interesting, indeed.

I still find that smaller teams are more effective when time to market allows a slower pace. However, try not to miss the lessons available from working with a large team if you find yourself on one. Large teams are good for finding language, framework, and developer limitations quickly. Those limitations should be embraced and fixed for everyone’s benefit.

I ran across a post by a MySQL employee on how his company processes bug reports. What’s fascinating is that this company has to deal with the MySQL database bugs but also its various other products. They provide binaries and source code to customers. Imagine the support nightmarish situations varying from wide array of operating systems, custom configurations, compilation. Well, read on if you want to know how MySQl deals with this.

By the way, if you do find a MySQL bug, here’s how to report it.