Categories
personal

Anaheim, California, 2006

More personal photos from our 2006 trip to Disneyland, California Adventures, and Downtown Disney.

Categories
personal

Rosarito, Mexico, 2006

Here‘re some favorite pictures from the trip, for those who haven’t seen them already 🙂

Categories
computer

Must-Have OS X Freebies

As far as I’m concerned, no Mac is complete without these great freebies..

Cyberduck
Great SFTP/FTP rich-client.

Colloquy
An intuitive, native IRC client

VLC
Dirt simple media player capable of handling things that QuickTime can’t.

Handbrake
All-in-one DVD ripping and encoding utility. Provides plenty of features for most of us without be overly complicated.

Skype
Easy-to-use VOIP client. Works with MacBook (Pro)/PowerBook microphones out-of-the-box, and provide free calls to other Skype users.

CrossOver Mac Beta
Every OS X user I know must operate in a Windows environment on a regular basis. The recent release of Parallels for Intel-based macs (basically VMWare workstation-style guest-OS host virtualization) has made life one tick easier by allowing us to run Windows on our Core Duo systems, and the new CrossOver Beta for Intel Macs provides a great complementary technology. CrossOver Mac, by CodeWeavers of wine fame, allows you to run some Windows applications directly on your Intel Mac, without having to host a full-fledged copy of Windows by implementing the applications APIs dependencies on the Mac. The beta is free.

QuickSilver
Provides Spotlight-like capabilities, but faster and way, way better. The extremely brisk find-and-launch concept will be new for many users, but will be hard to live without once understood.

Categories
computer

Network De-Perimeterization: The Jericho Forum

The presenters from the Jericho Forum at DEFCON 14 this year did an acceptable job of highlighting the principle that border firewalls are much less beneficial that they used to be for security purposes. WiFi, VPNs, MANETs etc. provide constantly changing IT environments which are not realistically plausible for IT to completely control. Our new challenge is to accept that hostile things may exist on the network, and we must solidify the security of individual services despite high-priced blue-colored networking hardware connecting it all. Their DEFCON session was unfortunately unclear on the specifics of how one accomplishes this, but I nevertheless agree with many of their core principles.

This Decades Security Challege (good .pdf slides)
De-perimeterization is the way to go for network security
De-perimeterization: Jericho Forum misses the mark

Categories
computer

Encryption: Use it, lest ye be thieved.

Each time I go to DEFCON, sniff a network or see an ad for an infosec product, I’m harshly reawakened to the general publics detachment for security concerns. When using a virus scanner, firewall and pop-up blocker, most users seem comforted enough to go about daily business with a satisfactory feeling of a “secure” experience.

A large gap with this frame of thought is of what we’re trying to secure. The most valuable thing on your computer—the stuff you want to secure if nothing else–is your personal data/information, NOT the machine itself. Most white-collar folk, in a worst-case scenario, could cough up the bones to cope with a stolen or broken machine, or re-install the OS after a bad virus attack. The data on that machine, however, may be priceless memories, confidential trade-secrets, or other information which you’d highly prefer to remain private and well backed up. As a resident of Arizona–the new U.S. capital for identity theft (per-capita)–we must recognize that the Bad Guys on the tubes do not have the primary intent to annoy us. They’re trying to make money. Compromising your system is merely a means for collecting sellable usage habits, relaying \/i@gr@ ads, stealing/selling your identity etc. We simply need to recognize that we protect system assets largely to protect our information.

In that vein, one of the largest commonplace no-nos is sending sensitive information over ordinary email. We’ve all done it, and most will continue. Emails can pass through systems that are maintained by people you don’t know and most certainly don’t trust, so don’t be a bonehead: encrypt your email, especially if it’s sensitive material. (If your email client is a horrible bitch-goddess that makes encryption a pain to deal with, please poke the vendor with a sharp stick until they make it trivial.) Mail.app and Keychain Access.app (OS X) make it ridiculously simply to manage and use X.509 public/private keys, which you can obtain for free from Thawte. If you use Mail.app, you’re out of excuses.

