Performing unit conversion queries using Google's search box.

Imagine if you could that offline, or even be able to have this functionality available to incorporate it in scripts or other programs as well. Imagine you could have this functionality as an extension in Mac’s AlfredApp.

Introducing Metric: A Unit Conversion Library for Java

I needed this functionality to develop an extension for Alfred, the most wonderful Mac launcher, and I wanted it to work offline, without having to retrieve the results from Google or another online source. So I created a Java library that’s capable of performing unit conversion queries expressed in natural English. I called it simply Metric, made it open source, and published it on Github. You can clone it, fork it, play with it or contribute back if you will. The code is fairly well documented and organized. The library includes some supporting sub-libraries that may be used independently in other projects, including a plural/singular inflector for the English language.

Metric meets Alfred

The original goal of developing a library like Metric was to use it as an Alfred extension. Alfred (http://www.alfredapp.com/) is a wonderful productivity application for Mac, much like Quicksilver or Google’s Quick Search Box, but  a little bit better in my opinion. You can grab a copy of Metric as an Alfred extension here. After you install this extension, you can type unit conversion queries on Alfred using cv as keyword.

Performing a unit conversion query with Alfred

This Alfred extension shows the results of the conversion using Growl, but I guess if you already have a Mac chances are that you Growl installed. If not, you can get it here.

Links and resources

• Metric source code repository on Github
• Unit Conversion extension for AlfredApp
• Alfred App and Growl

A couple of days ago I was introduced to a new data structure I did not know before. It’s called a skip list. It’s a sorted linked list, where the nodes are linked at different levels, forming increasingly sparse chains, each of which skips more nodes, and therefore is faster to traverse, allowing search algorithms to hop over parts of the list when searching. That’s why they’re called skip lists.

The concept was shown to me during a job interview. They briefly introduced me to the concept of skip lists using an image. It is said that an image is worth a thousand words, and in this case the assertion holds:

After I finished the interview I went on to find out more about skip lists, and I was amazed on how I did not stumbled upon them before. Immediately my instinct was to try out the algorithm I came up with during my interview, and when I saw it worked, I ended up writing a whole new SortedMap subclass in Java, implemented with skip lists.

It is surprisingly amazing how easy it is to write the routines for all the basic operations on skip lists, like adding, updating, removing and querying on them, specially when you see it described as a probabilistic data structure, which you have to admit that looks scary at first glance.

Performance

Objective-C provides most of the benefits of C++, plus some more benefits that C++ does not provide at all. And I am not talking only about Simula vs. Smalltalk philosophical differences here, but about stuff that C++ could have actually had without breaking its Simula-like philosophy. Some of the features/reasons I will enumerate below fall under this category.

Declared properties

Objective-C provides a simple way to declare properties that define and describe the state of an object, as well as to implement the way we access these properties.

Properties ensure that we adhere to the principle of encapsulation, by which an object controls the way that other objects have access to query its own state. In Objective-C all instance variables are private to an object, and its values can only be accessed via properties defined in the object’s class.

Properties also play a big role in some of the core features of the runtime library, such as KVC, KVO, Model Objects, etc. I wish C++ would have had this one.

Protocols

Protocols are similar to interfaces in Java. When I started learning Java over twelve years ago, no one made a reference to Objective-C protocols as a similar feature of an existing language, even though protocols were introduced to Objective-C several years before Java appeared.

A protocol defines an abstract interface that classes can adhere to. This interface consists of a set of method definitions that implementing classes should provide.

As a plus, compared to Java interfaces, protocols can define some or all of its methods to be optional, so that implementing classes can opt to provide implementations for the optional methods or not. In this case when sending a message to invoke an optional method on an object that conforms to the protocol, the caller should ensure first, via reflection, that the object is able to respond to the message.

Compared to C++, protocols provide a way to circumvent the lack of multiple inheritance, although their use in the standard Cocoa library is mostly not related to this.

Categories

Categories allow you to add methods to an existing class, but without subclassing. You can do this even with classes from the runtime library or classes to which you do not have the source. This is my favorite language feature. Ever since I became addicted to Ruby I believe I cannot stand a language that does not allow me to do this.

When you first think about it, it makes no sense. Subclassing should be fine. But what if you need to add a new functionality to an existing hierarchy of classes? The best example comes not from Objective-C itself, but from Ruby and the Ruby on Rails framework: Rails would not have been possible without Ruby having this feature. Another good example within the Objective-C realm is the Three20 iPhone programming library, that would have been harder to implement and maybe not too feature-wide if it were not for the language having this feature.

A more mundane but valid use for categories is to split the implementation of a class into separate source files, be it for organizational purposes, or because the class interface and implementation is too extensive and splitting it up makes it easier to understand and maintain, etc.

This is one of the features I believe that C++ could have had without breaking its philosophy, and it would have been great.

Compatibility with C (and C++)

Unlike C++, Objective-C is a proper superset of C, meaning that any C program or file is also Objective-C code. There’s no guideline of what to do and what not to do when using C code in Objective-C. The most evident advantage is that Objective-C programs can use any existing C library without the need for wrappers. Some notable examples of libraries that are used in iPhone programming are sqlite and OpenGL.

It should also be mentioned at this point as a side note, that Objective-C can be combined with C++ as well, although they are still different languages. In this case there’s a list of requirements or restrictions to observe. For more information refer to the official documentation about this feature.

Simpler, more flexible, and easier to master

This one is a subjective reason, but I stand by it.

I have mastered more of Objective-C in six months than of C++ in years. I have also been more confortable learning it. I remember learning C++ as a necessary evil, and by contrast, I am happy that iPhone programming led me to this wonderful programming language.

The language is far from perfect, and there are certainly a few features from other languages that I miss a little bit. My perception of it has changed over time though. When you first start to use it, it appears to be cumbersome and bizarre. But sooner rather than later you start to love it (unless you are a C++ fanboy, of course).

So what do you think about Objective-C? Are there any other features that you love or hate about it? Feel free to share you opinion without starting a war.

Well, not exactly. If you have a real device (and you should anyway, if you are developing for the platform) and this device has lots of contacts in it, then you can copy the internal address book files into the simulator’s file system in your Mac. I actually got the tip from this blog post after searching on Google a little bit, but it did not worked for me exactly that way. I’ll let you know why.

First you have to extract the device’s address book sqlite files. There are two files actually, and according to their names, one is for the actual contacts, and the other one stores the contact images. Both files are located in /var/mobile/Library/AddressBook/ inyour iPhone, so if you have a jailbroken device, then it is as simple as copying through ssh…

scp mobile@iphone:Library/AddressBook/*  ~/Library/Application\ Support/iPhone\ Simulator/User/Library/AddressBook

If your device is not jailbroken then it is a bit more complicated. The solution involves extracting the sqlite files from the backups of your device created by iTunes in your Mac whenever you sync. The blog post linked above has a nice script for doing this, although I have not tested it.

But this did not work for me right away. I copied the files into the specified directory and started the simulation just to see the same empty list. So I wandered a bit through the vicinities of that location and I realized that along with the User directory inside ~/Library/Application Support/iPhone Simulator, there are a few more directories whose names correspond to the versions of the SDK installed in the simulator. Since I am running the simulator on iOS 4.0.2, then I copied the files into this directory structure instead, like below

scp mobile@iphone:Library/AddressBook/*  ~/Library/Application\ Support/iPhone\ Simulator/4.0.2/Library/AddressBook

So if the User directory don’t work for you either, then try looking for the one corresponding to the SDK version that you are running in the simulator.

So besides the obvious hiding of sections not relevant on a printed media, like the sidebar, comments form, etc., I started to look at what other improvements could be made for a printed version of a web page. I readily searched for and turned to an article I recall having read some time ago in A List Apart about exactly this matter: Going to Print.

Following the article’s suggestions I started customizing margins, backgrounds, font type and size, etc. Then I stumbled upon a very tricky issue they mention: what to do with links? They are clearly of no direct use in printed media since users can’t click on a paper, but on the other hand it’s a pity that the extra information conveyed in a link (namely the referenced URL) gets lost.

CSS selectors to the rescue

The article suggests using an advanced CSS2 technique. Using special selectors we can append after every link, the URL it refers to enclosed in parentheses. This will only be visible using modern and fully CSS2-compliant browsers (Yes, I am staring at you, Internet Explorer).

#content .post a:after {
  content: " (" attr(href) ") ";
  font-size: 90%;
}

The above rule states that after any anchor tag within the post, the href attribute value should be added in parenthesis. It also additionally puts the link in a slightly smaller font so that the link text gets more attention.

However, when I actually tried this I didn’t like it. The resulting printed view is too cluttered, specially if you have a sizable amount of links in your post, or if some of them reference URLs that are too long and hard to read. It would be really nice if one could selectively apply this printed styling to certain links only.

An apparent solution would be to apply a certain CSS class to the links we want to have this behavior, and then specify in our style sheet that the rule above should only apply to links with this CSS class.

#content .post a.print-href:after {
  content: " (" attr(href) ") ";
  font-size: 90%;
}

Note the .print-href class in the CSS selector. We now have to apply this class to all the links in a post that we want to be printed along with the referenced URL.

The problem is that there’s no straightforward way of doing this in WordPress’ post editor. The link popup allows you to specify a style class to be selected from a predefined set of wordpress-specific classes, but not your own.

Plugins to save the day

The short story about how to solve this, involves installing the TinyMCE Advanced plugin in WordPress, which enhances the post editor in several ways. One of the several enhancements is that the link popup is larger and has more options, even a few separate tabs grouping lots of different options. The last tab, the one labeled Advanced, allows you to arbitrarily specify the value for several possible attributes of the anchor tag, including the class attribute.

Notice the classes text field in the picture above, where it is already filled with the class name. The actual class name doesn’t matter, as long as you use the same class name in both your links and the CSS rule in your stylesheet.

So now, if you print this post, you’ll notice how some links in it get printed along with the referenced web page, and others don’t. I hope this hint may helpful to anybody out there.

Do you know any other helpful hints about making web pages and blog posts more printer-friendly?

Actually it was very simple and required almost no work. There’s a wordpress plugin for that already, which along with a custom mobile-friendly theme gets the job done. Both the plugin and the theme are developed by Crowd Favorite, a web development company specializing in WordPress customization and enhancement. They also provide two great standard themes, including the one used in the blog’s standard interface.

Do you know any other plugins or tools to make a WordPress blog friendly to handheld mobile devices?

But you probably haven’t heard of ASCIIcasts, which is a text version of the original blog, including a transcript of Ryan’s voice from the original video, along with key code samples and screenshots of the main features explained. Think of it as a textual equivalent of the screencast. It can serve various purposes, including being search friendly (you can make a full text search on Ryan’s spoken words), but also for people like me with a slow connection, it can help me have a glimpse of any episode before actually downloading it, maybe even sparing me the effort and bandwidth. If any of these or other reasons are good for you, or even for the sake of it, take a look as ASCIIcasts. You’ll love it almost as much as the original.

Meanwhile I am enjoying a similar experience. Somebody noticed out there that there are many of us with an iPad already (kind of). The iPad nano has been around for a couple of years now but with another name. And I recently got one and I am delighted with it. Why going crazy about the new one when you can have the nano version which fits in your pocket, has a camera and makes phone calls too!

iPad nano

Now seriously, after using the iPhone for some days I understand why people are crazy to experiment with its big but younger brother. Touch screens are seriously redefining how we interact with computers and from a developer standpoint it’s amazing the whole new set of possibilities that arise. And it’s not only touch screens and multi-touch, but also the ability to make a program adapt to different orientations of the device, to be able to access hardware services like a compass, accelerometer, GPS, etc.

It turns out that git offers three mechanisms to specify which files to ignore. Most people know about the .gitignore files inside the working tree. But if you take a look at the gitignore documentation you’ll find out that there’s a second file to specify ignore patterns that are specific to a given user’s work-flow, but that shouldn’t be cluttering the .gitignore files inside the repo, which are normally also versioned by git and thus shared by all the developers working in the project. Patterns like these should go in the $GIT_DIR/info/exclude file, where $GIT_DIR usually refers to the .git/ directory inside your working tree.

Nobody cares what’s your favorite editor and you shouldn’t be cluttering the ignore files versioned inside the repo with the patterns of the files generated by your working environment. That way your buddies on a Mac won’t laugh at you when they notice you are stuck with Netbeans because you’re on Linux, or that you are geeky enough to use Emacs or Vim instead of the sexy TextMate.

But wait. We still have to repeat all those pesky private ignore patterns in every different project, when we should be able to tell git globally about the garbage we normally want to ignore. DRY anybody?

You’re right. That sounds very stupid. We are programmers after all. We’re supposed to be clever and lazy. So is the guy who invented all this git thing. It turns out that you can specify a global .gitignore file via git-config.

git-config --global core.excludesfile /Users/ernesto/.gitignore

The file doesn’t have to be named .gitignore and it doesn’t have to be in your home directory. The core.excludesfile configuration directive is there precisely so that you can put this global ignore file anywhere you want. Also, beware of using ~/ to specify that the file is in your home directory. The documentation says that it works and expands it to the value of the $HOME environment variable, but it doesn’t work in my Mac.

So now you can go and edit that file and put the things that bother you privately. Mine for instance is something like this.

.DS_Store
.svn
*~
*.[oa]
*.kpf
nbproject
Thumbs.db

Currently it works as a Ruby interface to Mercurial, but they are aiming high. According to their own definition, “[their] goal is to produce a piece of software that lets you forget that you’re working on git project one moment and a Mercurial project the next.” A sort of meta-interface for most modern distributed VCS’s out there, so that you can use them all with the same set of commands, or maybe even interact between different VCS’s. Although I haven’t had the time yet to truly play with it, It appears to be highly customizable.

BTW, they also mention svn and cvs as VCS’s they want to support, but I can’t see why to drain out resources into these dinosaurs. I still don’t get why people still use centralized-only VCS’s if they have the choice of distributed version control. But anyway, I wish them good luck with the project overall, and I will sure keep an eye on it for a while.