I’ve been dealing with Daylight Savings Time issues at work. It’s a pain. I found out Hawaii and Puerto Rico don’t observe DST the hard way. It came to a surprise to me that WordPress that does not support Daylight Savings Time handling at all. I posted my last post and realized the time stamp was off by an hour. WordPressers have to manually update their blog settings to account for the hour(s) offsets from GMT whenever DST comes and goes. Luckily, there is a plugin that automates this process for us. Check it out here.

I wanted to delete some .svn folders that didn’t go away when I disconnected from a repository but couldn’t see them in Finder. So I needed to show hidden files. Here’s how to do it.

Open up Terminal

>> defaults write com.apple.finder AppleShowAllFiles TRUE
>> killall Finder

Replace TRUE with FALSE to hide them again.

I’ve had my MacBook Pro for a couple of months now and I’ve officially switched over to a MBP at work as well.  All this time I have been working without a delete key.  That thing labeled ‘delete’ on my keyboard is really what I have known in the past as a ‘backspace’ key.  Naturally, I assumed Ctrl+delete would give me back my true delete functionality, but that didn’t do it. It turns out the magic key combination is Fn+delete. My productivity should go up now! Yay!

I came across this Google TechTalk with Linus Torvalds on git. I’ve never seen or heard Torvalds speak before. He certainly has a good sense of humor…or arrogance :).

It’s been almost a year since this tech talk and I still really haven’t seen large adoption of git. However after some painful experiences with Subversion, maybe it’s time to take a closer look at git. git sounds great in theory and design, but in practice I’m not yet convinced there is much value add.For example, the point that a truly distributed system allows you to make commits when you are unwired since the commits only go to your local repository, in my opinion, isn’t much value add. I am never really away from a wireless point or ethernet cord when I intend to code. The internet is just too much of a valuable resource for me to be disconnected when I’m coding, whether it be googling an obscure exception or reading online documentation.

The design of git is kind of reminiscent of what maven2 did for the build process and dependency management, with the idea of local repositories and selecting with distribution repositories you trust to pull down your dependencies.

I like the idea of the network of trust. I think that’s where the big win for git is. If I know a coworker is working on a piece of code and won’t be done until the end of the week, I know not to “trust” their branch until they tell me it’s ready.

git seems to encourage more communication between developers, which is great if the teams are practicing Agile software development. The idea of “Individuals and interactions over processes and tools” really needs to be instilled into the developers for git to work though. With so many branches around, there needs to be more communication between developers as to what features or branches are ready to be merged into the next release branch.

I guess only time will tell if git will be accepted by the masses.

I wanted to go through the exercise of contributing to open source with a project of my own. After thinking about it for probably 15 minutes, I decided I wanted to try to build my own caching system in Java. Too bad I knew next to nothing about caching. I went off and did some research.

There are certain known algorithms that have become popular when implementing caches. Given that caches have a finite size (either you run out of space or memory), the cache algorithms are used to manage the cache. These algorithms determine things like how long an item remains in the cache and what gets booted out of the cache when it reaches its maximum size. Wikipedia describes the most efficient caching algorithm “would be to always discard the information that will not be needed for the longest time in the future”. You need to take a look at the data you want to cache before deciding on a caching strategy. Do you need to support random access (the access to the data is uniformly distributed) or sequential access ( you’re interested in large chunks of data at a time)? Is certain data accessed more often that other pieces of data?

Here’s a couple common algorithms:

• Least Recently Used (LRU) – the items that haven’t been accessed the longest get the boot first. This is implemented by keeping a timestamp for all items in the cache. Check out this simple LRU implementation.
• Least Frequently Used (LFU) – the items that are sitting in the cache but have been accessed the least are booted out first. This is implemented by a counter to see how often an item is accessed.
• First In First Out (FIFO) – the item that first entered the cache is the first to go when it gets full. This can be easily implemented by a queue.

Of course, there are projects like EHCache and OSCache out there that have addressed this issue.

OSCache provides a FIFO and a LRU implementation of a cache.

In addition to FIFO and LRU, EHCache provides a LFU implementation of a cache.

Thinking about how these algorithms work, it is easy to see that there are certain cases where using one over the other provides a great advantage. For example in the case of LRU, which seems to be the widely accepted and most used caching algorithm, this cache works great when the majority of the hits come to a very concentrated group of items. This way, most hits, if not all, are retrieved from the cache. However, if there is a large scan of all the data, once the cache reaches its max size LRU will just remove items out on every hit. If the cache can hold a max of 50 items and you have 100 records, as you iterate over the 100 records, the cache will empty out the first 50 records to put in the second half of the records, resulting in lots of add/removing to the cache and 0 cache hits. Algorithms that prevent this from happening, like LFU, are known as scan-resistant.

I was interested in finding if there was some middle ground that gave me the best of both worlds LRU and LFU. It turns out there is.

The algorithm is known as Adaptive Replacement Cache (ARC). It gives you the benefits of LRU as well does a balancing act to prevent data scans from polluting the cache. It does by keeping track of two lists, one for recently references items and another or frequently referenced items. If you read about it, it’s a pretty cool algorithm.

I was excited when I came across this algorithm because I thought it would make such a fine addition as an open source project. And then I discovered it was patented. Apparently, PostgreSQL already went through this exercise and deemed it safer to not use it.

So, now I’m thinking I need a new idea for a project.

Check out Snipshot. I used this to resize the rails image from the previous post since I was lazy and didn’t want to dig up a image editor and I had a browser open already 🙂

Pretty cool technology.