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.

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.

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.

So far (the short version) I am doing better than I thought for just about a couple of days being serious about this. There are a few things that still bother me a lot though, aside from the fact that I am not proficient using it yet, of course.

My [mostly borrowed] customizations

I’ve heavily customized Emacs to suit my needs better than it could do with its awkward defaults. Emacs key shortcuts (or is it key bindings?) are soooo unpleasant, unintuitive, lengthy and annoying that I refuse to use them at all. Happily one of Emacs’ most powerful strengths, its ability to be customized, comes to the rescue. Actually this feature is what makes Emacs still relevant after 30+ years.

My Emacs after being customized

Without going too much into details, I based my Emacs customizations mostly on Ryan McGeary’s, mostly because his setup is aimed at Ruby on Rails development and Git, which is what I want Emacs for in the first place. Overall, it’s ri-emacs, rinari, rhtml-mode, magit, yasnippets, and several other non-language-specific customizations (ido, recentf, etc.)

On top of this setup, and after pruning stuff that I don’t need, at least for the moment (like erlang, markdown, haml, svn, carbon-emacs, etc.) I added support for some other stuff, namely rspec, cua-mode (see Common User Access), and other minor goodies from other sources.

Aside from McGeary’s setup as a base, I have to give credit to snippets of code I borrowed from elsewhere to further customize my environment. I should particularly mention Devcraft’s advises to customize Emacs for Rails development, Dahoiv’s .emacs file, the Emacs blog (where Ryan McGeary also writes) and the emacs-flu blog.

Pros and Cons

On the good side, I have played for a while with the ruby on rails mode and it is good. The yasnippet extensions take a lot of credit on this, but overall it tastes very good on its own. I have yet to deal enough with the magit extension to fully evaluate my environment. I cannot afford buying a Mac+TextMate for Ruby development, and Emacs can hopefully come to the rescue for my productivity and joy while coding.

Also, having been able to get rid of most of the many painful key bindings in such a short time was amazing. I wonder why Emacs does not update its defaults to comply with the CUA standards. The cua-mode is not enough.

On the bad side (taking aside my own inexperience and lack of abilities) not everything is doing fine. Many of my key-bindings customizations break on “weird” modes, like C-w for closing the current buffer, which is not working when the current buffer is in dired mode.

Also, I feel disappointed with the embedded shell (M-x eshell). I actually expected a bash session inside an Emacs window, but aliases and tab-completion are not working as they should, which makes me suspect it is not bash but an Emacs shell program (surprise!!!). As it is right now, I prefer to Alt-Tab to my terminal emulator with a real bash session in it. Something similar happens with the Rails console (available via C-c ; c), which I really didn’t test a lot after I realized that pressing the up and down arrow keys didn’t navigate through my history of previous commands .

So, what is it then?

In spite of all this, I still believe I can give Emacs a chance. Most shortcomings I’ve faced are not directly related to its function as a coding environment, but to tasks around coding, like going to the console to type rails-related commands, manipulating the file system, etc. I was doing these stuff outside my previous code editors anyway so I guess this can stay as is for some time.

Hopefully I’ll be able to fix some of this issues over time and always use more and more features of this wonderful editor. I could even live without using git from within it, but I have yet to test that. Meanwhile, I’ll take some time to get better at coding with what is currently working for me. It seems to me that Emacs will stay for a while on my desktop.

Emacs icon

I have always heard and read a lot about that piece of software called Emacs. You know what they say: you either love it or hate it (or else you pass by without knowing about it, in which case you probably don’t want to keep reading).

Maybe it’s time to seriously consider it, because it’s intriguing how its fans always say it is the climax of productivity in computer programming and several other tasks, although it may be really hard to grasp in the first place. I have been warned, and I am determined not to be easily scared off of it, no matter how daunting this task may be.

And as I like to use my blog as a back reference for things I achieve or come to learn after a great deal of work and research, it might be reasonable to expect me to blog about my progress or my rage while trying to tame this wonderful and powerful beast.

