Posts

Posted on

Refactoring Rules

Tried-and-true refactoring rules:

  1. Find the smallest change that could possibly work, and check it in. “If I make this change, it will change nothing else.”
  2. Revert early, and revert often. If you lose a half-day of work because the refactoring change is too large, that’s okay. Better to start over than to cost the rest of the team precious time struggling with a broken build.
  3. Do not write new code while refactoring.
  4. Always use cut-and-paste, never copy-and-paste.
  5. Just because the unit tests pass, doesn’t mean that the product still works after your refactor. You may need to add new unit tests before you refactor. And you may need to do some acceptance-testing for things that aren’t unit-testable.

General Advice:

  1. Don’t checkin changes to the version control system just before you go home. Wait for the next day.

Types of Refactoring:

  1. Refer to Martin Fowler’s “Refactoring” book
  2. Refer to Fowler’s website: http://www.refactoring.com/ and his catalog of refactorings
Posted on

Advantages of Fedora Core 5 over FC3/FC4

Advantages of Fedora Core 5 over FC3/FC4:

  • Faster boot times
  • Faster Gnome desktop login
  • Faster responsiveness in the Gnome user interface (snappier application menu, etc.)
  • Suspend to disk and suspend to RAM
  • New desktop applications: Beagle desktop search tool, F-spot photo manager, Tomboy note taking application.
  • Firefox: Opening a new window is MUCH faster than with FC4.
  • Most stable installer to date, in my opinion.
  • New HAL integration (hardware abstraction layer) manages USB flash drives, and as a result, they mount on the user’s desktop more quickly than in the past.
  • SELinux targetted policies are much more comprehensive
  • Better wireless NIC support.
  • Xen virtulization.

