Thoughts and Ramblings

This is the first is a series of blog posts I’m going to write over the next several days on things that Objective-C can learn from Java. I’ve been programming in Java since 1997, and in Objective-C since 2001. The two languages have a lot of similarities, but there are a few design principles in which Java excels and Objective-C is left behind. This is understandable considering that Objective-C is older than Java, and Java borrowed heavily from Objective-C when it was designed. In this series I’m only going to discuss changes to the language; these items will have very little, if any, impact on the runtime. For the purposes of this discussion, I’m going to use Java’s terminology since it is more familiar with the programming public. This means I’ll talk about functions instead of selectors, and interfaces instead of protocols.

I’ve been slowly transitioning to using nginx as the web front-end in an effort to reduce Apache’s memory usage. In keeping with this task, I’m moving more and more off of Apache. One piece I recently moved was trac, transitioning to using it directly by nginx by running it in fast-cgi mode where as previously it was running as cgi though Apache.

While fast-cgi is faster, it has inherent issues, such as any memory leak can result in ever growing memory usage, which is exactly why Apache has a setting for each child to serve a limited number of requests before exiting. Trac.fcgi has no such directive, and has the equivalent of a large memory leak, a non-expiring cache. While it’s not as bad as a memory leak, which will indefinitely grow instead of reaching a limit, if the cache size is larger than the available memory for trac to use, it’s just as serious. The only solution, without fixing trac’s caching mechanisms, is to restart trac periodically, but during the time trac is restarting, all requests are lost, causing bad gateway errors to the user. Additionally, the restart needs to be done manually. Clearly not an ideal solution.

So, my parents were using a Flip Ultra HD to record sermons. This camera has a serious flaw which the company has acknowledged and failed to fix. First, the camera has 8GB of memory which it formats into a FAT-32 filesystem. This filesystem has a well known limitation where it cannot have a file which exceeds 4GB in size. The Flip camera, when recoding in HD, will hit this limitation in about an hour (depending on the motion in the video). The simple solution to this is to simply split the recording into multiple files so as to not cause any issues. Pure Digital Technologies, Inc, unlike their competitors, doesn’t seem to have figured out this simple solution but instead elected to have the camera beep and turn itself off. This completely violates what a consumer would expect out of a camera in that it will continually record until it is out of power or out of memory, or in the old days, tape.