Thoughts and Ramblings

General things I find of interest.

Incorrect Podcast Order on my iPod

One of these days I will learn not to grab the latest and “greatest” software the moment it comes out. Yesterday, I upgraded my iTunes to version 9 and my iPod Touch’s firmware to 3.1.1. Then, I noticed that one of my podcasts was out of order, and furthermore, the release date was no longer showing up on the iPod itself. Strangely, only one podcast was having this issue.

I started to suspect that this was my fault, since this one podcast, Escape Pod was a podcast I was listening by going through its archives. I had written a program which downloads the archived episodes, and modifies the ID3 tags so iTunes will properly recognize the file as a podcast and insert it into its database as if it had downloaded it itself. Getting the release date working correctly was one of the harder points, so I figured that I still didn’t have it quite correct and the new iPod firmware was being more sensitive to it. I got even more annoyed by the fact that iTunes, after upgrading my iPod’s firmware, decided to trash the old firmware versions preventing me from ever downgrading.


Text Compression Techniques

A friend of mine develops on an Bible application for the iPhone, BibleXpress. Since his application includes several translations with the app, he once mentioned to me the possibility of compressing them to save space. Any compression that is done must achieve a good ratio, but more importantly, decompression must be fast. I took it upon myself to find a compression algorithm that could fit the bill.

In my test case, I worked with the NASB translation of the Bible. The raw text of this translation, minus formatting and book/chapter/verse identifiers is 3.965MB. Since the iPhone already has zlib, using gzip compression is an obvious choice. When compressed with gzip, the file size becomes 1.189MB, a significant savings. Even though bzip2 is not readily available on the iPhone (at least not that I could find), I tested its compression which produced a file size of 0.8548MB. While these mechanisms provide a significantly smaller file, when one desires a certain portion of the file, one must first decompress the entire file up to that point. This is an expensive operation on a small device such as the iPhone.


New Car

Well, after much hassle, I now have a new car. Here are some pictures:

New Car Front
New Car Front
New Car Side
New Car Side

The whole ordeal was mostly due to the CARS program, which is often known by “Cash for Clunkers”. Anyway, I finally got that resolved and got a lot more for my old truck than I would have ever gotten in trade-in value. So now I have a VW Jetta, and so far I’m happy with it. I just need to get used to driving a car instead of a truck, but otherwise it drives well.


Using Newer Subversion in Xcode

I use MacPorts to get a whole host of utilities. In addition, I’ve always used it to obtain later versions of subversion that the one provided with the OS. Xcode, on the other hand, is locked into using the version of Subversion which is installed in /usr (currently version 1.4.4 where as I have 1.6.3). Since I often work in the command line, eventually I will use the newer version of Subversion on a directory which I also use in Xcode. This causes a problem since the command line utility will upgrade the local repository format in such a way that old versions of Subversion (Xcode’s) cannot use it.


Working With Core Data

When I redesigned Sapphire, I decided that the metadata back end would be best served by Apple’s Core Data Framework. While the framework has a lot of power, several shortcomings in the implementation hindered its potential.

First, I should start with the many things that Apple did correctly in Core Data.

  • The whole data model with relationships and properties is quite powerful. With this data model, one can represent many data sets in a simple manner, such as the example below:
    core-data-model
    core-data-model
    This example shows part of the data model within Sapphire pertaining to TV shows, where a TV shows contains multiple seasons, each of which contains multiple episodes. Additionally, an episode contains one or more sub-episodes, to handle the case where a single file or DVD contains multiple episodes. Lastly, the show and season objects extend from a superclass CategoryDirectory, which contains some common properties to all collections.
  • Since the relationships are defined, they can be automatically maintained. In the above example, if an episode’s show relationship is set to a particular TVShow object, that show’s object will automatically have the episode added to its episodes relationship.
  • Delete rules can be set such that if an object is removed, the delete can cascade to remove other objects as well. This is useful in the case of removing a directory, and all the files and directories contained within it.
  • Saving to a file is easy since the details of reading and writing a file are handled by Core Data
  • While I didn’t use it, undo management is also built into the system.

So, with all these advantages, why is Core Data not used more often. The answer is that it contains numerous short comings.