I've uploaded <data> support to plist.rb. Special thanks goes to Mat Schaffer, who did the hard work of finding a test case. <data> elements are returned as Tempfiles, and can be replaced with an IO or StringIO:

# reading <data> elements
data = Plist::parse_xml("example.plist");
data['image'].read

# changing <data> elements
bin = File.open("example.jpg"){ |f| f.read }
data['image'] = StringIO.new( bin )
data.save_plist("example_data-v2.plist")

The easiest way to install is to "gem install plist"

Flying over the Atlantic, I wondered about the reliability of the flight progress indicators. It's so hard to integrate software. How did the engineers pass the location of the plane to one critical system (autopilot) and one trivial system (cabin TVs) while ensuring that a short or other problem with the cabin TVs didn't knock out the autopilot. My memory of the East Coast blackout lingers.

My father-in-law is a process engineer and amateaur pilot. After landing, I asked him how the engineers did it. He explained that there most likely is just a second GPS for the cabin TVs. In fact, the electrical system for the cabin is probably completely separate from the avionics. The reward of sharing one component (the GPS) isn't worth managing the additional risk of merging the circuits.

Consider the different areas of a website, and the different divisions of a company. It isn't always worth allowing the marketing department to take risks that affect fulfillment. Especially if the code between business units is straightforward:

def fullname; firstname + ' ' + lastname; end

Having 2 copies of the above code doesn't hurt anyone.

Furthermore, given:

• one web domain is one business
• the one web domain is handled by one web application
• that business employs a full time programmer
• on some regular schedule, that programmer releases code to production
• it is impossible to catch all bugs
  

On some regular schedule, the entire website is at risk. It frightens me -- the entire business as a single (failure prone) application.

On the other hand, if these are given:

• the website is split into 5 web applications
• on some regular schedule one of the web applications is updated

Then only 1/5 of the website is at risk at a release point. Even better from a risk management perspective, given this environment:

• 500 unlinked php/coldfusion/asp scripts

Each update only puts one small fraction of the site at risk. My point is not that the 500 scripts is the optimum solution, but that linking code also links risk.

In my view, linking code is a bet that the benefits will outweigh the risks. There is nothing wrong with taking risks, but sticking to a simple rule like "Don't Repeat Yourself" can obscure the bets being made.

It is worth knowing when you are standing on the shoulders of giants, and when you are standing on thin ice.