I have found great websites so far to start banging my head, namely the Emacs wiki, the Emacs blog and Google That is, of course, besides Emacs’ own website, which serves as a starting point for a lot of information.

So far I have managed to customize it a bit much to my liking, but mostly out of copying and pasting (or is it yanking?) snippets of code from the web into my .emacs file. It’s going to be a long journey until I start typing my own elisp code. I am not even scratching the surface yet, I’m barely staring at it.

Or so I though… until recently. It turns out that to be sure, I searched for command-line bookmarks on google and after a while digging for it, I managed to find three different projects that aim at providing this feature to my favorite shell.

I downloaded and installed all these packages and I am sharing my thoughts about them here.

go-tool

go-tool

This was the first one I found and the one I have used the most. The project is hosted at http://code.google.com/p/go-tool/ and it is developed in Python.

It has a command-line automated setup process that installs the python module system-wide, and there’s also a command to automatically setup shell integration.

Shell integration is achieved by registering some bash functions that do the actual directory change (this is needed because spawned processes do not change the working directory of the parent process, so a python script cannot actually change the working directory of the shell session that started the script). As you can imagine, this feature is common to all the three projects.

Directories are aliased to a short keyword that you can later use to change your current directory. You can add a bookmark for the current directory, or for any other directory, you can delete bookmarks, etc. The details are better covered in the project’s homepage.

The main downside of this solution is that once you start using it, you start missing bash completion with the TAB key. Although I guess it shouldn’t be difficult to implement it ourselves. The program stores its bookmarks in ~/.go/bookmarks. The main advantage is that it is multi-platform, supporting Unix-like environments (including Apple’s Mac) and Windows.

CDBM

cdbm

The name is an acronym for ‘cd bookmarks’ and the project is hosted at google code too (http://code.google.com/p/cdbm/) although I found more information about it from its author’s blog. It is programmed in c.

This is the most simple of the three projects I found. It is simple to install and simple to use, but it is also the simplest in terms of features and possibilities, although unlike the previous one, it features auto-completion.

Shell integration is achieved in a similar way, through bash functions that have to be programmed into our ~/.bashrc file.

Its main disadvantage is that is oriented to bookmarks indexed by numbers instead of aliases or keywords. In a more recent version the author added keyword support on top of the previous design, without removing the numeric index. However, keywords support still doesn’t feel natural.

Apparix

apparix

This was the last project I found and it is the most complete in terms of features. It is hosted at http://www.micans.org/apparix/ and implemented in c as well.

It features shell integration, bash auto-completion support, and it extends bookmarks to more than just a simple super-cd utility. For instance, bookmarked directories’ contents can be listed remotely, without actually changing the current directory.

Shell integration si great, but its configuration could be more automated into the setup process, like the go-tool project does. But the bundled auto-completion is great. You can even auto-complete further into the subdirectories of the bookmark you are using in the command.

Take a look at the following sequence of commands:

ernesto@ubuntu:~$ cd /var/cache/
ernesto@ubuntu:/var/cache$ bm
added: cache - /var/cache
ernesto@ubuntu:/var/cache$ apparix
--- portals
--- expansions
--- bookmarks
j cache        /var/cache
ernesto@ubuntu:/var/cache$ cd
ernesto@ubuntu:~$ to cache apt/archives/partial
ernesto@ubuntu:/var/cache/apt/archives/partial$

We change into the /var/cache directory, and then we register a bookmark for it with the 'bm' command. The 'apparix' command then lists the available bookmarks, where you can see our recent addition. Then we go back to our home directory, and use the 'to' command to change into a subdirectory of the directory represented by the bookmark, instead of just changing into the bookmarked directory only.

And the winner is…

Clearly apparix is the most complete of the three alternatives I found, although I have been using the go-tool for some time already, and I was getting used to it. However, I always missed auto-completion for the go-tool, never decided to implement it my self, and now that I have found apparix with it, I guess I’ll make the switch.

You go and play with them and make your own choice. The command line will never be the same after you start using this.