<?xml version="1.0" encoding="UTF-8"?>
<!-- generator="wordpress/2.3.2" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>

<channel>
	<title>Vincent Gable</title>
	<link>http://vgable.com/blog</link>
	<description>my weblog.</description>
	<pubDate>Sun, 06 Jul 2008 01:14:31 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.2</generator>
	<language>en</language>
			<item>
		<title>FourCharCode2NSString</title>
		<link>http://vgable.com/blog/2008/07/05/fourcharcode2nsstring/</link>
		<comments>http://vgable.com/blog/2008/07/05/fourcharcode2nsstring/#comments</comments>
		<pubDate>Sun, 06 Jul 2008 01:13:51 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
		
		<category><![CDATA[MacOSX]]></category>

		<category><![CDATA[Objective-C]]></category>

		<category><![CDATA[Programming]]></category>

		<category><![CDATA[Sample Code]]></category>

		<category><![CDATA[Usability]]></category>

		<category><![CDATA[Debugging]]></category>

		<category><![CDATA[FourCharCode]]></category>

		<category><![CDATA[macros]]></category>

		<category><![CDATA[NSString]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/2008/07/05/fourcharcode2nsstring/</guid>
		<description><![CDATA[As I have written before, the best way to convert a FourCharCode to an NSString* for NSLog()ing is to use the NSFileTypeForHFSTypeCode() function.  But for the life of me I can&#8217;t remember that name, even though I use it about once a month.  It&#8217;s too long, and it has too little to do [...]]]></description>
			<content:encoded><![CDATA[<p>As I have <a href="http://vgable.com/blog/2008/04/23/printing-a-fourcharcode/">written before</a>, the best way to convert a <code>FourCharCode</code> to an <code>NSString*</code> for <code>NSLog()</code>ing is to use the <code>NSFileTypeForHFSTypeCode()</code> function.  <strong>But for the life of me I can&#8217;t remember that name</strong>, even though I use it about once a month.  It&#8217;s too long, and it has too little to do with what I&#8217;m using it for.</p>
<p>So I have added the line:<br />
<code>#define FourCharCode2NSString(err)	NSFileTypeForHFSTypeCode(err)</code><br />
To my prefix-files, because I <em>can</em> remember <code>FourCharCode2NSString()</code>.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2008/07/05/fourcharcode2nsstring/feed/</wfw:commentRss>
		</item>
		<item>
		<title>-dealloc Warning</title>
		<link>http://vgable.com/blog/2008/07/05/dealloc-warning/</link>
		<comments>http://vgable.com/blog/2008/07/05/dealloc-warning/#comments</comments>
		<pubDate>Sun, 06 Jul 2008 01:06:27 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
		
		<category><![CDATA[Bug Bite]]></category>

		<category><![CDATA[Cocoa]]></category>

		<category><![CDATA[MacOSX]]></category>

		<category><![CDATA[Objective-C]]></category>

		<category><![CDATA[Programming]]></category>

		<category><![CDATA[GCC]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/2008/07/05/dealloc-warning/</guid>
		<description><![CDATA[The only time you should call ever call -dealloc in Objective-C is on the last line of your own -dealloc method.  This call should be [super dealloc];.  The proper way to dispose of an object is to send it a -release message &#8212; -dealloc will then be called if appropriate.
Now when I was [...]]]></description>
			<content:encoded><![CDATA[<p>The <strong>only</strong> time you should call ever call <code><a href="http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSObject_Class/Reference/Reference.html#//apple_ref/occ/instm/NSObject/dealloc">-dealloc</a></code> in Objective-C is on the last line of your own <code>-dealloc</code> method.  This call should be <code>[super dealloc];</code>.  The proper way to dispose of an object is to send it a <code>-release</code> message &#8212; <code>-dealloc</code> will then be called <em>if appropriate</em>.</p>
<p>Now when I was first learning Cocoa, I sometimes disposed of objects by calling <code>-dealloc</code> directly.  This caused all sorts of problems.     Truth be known, if I&#8217;ve been messing with several object&#8217;s <code>-dealloc</code> methods, I&#8217;ll sometimes dyslex out and type <code>dealloc</code> when I mean <code>release</code>, just because it&#8217;s more fresh in my head.  This is very rare, but it has happened once, and will happen again.  I&#8217;m fallible like that.  Murphy&#8217;s law tells us that I won&#8217;t catch it every time.</p>
<p>So I humbly propose that <strong>GCC should warn you if you use <code>-dealloc</code> any way other then calling <code>[super dealloc];</code> on the last line of your own <code>-dealloc</code> methods</strong>.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2008/07/05/dealloc-warning/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Missing Frameworks</title>
		<link>http://vgable.com/blog/2008/07/05/missing-frameworks/</link>
		<comments>http://vgable.com/blog/2008/07/05/missing-frameworks/#comments</comments>
		<pubDate>Sat, 05 Jul 2008 06:20:55 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
		
		<category><![CDATA[Bug Bite]]></category>

		<category><![CDATA[Cocoa]]></category>

		<category><![CDATA[MacOSX]]></category>

		<category><![CDATA[Objective-C]]></category>

		<category><![CDATA[Programming]]></category>

		<category><![CDATA[AMWorkflowView]]></category>

		<category><![CDATA[automator]]></category>

		<category><![CDATA[OSAScriptView]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/2008/07/05/missing-frameworks/</guid>
		<description><![CDATA[I tried using an AMWorkflowView in a project, but when I ran it, I would crash with the following printed to the console:

*** Terminating app due to uncaught exception &#8216;NSInvalidUnarchiveOperationException&#8217;, reason: &#8216;*** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class (AMWorkflowView)&#8217;

It turns out I just forgot to include Automator.framework in my project!
It turns out that you [...]]]></description>
			<content:encoded><![CDATA[<p>I tried using an <a href="http://developer.apple.com/documentation/AppleApplications/Reference/AMWorkflowView_Class/Reference/Introduction.html"><code>AMWorkflowView</code></a> in a project, but when I ran it, I would crash with the following printed to the console:</p>
<p><strong><br />
*** Terminating app due to uncaught exception &#8216;NSInvalidUnarchiveOperationException&#8217;, reason: &#8216;*** -[NSKeyedUnarchiver decodeObjectForKey:]: cannot decode object of class (AMWorkflowView)&#8217;<br />
</strong></p>
<p>It turns out I just forgot to include Automator.framework in my project!</p>
<p>It turns out that you also have to include Automator.framework to use any <code>OSAScriptView</code> objects.</p>
<p>I hope this helps someone who googles the error message :-).</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2008/07/05/missing-frameworks/feed/</wfw:commentRss>
		</item>
		<item>
		<title>NP-Complete is Often Easy</title>
		<link>http://vgable.com/blog/2008/07/03/np-complete-is-often-easy/</link>
		<comments>http://vgable.com/blog/2008/07/03/np-complete-is-often-easy/#comments</comments>
		<pubDate>Fri, 04 Jul 2008 00:55:13 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
		
		<category><![CDATA[Design]]></category>

		<category><![CDATA[Programming]]></category>

		<category><![CDATA[Quotes]]></category>

		<category><![CDATA[Complexity]]></category>

		<category><![CDATA[Haskell]]></category>

		<category><![CDATA[NP-Complete]]></category>

		<category><![CDATA[NP-Hard]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/2008/07/03/np-complete-is-often-easy/</guid>
		<description><![CDATA[ There are a lot of problems that are, in theory, incredibly difficult - but because the difficult cases are very rare and rather contrived, they&#8217;re actually very easy to solve. Two examples of this that I find particularly interesting are both NP complete. Type checking in Haskell is one of them: in fact, the [...]]]></description>
			<content:encoded><![CDATA[<blockquote><p> There are a lot of problems that are, in theory, incredibly difficult - but because the difficult cases are very rare and rather contrived, they&#8217;re actually very easy to solve. Two examples of this that I find particularly interesting are both NP complete. Type checking in Haskell is one of them: in fact, the general type inference in Haskell is worse that NP complete: the type validation is NP-complete; type inference is NP-hard. But on real code, it&#8217;s effectively approximately linear. The other one is a logic problem called 3-SAT. I once attended a great talk by a guy named Daniel Jackson, talking about a formal specification language he&#8217;d designed called Alloy. Alloy reduces its specification checking to 3-SAT. Dan explained this saying: &#8220;The bad news is, analyzing Alloy specifications is 3-SAT, so it&#8217;s exponential and NP-complete. But the good news is that analyzing Alloy specifications is 3-SAT, so we can solve it really quickly</p></blockquote>
<p>&#8211;<a href="http://scienceblogs.com/goodmath/2008/05/linear_programming.php">Mark Chu-Carroll (aka MarkCC</a></p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2008/07/03/np-complete-is-often-easy/feed/</wfw:commentRss>
		</item>
		<item>
		<title>NSApplicationName Inconsistencies</title>
		<link>http://vgable.com/blog/2008/07/03/nsapplicationname-inconsistencies/</link>
		<comments>http://vgable.com/blog/2008/07/03/nsapplicationname-inconsistencies/#comments</comments>
		<pubDate>Fri, 04 Jul 2008 00:06:18 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
		
		<category><![CDATA[Bug Bite]]></category>

		<category><![CDATA[Cocoa]]></category>

		<category><![CDATA[MacOSX]]></category>

		<category><![CDATA[Objective-C]]></category>

		<category><![CDATA[Programming]]></category>

		<category><![CDATA[Sample Code]]></category>

		<category><![CDATA[NSApplicationName]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/2008/07/03/nsapplicationname-inconsistencies/</guid>
		<description><![CDATA[The value stored under the NSApplicationName key of the result of [[NSWorkspace sharedWorkspace] activeApplication] is not the always the name the user knows the application by.  Worse, it&#8217;s not always the same as the name for the application that other APIs expect or return.  Even fullPathForApplication: in NSWorkspace sometimes won&#8217;t recognize it!

The problem [...]]]></description>
			<content:encoded><![CDATA[<p>The value stored under the <code>NSApplicationName</code> key of the result of <a href="http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWorkspace_Class/Reference/Reference.html#//apple_ref/occ/instm/NSWorkspace/activeApplication"><code>[[NSWorkspace sharedWorkspace] activeApplication]</code></a> is not the always the name the user knows the application by.  Worse, it&#8217;s not always the same as the name for the application that other APIs expect or return.  Even <code>fullPathForApplication:</code> in NSWorkspace sometimes won&#8217;t recognize it!</p>
<blockquote><p>
The problem stems from the fact that there are at least five application names floating around, at least in concept: (1) the file name the Finder sees, which in the case of an application package is the package (bundle) name; (2) the name of the executable inside the package, (3) the long name used in many places for display purposes only; (4) the short name used as the application menu title and in a few other places where a long name won&#8217;t fit for display purposes; and (5) the process name of a running application. They aren&#8217;t always the same, especially in Microsoft and Adobe products.
</p></blockquote>
<p>&#8211;From <a href="http://www.cocoabuilder.com/archive/message/cocoa/2003/8/24/2349">an informative message</a> by <a href="http://www.quecheesoftware.com/">Bill Cheeseman</a>.</p>
<p>So instead of relying on <code>NSApplicationName</code> I now use <code> <a href="http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Classes/NSFileManager_Class/Reference/Reference.html#//apple_ref/occ/instm/NSFileManager/displayNameAtPath:">-[[NSFileManager defaultManager] displayNameAtPath:]</a></code>  then strip off the filename extension.  This should give exactly the filename the user sees.  Every time.</p>
<p><code><br />
NSDictionary *appInfo = [[NSWorkspace sharedWorkspace] activeApplication];<br />
NSString *appPath = [appInfo objectForKey:@&#8221;NSApplicationPath&#8221;];<br />
NSString     *name = [[[NSFileManager defaultManager] displayNameAtPath:appPath] stringByDeletingPathExtension];</code></p>
<p><strong><a href="http://developer.apple.com/documentation/CoreFoundation/Conceptual/CFBundles/Tasks/locating.html#//apple_ref/doc/uid/20001123-123081">And of course, you really should be using bundle identifiers, instead of names, to identify an application.</a></strong>  Unfortunately, a <em>very few</em> applications are not bundles.  (For example, Microsoft stuff prior to Office 2008), so it <em>might</em> be necessary to fall back on using a name to locate them in a path-independent way.</p>
<p>Creating a custom <code>CFBundleName</code> in an application&#8217;s <code>info.plist</code> file seems to confuse <code>NSApplicationName</code>.  For this reason I don&#8217;t think setting it is a good idea.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2008/07/03/nsapplicationname-inconsistencies/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Learning From Other People&#8217;s Failures: Acrobat Reader 9</title>
		<link>http://vgable.com/blog/2008/07/03/learning-from-other-peoples-failures-acrobat-reader-9/</link>
		<comments>http://vgable.com/blog/2008/07/03/learning-from-other-peoples-failures-acrobat-reader-9/#comments</comments>
		<pubDate>Thu, 03 Jul 2008 22:58:01 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
		
		<category><![CDATA[MacOSX]]></category>

		<category><![CDATA[Usability]]></category>

		<category><![CDATA[Adobie]]></category>

		<category><![CDATA[failure]]></category>

		<category><![CDATA[Installers]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/2008/07/03/learning-from-other-peoples-failures-acrobat-reader-9/</guid>
		<description><![CDATA[Epic Fail.
The PC version is awful too.
]]></description>
			<content:encoded><![CDATA[<p><a href="http://gusmueller.com/blog/archives/2008/07/adobe_reader_9_is_out!.html">Epic Fail.</a></p>
<p><a href="http://blog.micropledge.com/2008/07/adobe-reader-9/">The PC version is awful too.</a></p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2008/07/03/learning-from-other-peoples-failures-acrobat-reader-9/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Unfriends</title>
		<link>http://vgable.com/blog/2008/07/03/unfriends/</link>
		<comments>http://vgable.com/blog/2008/07/03/unfriends/#comments</comments>
		<pubDate>Thu, 03 Jul 2008 22:55:06 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
		
		<category><![CDATA[Design]]></category>

		<category><![CDATA[Quotes]]></category>

		<category><![CDATA[facebook]]></category>

		<category><![CDATA[security]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/2008/07/03/unfriends/</guid>
		<description><![CDATA[Facebook&#8217;s &#8220;People You May Know&#8221; feature shows you a few links to profiles of people you &#8230; well, may know.  Put another way it&#8217;s a feature that
shows you people that all your friends know who you are not friends with.  There aren&#8217;t pleasant names for these kinds of people.
Facebook is a spiteful conniving [...]]]></description>
			<content:encoded><![CDATA[<p><a href="http://facebook.com">Facebook</a>&#8217;s &#8220;People You May Know&#8221; feature shows you a few links to profiles of people you &#8230; well, may know.  Put another way it&#8217;s a feature that<br />
<em>shows you people that all your friends know who you are not friends with</em>.  There aren&#8217;t pleasant names for these kinds of people.</p>
<blockquote><p><strong>Facebook is a spiteful conniving bitch<br />
</strong><br />
It continues to put my ex in the &#8220;people you may know&#8221; section.<br />
You fuckin&#8217; dirty backstabbing whore, facebook, I&#8217;ll kill you. Just keep rubbing that shit in, I&#8217;ll fucking kill you.</p></blockquote>
<p>&#8211;<a href="http://theprpboard.com/showthread.php?p=8410">some bitter guy</a>.</p>
<p>Applying the  <a href="http://www.schneier.com/blog/archives/2008/03/the_security_mi_1.html">&#8216;The Security Mindset&#8217;</a> can keep you from implementing a similar feature.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2008/07/03/unfriends/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Auto Dial</title>
		<link>http://vgable.com/blog/2008/06/28/auto-dial/</link>
		<comments>http://vgable.com/blog/2008/06/28/auto-dial/#comments</comments>
		<pubDate>Sat, 28 Jun 2008 20:59:06 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
		
		<category><![CDATA[Research]]></category>

		<category><![CDATA[Usability]]></category>

		<category><![CDATA[failure]]></category>

		<category><![CDATA[phones]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/2008/06/28/auto-dial/</guid>
		<description><![CDATA[Today, most people I see making phone calls use cellphones. As near as I can tell, every time they call someone they know, they do it using their phone&#8217;s address book, instead of keying in their a ten-digit &#8220;telephone number&#8221;.  It&#8217;s pretty obvious why.  Nobody wants to have to memorize ten-digit numbers.  [...]]]></description>
			<content:encoded><![CDATA[<p>Today, most people I see making phone calls use cellphones. As near as I can tell, <em>every time</em> they call someone they know, they do it using their phone&#8217;s address book, instead of keying in their a ten-digit &#8220;telephone number&#8221;.  It&#8217;s pretty obvious why.  Nobody wants to have to memorize ten-digit numbers.  And we think of people by their name, not some number.</p>
<p>This was not something that was hard to predict.  <a href="http://en.wikipedia.org/wiki/Rolodex">Rolodexes</a> have been in every office for decades, because people want to look up people by name, not number.  Only recently has software supplanted them.</p>
<p>I was very surprised when I found <a href="http://blog.modernmechanix.com/2008/06/03/directory-dials-the-phone/">this unknown invention from the late 1930&#8217;s</a></p>
<blockquote><p>
<a href="http://blog.modernmechanix.com/mags/PopularScience/1-1947/directory_phone.jpg"><img src="http://vgable.com/blog/wp-content/uploads/2008/06/autodial.png" alt="autodial.png" border="0" width="320" height="230" /></a><br />
A NEW desk telephone directory not only finds the number you want but actually dials it for you.<strong> All you have to do is slide the knob on the face of the device, called an Auto Dial, to the name you want, then press the small lever at the foot of the machine.</strong> When the lever returns to its normal position, in five or six seconds, your call is made and you pick up the phone.</p>
<p>The Auto Dial was invented by a German before (World War II). The only sample in (America) is owned by Alfred Altman, President of the National Dairymen Association. The machine can handle any 50 telephone numbers desired by the user, and changes can be made at will.</p>
<p>The signals can be made up of any number of letters and digits, according to the system used in the local exchange. The regular hand dial on the telephone can be used in the ordinary way when the automatic device has been attached.</p></blockquote>
<p>What an improvement over memorizing and/or dialing a number!  We all have these devices built into our cellphones today.  Frighteningly, the original appears easier to use then my cellphone&#8217;s &#8220;Address Book&#8221;.</p>
<p><strong>So why didn&#8217;t this invention catch on half a century ago</strong>, not just a decade ago?  I don&#8217;t know.  I can only speculate, and I don&#8217;t think there is value in writing uninformed guesses down.  But understanding why the Auto Dial was never popular is probably very instructive.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2008/06/28/auto-dial/feed/</wfw:commentRss>
		</item>
		<item>
		<title>The Heat Barrier</title>
		<link>http://vgable.com/blog/2008/06/27/the-heat-barrier/</link>
		<comments>http://vgable.com/blog/2008/06/27/the-heat-barrier/#comments</comments>
		<pubDate>Sat, 28 Jun 2008 04:31:17 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
		
		<category><![CDATA[Research]]></category>

		<category><![CDATA[Technology]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/2008/06/27/the-heat-barrier/</guid>
		<description><![CDATA[Technology improves at an overwhelming pace. The prospect of exponential growth has some people making fantastic predictions.  Eg. &#8220;In 15 years, life expectancies will start rising faster than we age&#8221;.
I&#8217;m a big believer in the power of human invention. But I stumbled upon a somewhat sobering magazine article a few days ago.
CAN WE CRASH [...]]]></description>
			<content:encoded><![CDATA[<p>Technology improves at an overwhelming pace. <a href="http://www.dailygalaxy.com/my_weblog/2008/06/exponential-tec.html">The prospect of exponential growth has some people making fantastic predictions</a>.  Eg. &#8220;In 15 years, life expectancies will start rising faster than we age&#8221;.</p>
<p>I&#8217;m a big believer in the power of human invention. But I stumbled upon a somewhat sobering magazine article a few days ago.<br />
<a href="http://blog.modernmechanix.com/2008/05/17/can-we-crash-the-deadly-flame-barrier/">CAN WE CRASH THE DEADLY FLAME BARRIER? (Oct, 1955)</a><br />
<blockquote>Fly a plane fast enough and friction will melt it. Can we “put out the fire?”</p></blockquote>
<p>As near as I can tell, the answer is &#8220;no&#8221;.  In fact, it is my understanding that <strong>maximum airspeed has declined over the years</strong>.  For example, the absolute air-speed record, 2,194 MPH, was set in 1976 with <a href="http://en.wikipedia.org/wiki/SR-71_Blackbird">a currently <strong>retired</strong> aircraft</a>.  In 1976, we came up against the heat barrier, and could not break it.  Since then, we have also retired the <a href="http://en.wikipedia.org/wiki/Concorde">only</a> <a href="http://en.wikipedia.org/wiki/Tupolev_Tu-144">two</a> models of supersonic transport aircraft to see active service.  The minimum time to cross the Atlantic is higher today then 20 years ago.</p>
<p>Now it&#8217;s certainly true that miles per gallon of fuel, and speed / gallon, have increased since 1976.  This is almost certainly of more practical importance to the world.  But I think it&#8217;s worth noting an example of a purly-technological dimension that has regressed with time.  Not everything in technology &#8220;<a href="http://en.wikipedia.org/wiki/Moore's_law">doubles every two years</a>&#8220;.</p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2008/06/27/the-heat-barrier/feed/</wfw:commentRss>
		</item>
		<item>
		<title>open source just isn&#8217;t a very good strategy for fixing ugly</title>
		<link>http://vgable.com/blog/2008/06/24/open-source-just-isnt-a-very-good-strategy-for-fixing-ugly/</link>
		<comments>http://vgable.com/blog/2008/06/24/open-source-just-isnt-a-very-good-strategy-for-fixing-ugly/#comments</comments>
		<pubDate>Tue, 24 Jun 2008 17:05:01 +0000</pubDate>
		<dc:creator>Vincent Gable</dc:creator>
		
		<category><![CDATA[Design]]></category>

		<category><![CDATA[Quotes]]></category>

		<category><![CDATA[Open Source]]></category>

		<guid isPermaLink="false">http://vgable.com/blog/2008/06/24/open-source-just-isnt-a-very-good-strategy-for-fixing-ugly/</guid>
		<description><![CDATA[ And unfortunately, open source just isn&#8217;t a very good strategy for fixing ugly. 
&#8211;Hank Williams.
]]></description>
			<content:encoded><![CDATA[<blockquote><p> And unfortunately, open source just isn&#8217;t a very good strategy for fixing ugly. </p></blockquote>
<p>&#8211;<a href="http://whydoeseverythingsuck.com/2008/06/can-open-source-save-symbian-from-ford.html">Hank Williams.</a></p>
]]></content:encoded>
			<wfw:commentRss>http://vgable.com/blog/2008/06/24/open-source-just-isnt-a-very-good-strategy-for-fixing-ugly/feed/</wfw:commentRss>
		</item>
	</channel>
</rss>
