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.

There’s no way to make it open links by default in new tabs in the background. And no, I do not want to be doing ⌘-click to achieve this. And I do hate browsers opening new windows unless specifically told. Tabbed browsing was invented long ago and most browsers do it fine (read Opera, Firefox and Chrome). At the very least they give you enough options for you to control how you want it to behave. Safari gives some options, but they’re not enough. I know this is Apple’s way of doing things, and most of the time they get it right, but in this case their lack of options and their selection of defaults is not good for me.

And finally, to make things even worse, I cannot see the URL of a link when I hover it. I do not need Safari to have a permanent status bar. It could adopt Google Chrome’s way to do this, which is to show a small tooltip in the place where the status bar would be, but only for the time I am hovering the link.

Google Chrome would be the right choice, and I do use it a lot, but why on Earth does it lack Gears? How is it that Google supports its plugin on Firefox and Safari but not on their own browser??!! I cannot live without Gmail Offline, so that’s why I haven’t been able to dump Firefox completely.

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.

1
2
3
4
5
6
7

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

Google Chrome running on Leopard

I received with great joy today the news that Google’s web browser, Google Chrome, has been officially released for Mac (and Linux), even if it is still tagged as beta.

Since its first appearance in the web browsers scene more than a year ago, Google Chrome has been a source of innovation the area, with isolated processes per tabs, a revolutionary javascript engine, and the great news that its source code would be freely available as open source.

Sure that many were worried by its controversial privacy-violation practices, but the openness of its source code will always allow anyone with the know-how to modify it to their own needs, and that of the worried ones (me included to some extent, I’ll give you that). Indeed there’s a project called Iron which offers precisely that: Google Chrome for the privacy fanatics.

But just as about anything that’s new, Chrome for the Mac and Linux has several shortcomings compared to its Windows version that most people are accustomed to. The Apple Blog notes a few of these issues, at least those that affect Mac users, which are probably the same features not present yet in the Linux version as well. The most striking absence, at least for me, is Gears, of which I have become extremely dependent since Gmail offline appeared. This one even comes as a great negative surprise, since Chrome is the only browser that comes with Gears bundled, and being both (Gears and Chrome) from the same provider, I kind of assumed that they were inseparable

Not everything is bad news though. Google Chrome for both platforms integrates itself very well, or so they say. At least for the Mac I can confirm it. Google Chrome feels more like a Mac app than Opera does, which is kind of surprising if you take into account that Opera has been around for the Mac since, well, forever, I guess. And according to the official announcement in Google Chrome’s blog post about this beta release, Chrome seems to blend just well with a variety of GTK themes.

I really hope that this browser and the open source project behind it continue to improve. This news today is indeed a big step, and I’m sure those differences in feature sets will become smaller with time. I also hope that projects similar to the Iron alternative appear for other platforms too. Its open source nature makes it possible for this to come true.

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.

I am bothered with this for a reason. I recently acquired a MacBook and I dumped iPhoto after just a few minutes of using it because it attempted to hide the actual pictures from me via any other application. You’re stuck with iPhoto when you use it, and I like to access my pictures directly with my file manager or even with other applications (Photoshop, Gimp, whatever). Then I started looking for alternatives and Picasa popped up in no time as a very good one, and free (as in beer). I remember I used it on Windows but never committed fully to it, but now I have been happy with it for while on the Mac, and have invested a considerable amount of time tuning my very dear pictures collection, mostly in terms of organization and fixing rotations, because I prefer to do other editing tasks in more professional programs. In terms of organization it got even better just  few weeks after I started using it, when it introduced facial recognition technology, allowing me to organize and browse my pictures by the people appearing on them, and with a minimal effort. It was all a sweet honey moon.

Pictures rotated in Picasa are still in its original state on disk.

But a couple of days ago I wanted to lighten a dark picture I had recently shot, and fired up Photoshop just to be surprised. I went back to Picasa to check it out, but the picture was correctly oriented there. I looked for the picture in Finder and opened it with Preview, and I even bothered copying it over the network to a PC to open it with Windows Picture Viewer. Even Picasa in the PC got it wrong! Everywhere I tried, the picture was wrongly rotated, as it originally came from my camera. Only Picasa on my Mac got it “right”.

