Wednesday, July 21, 2010

Week 4 Reading Response

Before touching on this week's "official" reading assignment, I am going to reflect upon a couple less official, yet, no less educational experiences. Some might call them "Choctaws," others might refer to them as rants, still others might call them "Soapbox Specials," however, I choose to label them "Peeblogs." That's right, educational, hysterical life experiences and musings by none other than your very own John Peebles. During this week's near-daily Peeblogs, I learned the following very important principles:

  • It is key in life to have the ability to take that which you learn/hear/read and be able to apply it to, and associate it with, the real-life situations that you find yourself in everyday.
  • The three most important life skills are:
  1. -Writing
  2. -Reading
  3. -Being able to conduct yourself according to the surroundings that you find yourself in, so as to make a good impression and establish good standing. (i.e. People skills in any situation)
  • In order to be great, a man must read no less than one book per week. As a result of this principle, I have begun attempting to teach myself how to speed-read, according to an article on the Internet.
  • Companies' incentive plans, when regulated poorly, can actually end up demotivating their employees. Sir Peebles went on to explain how his friend had quit working for a company because they denied him his $20k bonus, which resulted in the company losing one of its best employees to a staunch competitor. He explained that, in the long run, the company was ruining themselves. He followed this story up with what was by far the best analogy that I heard all week: "You end up plugging a grenade up your ass. Sure, it feels great until it goes off, and then you're screwed."

And now on to this week's official reading assignment, "Continuous Integration," by Martin Fowler. Fowler's article was an outright home run, endorsing and explaining the ins and outs of CI and hitting upon the principle from every angle. Here is a brief synopsis of what I took from the article.


In CI, "everybody develops off of a shared stable base and never gets so far away from that base that it takes very long to integrate back with it. This results in in less time spent trying to find bugs." Every developer keeps and maintains a copy of the current integrated source on his machine. Updating this copy is called "checking out." This copy must stay up to date with the mainline, or, current source code. In short, there is a single source repository maintained by a program such as Subversion, which contains all of the source code for the product/system. When a developer wants to edit some of this code, he makes sure that he has an updated copy of that source code on his own machine and then works with that copy while editing and initially testing. Eventually, after extensive testing, that edited code will be integrated back into the mainline using a continuous integration server such as Cruise Control.

The following are a few important practices in CI:

  • Maintain a single source repository: A mainline with very few branches, which might be necessary for bug fixes and temporary experiments.
  • Automate the build: Everything should be able to be built/linked by issuing one single command.
  • Make the build self-testing: A close runner up to the above-mentioned John Peebles quote: "Imperfect tests, run frequently, are much better than perfect tests that are never written at all."
  • Keep the build fast: Make the build staged: a "commit build" that should quickly test a large amount of the code and a "secondary build" that runs some of the more time-consuming tests. The following is very important in regards to creating an optimally staged build, "As much as possible you want to ensure that any secondary build failure leads to new tests in the commit build that would have caught the bug, so the bug stays fixed in the commit build. This way the commit tests are strengthened whenever something gets past them. There are cases where there's no way to build a fast-running test that exposes the bug, so you may decide to only test for that condition in the secondary build."

Until week five, that is all I have for you. Come back next week for more Peeblogs if you dare.

No comments:

Post a Comment