Should your machine be stolen, sold, repaired, or otherwise leave your possession, how do you know your not handing over the keys to the kingdom to a complete stranger? You can wipe the drive, but that isn’t convenient if the machine will be returned to you. A simply way is to use TrueCrypt for Windows, encrypted .dmg files for OS X, or encrypt your entire freaking home directory with FileVault. (OS X).

OS X users have no excuse but to encrypt everything. Linux and Windows users may have difficulties, but easy wins are still possible. Encrypt your email. Encrypt your backups. Encrypt your calendar. Encrypt your address book. Encrypt your financials. Encrypt your music. Encrypt your photos. Encrypt your life.

Encrypt everything.

Categories
computer

Singletons Cause Cancer

It’s been said before. I’ll say it again. The singleton pattern sucks. From a pragmatic point of view, it has two primary drawbacks: reuse and testability.

Reuse

A public static getInstance() method is, by definition, statically bound at compile time. Since you can’t override static methods, reusing singleton code via inheritance means you’ll need to create a new getInstance2() method. No matter how creative you get with this method name, you have to accept that users of your code will periodically call the parent types public getInstance() method instead of your spiffy new getInstance2(). Working off an interface largely becomes a moot point since the developer must know the exact type of singleton they want to use at compile time in order to invoke the correct getInstance() method.

How do you configure a singleton without a parameter to getInstance(), which would not be consistent with the intentions of the pattern? Since the instance is constructed internally using a non-publically-accessible constructor, there isn’t a convenient way of introducing configuration information before it’s created.. unless the singleton is aware of a configuration source at compile time with yet more static binding. This makes the code very inflexible, as developers intending to reuse it will be at the mercy of your pre-chosen configuration mechanism, which may not be appropriate for their circumstances, or even unit testing.

Testability

Unit tests generally require control over the lifecycle of the class under test to fully validate proper state transition and contractual validity. Since you, the master of the known universe, are writing the software, you’ll certainly write negative scenarios into your unit tests to assert proper failure handling. If intentionally introducing a negative test results in an irrecoverable state, how do you throw out the singleton and start the next case with a new one? You can’t. What if your test case is creating a tricky concurrency scenario emulating multiple systems within the sandbox of a single JVM? You can’t (trivially). What happens when you discover you need multiple instances of the singleton within your application? You can’t. Time to refactor.

Additionally, unit testing of code using static singleton dependencies has a high potential of awkwardness due to an inability to swap out implementations for mock objects. Under the principle of designing for testability, quality and maintainability, hackishness is not a quality to aspire to.

Conclusion

Singletons can be hazardous to your health, seriously jeopardize your family’s safety, and have been classified as ‘terrorist patterns’ by the U.S. government. The fact that an application only needs one instance of something does not mean the object should be designed that way, and there aren’t very many scenarios where singletons are appropriate. Do as the Jedi do and use them with consideration and responsibly.

Categories
personal

Back From Baja

We’ve just returned from our getaway to Baja and California. Brief, self-explanitory electrocolorogram highlights here.

Categories
computer

On Brooks

I’ve written this same basic argument for small teams three or four times now, so to comply with the Don’t Repeat Yourself (DRY) principle I though I’d post it. In short, this argument repeats Brooks’ Mythical Man-Month concept 🙂 , and asserts that you must restructure the communications dynamics of a team when it changes in size, regardless of whether or not your project is late.

To paraphrase one of the points made in Frederick Brooks’ The Mythical Man Month, complexity in a system scales with the number of interfaces. Applied to a team communications system of N people, the worst-case number of total communications channels is when everybody talks to everybody else. This can be expressed by N(N-1)/2. In other words, a given person in the team (the Nth person) is communicating with everyone else (N-1 people).

