Full Of Caffeine

Very nice article that elaborates on the tool vs language world. In the end, we all fluctuate between this spectrum, but I think the best are the ones who tend to be language mavens, which puts the focus on the language itself and not on the IDE.

Of course, there are some languages that are so damn heavy and painful, that if you happen to be one poor soul that program on it for food, it makes sense to use the tools to aliviate the pain. However, if you still insist on using all kinds of IDE and or plugins for every other language, beware, you might be turning into a lazy, useless and fat pseudo-programmer.

Check it out @ The IDE Divide, by Oliver Steele.

Food for thought!

If you find yourself wanting to make the font smaller/bigger on a buffer-basis, you can use the following key-combos for that:

* C– – make font-size smaller;
* C-shift-+ – make font size bigger;

So, I stumbled upon a common situation today — I needed some data to be quickly entered on my app’s database, and this data had complex relationship information. The first thing I have done was creating a migration and put it in a data migration rake namespace. However, this data was temporary but in this specific case, I needed it. What to do? script/console!…

Well, script/console was not really the complete answer. Writing everything in direclty in its prompt is error-prone and awkward.

The solution to all of this is pretty simple: Write the code in ruby, save it to a file somewhere and pipe it to script/console:

$ script/console < ~/Desktop/code_to_run.rb

This code will run in the context of your app, and you will have the whole Rails env. available. Good for quick jobs like importing some data. This could even be used as simple and quick way to exchange data .

So, I’ve been breaking my head the last weeks, and finally (and hopefully) came to a conclusion.

Yeah, I’m a geek, I love technology and also to argue about editors. But there’s a beautiful world outside and an awesome life to live, I don’t really have time to engage on flame wars or dedicate my life for the emacs or TextMate cause.

I learned to be pragmatic.

If you are a long time emacs user, don’t be afraid to try TextMate, it is really a great editor, and if you are into Rails, you gotta try it, it just cuts out the crap of setting up and just works. I know, I know, emacs can be as great as TextMate, and I also know that with emacs you could type as fast as the speed of light, but… c’mon, reaching this point is obsessing about tools.

Emacs is awesome. I use it every single day to edit all kind of text files. I also have my whole KB and PIM in there (kudos to orgmode!) and I don’t see why I would replace it by buggy and heavy/closed-format OmniFocus or Evernote. It just works fine (By the way, I’m planning a series of articles on how to setup the ultimate KB/PIM system on a Mac using Emacs + Orgmode, stay tuned!).

Here’s my take on the subject, in a few lines:

Emacs has its strong points and uses. Textmate too. There are projects and files and situations. Some situations, such as when you are starting to get acquainted with a project, calls for TM, because it has a project browser, and allows you to have a quick overview and visual model of the project folder structure. Emacs is great when you are already so used to the file structure that you don’t want to look at it anymore. If you are an emacs user, you know how fast you can just switch between files if you know where they are, and with gpicker, it is even easier. In Emacs, however, you don’t get a good-looking and smooth project browser. period.

I’m currently using Emacs for all PIM/KB stuff, outlining, study, etc and TextMate for the Rails project I just started working on.

So, it is good to have a goo graps of both editors. Now, put that on your inbox “Experiment with TextMate/Emacs”!

After posting about my sorrow of not being able to compile gpicker on OSX because I could not manage to compile GTK+ on the very same OS, the creator of gpicker, Mr. Aliaksey Kandratsenka came to my humble blog and politely told me that gpicker was already building on OSX!

How? Well, he managed to set up the configure script to build a makefile that in turn uses the pre-packaged GTK+ for OSX (http://www.gtk-osx.org/), I don’t know the exact difference between this one besides knowing that it is pre-compiled (and has the headers), but I think it is a new project and hasn’t been around for so long.

How to compile it? Well, just install the GTK+ by using the provided dmg, and download gpicker 1.1.3 from here. Unzip it somewhere in your system, then:

1. $ ./configure
2. $ make
3. $ sudo make install

Then, set it up for you preferred editor. The originall integration is, of course, for emacs, and is just a matter of loading up a simple .el file and letting gpicker know which directory to search by default, and bind its triggering to a key-combo.

Here’s a screenshot of it in action:

(Note that this is a project that is composed of several applications, and some of them have the same name for the artifacts — models, controllers etc, but with a simple expression such as the one written, I can find the exact file I want in no time).

Anyway, gpicker is now beautifully running on my MacBook, and my agility with emacs is back at light-speed.

Thanks Aliaskey!