After some digging and research, I discovered that this is not a bug but a “feature”. Picasa merely stores the rotation info of each image in the .picasa.ini file in the directory where the image resides. This is faster and safer, since the original pictures are never modified, or so they say. And there’s an option (hidden in the right click menu of a picture that has been rotated or modified in any way within Picasa) to save the changes to disk. But wait! Do not allow you to think for a moment that this could solve the issue. This will save a copy of the original, forcefully, with no way to choose not to do this at my own risk.

I am not an expert of picture editing, but what’s the risk involved in picture rotating? If there’s a risk, why Photoshop or Gimp do not alert me about doing this? Why is this the very first software that avoids at all costs to actually let go the original un-rotated image?

A few weeks ago I would have dumped Picasa completely, but face recognition is kind of addictive. I have already invested time in tagging my friends and relatives, and it’s fun to play slideshows of a certain person, or even slideshows of pictures where two given persons appear. So Picasa stays for now. But I’ll be doing everything else from Adobe Bridge, even importing from cameras, copying and moving pictures around, etc.

However, I am spoiled by my Ruby on Rails background, and I started to think about ORM and ActiveRecord in no time. It turns out that, as I expected, I found a few blog posts and projects out there for this. Nothing surprising, since I’m not the only one coming to the iPhone from Rails, and I have just recently started programming for this platform. Several people have been struggling with it for some time now.

One of the most promising and wonderful projects I found is called SQLite Persistent Objects. It’s like ActiveRecord for the iPhone written in Objective-C (of course), but even better in some respects. You don’t write you data schemas first, but your classes instead. It’s the objects the ones that create the database and tables in the background as needed. It even features dynamic search methods too!

If you’re programming for the iPhone, I really recommend it (although I haven’t tested it thoroughly yet). The article above gives a link to a download, but the project seems to be hosted on google code, so ti would be presumably better to download it from there.

Update (2009-10-23): Coincidentally today the author of SQLite Persistent Objects posted in his blog that after deciding to discontinue development, another developer took over, so the project (which I didn’t know was dying) is alive again! He also links to a great presentation that get you started very quickly.

Having migrated to Mac not so long ago, I am aware that Apple’s default picture managing software already had this feature, although I cannot really say how it worked. I did try iPhoto for a few hours on my first days with my new MacBook, but I immediately hated it for trying to hide my pictures from me. Picasa at least respects my organizational scheme at the file-system level, instead of imposing me one, and I am still able to access my pictures through Finder.

As Picasa recognizes faces, you can add information about this people as you tag them. It can even use (and sync with) your Google Account contacts if you are signed in to Picasa Web Albums. It would be nice though, if it gave you the choice in Mac OS X to use the system’s address book instead, or alternatively. And as a side note, face recognition is not the only new feature of Picasa 3.5, also including in the package geo-tagging with a Google Maps panel withing Picasa’s interface, and more. For the time being, this new version has only been released for Windows and Mac in its English version. Non-English speaking users, or Linux fans, will have to wait a bit. Not to say that Mac people should be completely happy though, because I am still waiting for Picasa to port the very nice picture viewer that it installs on Windows.

In the mean time, I can enjoy watching a slideshow of pictures with me and my girlfriend in it, or detailing how my niece’s face has changed over time since she was born just a few years ago. Face recognition rocks. But beware, if you are a fanatic of organization, it can get become addictive!

PS: I wanted to include a screenshot, but I don’t feel right to publish an image with lots of pictures of faces and names of actual people, without their consent, and painting black areas over names and faces renders the screenshot useless for its original purpose. So I am going on without it. If you want to see it working, download the program and give it a try.

My new MacBook seen from behind

I finally ended this mac envy that has been consuming me for the last few months. Being a Ruby on Rails developer for some time now, all those screencasts and tutorials always based in MacOS X and Textmate have had an effect on me. Although it seems that I’ll be playing mostly with xcode instead of Textmate for some time, but it’s sexy to have Textmate just an inch away in case I need it.

PS: For the couple of friends of mine that already had a Mac, my envy was not malicious.

Rails has to be credited for introducing RESTful design to so many people, including me. I bet most web developers out there first knew about it from Rails, particularly from its 2.x release series, that have adopted resource-oriented design more seriously. The main benefit of adopting a REST-like architecture is that there’s a relatively easy and straightforward way of adding an API to our applications without developing an extra backend.

But Rails didn’t get it completely right, perhaps intentionally, with the outcome that there are so many people out there thinking they are developing RESTful applications.