I find it easier to upgrade rather than reinstall. The upgrade process did not install the new applications that a fresh install would have provided. Therefore, I did a fresh install of FC5 on one machine, and grabbed the package list (FC5 Packages). Then, I upgraded another machine, grabbed the package list ("rpm -qa | sort > upgradepackages.txt“). I generated a ‘diff’ of the two files. Here are the main things I came up with when going from FC4 to FC5:

Missing desktop packages:

  • beagle
  • f-spot
  • frysk
  • tomboy
  • gnome-backgrounds
  • gnome-power-manager
  • gnome-screensaver
  • gnome-user-share
  • nautilus-sendto
  • hal-gnome

Missing non-desktop packages:

  • xorg-x11-fonts-truetype
  • smartmontools
  • systemtap
  • hplip
  • longrun
  • irqbalance
  • glx-utils
  • gmime
  • gmime-sharp
  • dbus-sharp
  • dcraw
  • evolution-sharp

It’s always a good idea to read the release notes:
http://fedora.redhat.com/docs/release-notes/fc5/
Install extra software using yum, or using the graphical application ‘pirut’, or view ‘extra’ packages with your browser:
http://fedoraproject.org/extras/5/i386/repodata/repoview/graphical-internet.group.html
Useful packages (from extras repository):

yum install yum-utils gtweakui themes-backgrounds-gnome nautilus-open-terminal nautilus-image-converter nautilus-actions

Posted on

Is open source software sustainable?

Recently, a genuinely concerned coworker expressed concern that “not paying for software [may] ultimately kill the industry” because it encourages people expect something for nothing.

For those who would like this and other common concerns about open software answered, I recommend reading Open Source-onomics. Here’s a list of concerns it addresses:

  • “Open Source is not economically viable”
  • “Not paying for software will ultimately kill the industry”
  • “Why will programmers continue to contribute code if they can’t make money from it?”
  • “Even Open Source development involves effort, so there has to be payment for that effort”
  • “Are Open Source programmers writing themselves out of their jobs?”
  • “But free isn’t natural. There’s no such thing as a free lunch.”
  • “Is software a commodity?”
  • “Who will invest in software development if it doesn’t yield a return?”
  • “Open Source may have a niche, but proprietary commercial products will continue to rule”
  • “Customers will never trust something that is free”
  • “Open Source may release value, but it doesn’t create value”

For those who would like even more detailed reading, I recommend David Wheeler’s “Why Open Source Software? Look at the numbers!“

Posted on

Utah’s Diebold voting machines

We don’t need computers to enable voting in our republic. Technology can serve us, or we can be slaves to technology. In the case of electronic voting, the technology does not serve us sufficiently well to compensate for the risk and expense that it introduces. We are better off manually counting votes, with witnesses to verify.

Nearly three years ago, I voiced concern about the security of up-and-coming electronic voting systems in my home state, Utah. My colleagues and I wrote a letter to the editor of my local newspaper, and I spoke with the Utah County Commissioner. At the time, the commissioner told me that they wouldn’t buy Diebold machines, due to security concerns they’d heard about from other states.

Apparently, security concerns aren’t of concern — “All 29 counties [in the state of Utah] signed a contract saying they would use the Diebold machines,” said Michael Cragun, director of the State Elections Office. Officials “are aware of the problems, but Diebold is addressing it.” Excuse my skepticism, but I’ve heard that one before. Diebold will not address the problems until their feet are held to the fire. The only way we will get secure electronic voting is to 1. require full vendor responsibility for flaws, 2. have the systems openly peer reviewed for security flaws or bugs by experts, and 3. electronic election results must be audited. However, we don’t need electronic voting. The current, manual procedures aren’t broken.

Deseret News Article: http://deseretnews.com/dn/view2/1,4382,635194578,00.html

Questions we should be asking of e-voting vendors: http://avirubin.com/vote/questions.html

Posted on

Refactoring C++ with Ref++

IntelliJ IDEA has world-class refactoring support for Java. I’ve never seen a good tool for refactoring C++ code, until now: Ref++ for Visual Studio 2003 and 2005. Admittedly, it isn’t nearly as good as the refactoring tools available for Java code, but it’s a start, and Ref++ saves time.

Posted on

Fedora Core 5

I’ve been using RedHat/Fedora distributions of Linux since 1995. I typically keep my home machines running a fairly recent release. I find that it’s easier to upgrade if I don’t procrastinate through too many releases.

On the other hand, I’ve found that upgrading too soon can be risky. I depend on third party repositories for some of the software that I use (e.g. an ntfs driver). It takes between two to four weeks before the software repositories start offering their packages for a new distribution.

If I wait at least a few weeks to upgrade, after the release of the new distribution, and I run into problems, I can usually google to find a solution to the problem. If I’m on the bleeding edge, I don’t get that benefit. Instead, I’m the one posting problems and solutions that other people google.

On Monday, I downloaded the recently released Fedora Core 5 DVD via bittorrent, and decided to upgrade my less-critical Fedora Core 3 machine.

Backup. Even though I’m generally careful, I find that it’s easier to recover from a mistake if I have a complete backup. For this, I used Norton Ghost.

First try: I was impressed by the shiny new graphics in the installer. After several screens of questions and after it analyzed my system to figure out what packages to upgrade, it informed me that I didn’t have enough disk space (I only had 2 Gig of free space). The install aborted and I had to reboot my machine.

Yum cache: I use yum to upgrade my machines, and I happen to know that by default, it leaves a cache of the packages in the /var/cache/yum directory. I deleted the directory, which freed up 2 Gig of space. Shouldn’t the installer do that for me?

Second try: The installer ran without a hitch. It upgraded my system, even though it took a while.

First boot: The boot process hung when it tried to initialize OpenCT smart card terminals, whatever those are. I don’t think I have any. Back in the days when Iinstalled FC3, I had to add “acpi=off” and “pci=noacpi” to the boot loader before FC3 would work on my system. The FC5 upgrade had left those options in place. I deleted the options, and rebooted. This time, the boot process didn’t hang. Wierd. There may not have been a correlation.

First login: The GNOME desktop loaded much more quickly than with FC3. However, several error dialogs appeared. Various resources couldn’t be located, including icons for desktop launchers that I had customized. As I already mentioned, the third party repositories that I use with yum didn’t have FC5 packages available.

Upgrade versus Fresh Install: I find that upgrades are less than ideal, especially when I want to experience the new features of a distribution. Upgrades tend to leave out new features and new packages. Since RedHat has been changing SELinux policices at a rapid rate, an upgrade isn’t likely to leave SELinux in a workable state. A fresh install is better. For a home, desktop system that isn’t a server, it’s probably best to disable SELinux. It will be interesting to see how SELinux fares compared to the now open-source AppArmor that is included with SUSE. AppArmor appears to be easer to use and configure, but SELinux has fewer gaps in security coverage. I tend to think that ease-of-use will win out. In any case, I do use SELinux to protect one of my web servers.