A problem with large horizontal teams is that as N increases, the communications overhead of being able to operate potentially increases exponentially. As a member of a 5 person team, for example, communicating with 4 others is not a big deal. You are able to mentally understand what other people are doing and how others communicate with each other (in all 10 different relationships). If this team grows to 15 people, however, communicating is not as simple. In the worst case, not only do you have to communicate with 14 other peers, there are now 105 relationships between people you may have to be aware of to stay “in the loop”. The worst part may be that the majority of the information going across those channels may be directly irrelevant to you job, but since it’s relevant to the team as a whole, you spend the time and mental cycles to process it.

Now, this is all worst-case abstract theory, but it does highlight the scaling problems of communication in teams of changing size. As your team changes, you need to reevaluate the way it works to keep operating overhead due to excess or insufficient communication down to a minimum.

Categories
computer

Avoiding if(DEBUG_ON)

Consider the following Java code..

public class Counter {

	private final static boolean DEBUG_ON = false;

	protected int mCount = 0;

	public int getCount() {
		return mCount;
	}

	public void increment() {
		if(DEBUG_ON) {
			System.out.println(“about to increment! count=” + getCount());
		}
		mCount++;
	}
}

}

Some people use “debug” or “test” flags because they can provide a fast way of troubleshooting situations that would otherwise be inconvenient to debug. If increment() was recursive, for example, it may be convenient to simply keep an eye on stdout rather than set breakpoints and have to step through it. (Note: see an earlier post on conditional breakpoints to avoid this entirely.)

While the extra DEBUG_ON code is fairly harmless and benign, it’s nevertheless unnecessary code that could potentially break a production system, and even when/if you do remember to comment it out, it distracts the reader from the meaningful, real code you’re trying to express.

An alternative solution? Simple. Subclass it. Try this instead..

public class Counter {

	protected int mCount = 0;

	public int getCount() {
		return mCount;
	}

	public void increment() {
		System.out.println(“about to increment! count=” + getCount());
		mCount++;
	}

}

public class TestCounter extends Counter{

	public void increment() {
		System.out.println(“about to increment! count=” + getCount());
		super.increment();
	}
}

Now you can leave your print statements intact, and just use TestCounter as a drop-in replacement for Counter in your unit tests. Alternatively, you could use one of many design patterns to aggregate or compose the Counter rather than extend it, or use dynamic proxies or aspects if you’re looking to intercept calls that exist in a horizontal manner.

Categories
Uncategorized

Zen And The Art of Software Design

Japanese Tea Garden
As you sit on a bench with a hot cup of jasmine tea in the middle of the Japanese Tea Garden in San Francisco Park, you can’t help but be overwhelmed by the tranquil beauty of the garden that surrounds you from every direction. It’s a great way to spend an afternoon. I arrived at the garden expecting a wonderfully uncomplicated demonstration of Zen-like simplicity in design after seeing some very provocative pictures of Japanese Zen Gardens online. In this respect, I left disappointed.

The garden is brilliantly beautiful, but its beauty is achieved by bombardment of the exotic, rather than elegant simplicity. In the attached photo, for example, the frame almost bursts at the boarders with colors and plants. Very pretty, but is all that really necessary? Does each plant in the photo really serve a purpose that would be unfulfilled in its absense? Would the garden be any less beautiful with half as many plants? The tree from the Six Feet Under opening sequence is plenty inspiring on its own, even though it’s the only thing in the frame.

I liken the gardens design to the conception of many software systems, particularly many F/OSS projects. Doing less, well, seems to often go undervalued in an attempt to appeal to a wider audience and satisfy all the I-would-use-it-only-ifs presented by the potential userbase. Take this screenshot from easytag, for example. Does this look easy to you? To me this looks like an ugly, unusable piece of shit. Granted, the software appears powerful in that it allows you to customize your process to a very fine level of detail, but wait.. isn’t this software supposed to be easy to use?

To me this functionality is an example of a speculative generality code smell, combined with a very developer-oriented project culture the equates more features to better software. The vast majority of the important cases trying to be achieved here could probably be accomplished without trying to allow for every single possible permutation of tags that is mathematically possible (at least in the user interface).

Less: It’s the new more.