To understand why, let’s review the original concept of REST, something I never did when I took it for granted from the Rails implementation.

Defining REST

REST stands for Representational State Transfer, and it is an architectural style for distributed hypermedia systems. This is the concise and original definition of its intention, according to its creator Roy Fielding in the paper that started it all.

But perhaps more digestible and to the point than this paper is a blog post recently published by Paul Sandauskas in his blog, where he warns developer about not being fully compliant with REST guidelines. The short story is that resources should be hyperlinked to express their relationships, and client applications of a really RESTful API should be able to “navigate” across the exposed resources without previous knowledge of the URI structure, beyond an initial entry point, which could be the analogy of a home page for a regular web site.

I really recommend you reading Paul’s article, since I won’t go into the many interesting details. Overall, the advantages are many: clients need to have no knowledge about the structure of the resources in the server’s URI space beyond the starting point, so the application provider can make structural changes without “breaking” the clients.

There’s plenty of information about REST out there, independent from the Rails point of view. For a start I recommend the REST wiki, Wikipedia’s article about it, Roy Fielding’s dissertation (in particular chapters 5 and 6) and google of course.

RESTing on Rails

Rails tries to comply with REST and it’s great at it. But not fully compliant. Not that this is a bad thing though, and it’s even perhaps intentional (I don’t know). At least the most important REST guidelines are supported, particularly the URI-to-Resource mapping, avoiding a RPC kind of design.

So where does Rails fails? Mainly at not expressing relationships between resources by including hyperlinks in a resource’s representation (after all, that’s what hypermedia means). This, seen from an API point of view, where representations are often XML or JSON for the consumption of a client application, hinders the ability of the system to survive structural changes in its design and its URI space without rendering all independent clients useless.

For example, imagine a client application connecting to the API exposed by your own application, and requesting information about the products you offer. A reasonable response by a rails application conveys information about the product name, description, price, and the internal auto-generated id.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<products type="array">
  <product>
    <category-id type="integer">3</category-id>
    <description>Just a couch, as you would expect.</description>
    <id type="integer">1</id>
    <name>Couch</name>
    <price type="float">123.45</price>
  </product>
  <product>
    <category-id type="integer">6</category-id>
    <description>For your kid to pretend he's a hero.</description>
    <id type="integer">2</id>
    <name>Spiderman T-Shirt</name>
    <price type="float">12.95</price>
  </product>
</products>

The client application retrieves this XML representation of the resource but to request a single product resource from this list, it needs the URI identifying such resource. But what URI identifies each independent product resource? The client needs to know how the URI structure of our site works, and needs to construct URI’s based on this and the id of the desired product.

But what if we decide to restructure our web site in the future, and resources are no longer referenced the same way? All independent client applications are suddenly broken, or else we are stuck with our initial design choices so we don’t piss off our clients (who wants that after all?).

Why don’t we “navigate” through the resources exposed by our API instead? This implies conveying also hyper-textual information. After all, that’s what we do when we as human users enter an e-commerce web site (or any other web site). The HTML web pages are the resources we consume, and the browser is the library we use to connect to the internet. We don’t know in advance, from a page with a list of products, what the URI’s are for each independent product. That information comes with the page. If the developers decide to change the URI structure of the web site in the future, we can still navigate across the site when we visit it again, provided the initial entry page (the home page) is the same.

So REST is nothing more than just applying foundational web principles to modern web-based programming interfaces.

Does it really matter? Why bother?

It doesn’t really matter, if you are just using your Rails application in a closed environment, that is, if not even you consume the API but just the regular HTML interface, or if you are the only consumer of the API of your own application.

But what if your application is cool and useful enough so that third party vendors start using it to integrate their systems with yours? Isn’t that good? And what if you decide to re-engineer your site in the future and all those non-human API-consumer clients start broking? You’ll either have to…

• …continue supporting the old and the new interfaces at the same time (more work for you),
• …or convince your clients to re-program their interfaces with your application (more work for them),
• …or just let them go for a better provider (you loose).

Of course, you can always drop those pesky plans of re-engineering, but then you are stuck with your initial design choices, as far as they concern the external interface. Why condemn yourself with something that seems good today but might be holding you back in the future?

For Rails applications developers like me, there’s not much of a choice, but I wonder why Rails decided to auto-denominate themselves RESTful when they aren’t really, in the most strict sense of the word.

Pedantry? Perhaps.