Crazy Enough to Change the World

I don't like the iPhone, but I owned and used a iPhone 3G for two years. I don't like Macs, but I grew up using one and own one now. As a technologist I dislike the technical foundation that the products are built on. There are so many small things that drive me crazy as a developer.

None of the technical considerations mattered to Steve Jobs. It was never about the technology, it was always about the people. He realized that it wasn't about the megahertz or mega pixels, it was how it worked and how it looked.  Technology was only the enabler. Steve Jobs raised the bar for everyone creating products and at the same time moved society forward.

Apple was an experiment in what would happen if you actually had one person that was willing to make the final decision. He may not have always been correct, but he thought he was and stood behind his decisions.

The question I ask myself and I believe everyone should ask is, "By doing this am I making the world a better place?" You really can't know the actual answer to the question till after the fact. Mr. Jobs, the answer for you is yes.

The Age of the Operating System

What is the biggest challenge in computing?  Depending on who you ask and when you ask the question the answers will be dramatically different.  The biggest challenge often provides the gateway to the next breakthrough in computing.  While the iPad has created a new market that it proceeded to take all of the market share, I do not believe this form factor provides the biggest challenge even though manufactures of Android tablets are acting like it is.  Apple is promoting the three form factor sizes that they sell.  However, this is a dramatic oversimplification.



Reality is that we are living in a world where screens come in every shape and size.  The world is not divided into a 3.5 inch, 9.7 inch, and 15 inch buckets.  We have screens that range in size from 2 inches all the way up to 65 inches and beyond.

The real challenge is the operating system.  Specifically, the visual interface of the operating system.  In my mind there are three major competitors that are all working towards the same goal.  Apple's iOS, Google's Android, and Microsoft's Windows are all heading the same direction: a unified interface.



We are not there yet.  For Apple, Mac OSX Lion has an iOS like interface (that I find more annoying than useful) and the iPad has a larger screen that has become very popular.  For Android, Ice Cream Sandwich will unify the the Gingerbread / Honeycomb differences for the phone / table interfaces.  For Microsoft, Windows Mobile Phone 7 and Windows 8 have a unified interface with the Metro design.  Lets not forget the Apple TV, the Google TV, and the Microsoft Xbox all have interfaces for large devices provided by the corresponding companies.

The problem is that the same interface that works on a phone, on a computer, and on a television has not yet been invented.  Some people think it does not exist.  As a developer, I do not necessarily want an interface that is the same, I just want to build it out of the same building blocks.  This way I can write an application once and have it run anywhere.  As a consumer, I want my data and accounts to be portable.  My experience developing applications has taught me that I am horrible at creating interfaces.  I am suited for database and object oriented design, but my GUIs are hideous and hard to use.

My prediction is that Apple, Google, and Microsoft will each provide a solution for a unified operating system that works on every size screen within the next few years.  We are already almost there already!

My least favorite of the approaches is that taken by Apple.  The closed system approach that targets a "single" device has major benefits, but is not capable of innovation in a vacuum.  The iOS platform has pushed computing into new areas and created new opportunities for the average person to integrate technology into their lives.  My favorite approach is the open source one provided by Google's Android.  Even though Android is not developed in the open and the code is licensed Apache 2.0 instead of GPLv3, the balance still favors freedom.  The biggest downside is also the freedom provided by the system.  The combination of phones, tables, and TVs all running Android is mainly complicated by Chrome OS.  The real competitor to keep your eye on is Microsoft. While their phone solution may not be taking off, the market power of Windows combined with Xbox makes this not only the platform of the past, but the likely platform of the future.

While I am currently developing native apps for Windows, Android, and now even iOS, the universal platform is still the web.  While Chrome and Chrome OS are designed to push the limits of the web while providing improvements to security and an overall simplified experience, I do not see native applications going anywhere.  The scifi interfaces of the future are quickly approaching and it will be the next generation operating systems that make them a reality.

I believe the end result will be a way for a developer to write a single application that runs on devices of all shapes and sizes on a single platform.  It may be the open Android, the proprietary Windows, or the locked down iOS, but hopefully all three. The big trend seems to be moving towards simplification.  In the end though, I still only want a heads up display with augmented reality, but that is another issue all together.

Stargate Cake

The credit for creating this awesome Stargate cake goes to Cassie. It was made for Steven's birthday, but it was so amazing I couldn't resist sharing the construction process.

My TWiT Birthday

I've been a fan of TWiT for about 6 years now. As a long time fan, my girlfriend decided to get me a TWiT brick for my birthday. It is a contribution to help build the new TWiT studio, but I get a brick with "UnitVectorY Jared Hatfield" in the lobby of the TWiT brick house.

To top things off she even made me an awesome TWiT themed birthday cake!





You can see in the above pictures the Certificate of Appreciation that I received (my replica brick AKA paperweight is still in the mail), my awesome birthday cake that includes the TWiT logo and reads "Happy Birthday to My TWiT", and my Chromebook showing the TWiT website.

Programming for XML: The Easy Way

I really like XML. It is really amazing what you can do with it. All you have to do is define a structure and then create a document that follows that structure. You can mix and match attributes and elements in individual tags or in lists of tags. The real power of XML is not in the static documents, but in having it be interpreted in running applications.

While I use a lot of programming languages on a regular basis, one of my favorites is C#. One of the reasons C# is so easy to use is because of the built in ability to serialize and deserialize objects directly to XML.  This ability is made possible by the XmlSerializer class. With simple annotations you can directly map the objects into the XML structure. The power of this approach is that you can build individual objects that represent each part of the XML and then load the entire document into memory with a single operation.


Java does not provide this functionality out of the box, but Simple XML provides a very small library that allows for an almost identical approach to be used in Java.


With the appropriate calls, the above code could easily read in and produce the following XML document:


While there are some differences between the C# approach and the Simple XML implementation, they are minor. Other than the minor syntax differences, they two handle arrays of objects slightly different. The biggest difference is the default behavior related to unexpected XML attributes and elements. C# is very forgiving and will be able to handle missing and extra elements and attributes without throwing an exception. However, it will throw an exception if there is a type mismatch such as trying to load a string into an integer. The Simple XML framework uses a strict parsing by default and the application will throw an exception if unexpected elements or attributes are encountered. Luckily there is a parameter that can override this behavior. The main reason I have encountered this requirement is to maintain backward compatibility as an XML schema changes over time.

My real complaint is the way the iPhone (Objective-C) deals with XML parsing. While there is no lack of parsing libraries on the iPhone, none of them use the object annotation approaches that I described above. This boils down to the different approach Objective-C uses with regard to syntax and the way objects are defined.

One of the projects I am currently working on requires that I port over several application libraries that has already been written in both C# and Java to Objective-C so it can run on the iPhone. While I have managed to avoid writing complex XML parsers up till now, it seems unavoidable at this point.

With respect to the iPhone, there is a built in plist parsers. Alternatively, JSON provides another means for document communication that would be somewhat easier. In the end I will have to live with my previous decision related to application architecture and choose an XML parsing engine and write the necessary code.