El Arjonio

Excelente post de El Espíritu de los Cínicos: Link.

Después de que Dani Granatta inventara al Arjonio como forma de justificar de todos los males (poéticos), fue inevitable dejar constancia académica de su existencia.

A successful Git branching model

Both at work and for my personal software-development-related projects I've been using this excellent branching model suggested by Vincent Driessen in his website: http://nvie.com/posts/a-successful-git-branching-model/

Here's an echo of his awesome post:

 

A successful Git branching model

Published: January 05, 2010

In this post I present the development model that I’ve introduced for all of my projects (both at work and private) about a year ago, and which has turned out to be very successful. I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management.

It focuses around Git as the tool for the versioning of all of our source code.

Why git?

For a thorough discussion on the pros and cons of Git compared to centralized source code control systems, see the web. There are plenty of flame wars going on there. As a developer, I prefer Git above all other tools around today. Git really changed the way developers think of merging and branching. From the classic CVS/Subversion world I came from, merging/branching has always been considered a bit scary (“beware of merge conflicts, they bite you!”) and something you only do every once in a while.
But with Git, these actions are extremely cheap and simple, and they are considered one of the core parts of your daily workflow, really. For example, in CVS/Subversion books, branching and merging is first discussed in the later chapters (for advanced users), while in every Git book, it’s already covered in chapter 3 (basics).
As a consequence of its simplicity and repetitive nature, branching and merging are no longer something to be afraid of. Version control tools are supposed to assist in branching/merging more than anything else.
Enough about the tools, let’s head onto the development model. The model that I’m going to present here is essentially no more than a set of procedures that every team member has to follow in order to come to a managed software development process.

Decentralized but centralized

The repository setup that we use and that works well with this branching model, is that with a central “truth” repo. Note that this repo is only considered to be the central one (since Git is a DVCS, there is no such thing as a central repo at a technical level). We will refer to this repo as origin, since this name is familiar to all Git users.





Each developer pulls and pushes to origin. But besides the centralized push-pull relationships, each developer may also pull changes from other peers to form sub teams. For example, this might be useful to work together with two or more developers on a big new feature, before pushing the work in progress to origin prematurely. In the figure above, there are subteams of Alice and Bob, Alice and David, and Clair and David.
Technically, this means nothing more than that Alice has defined a Git remote, named bob, pointing to Bob’s repository, and vice versa.

The main branches

At the core, the development model is greatly inspired by existing models out there. The central repo holds two main branches with an infinite lifetime:

• master
• develop

The master branch at origin should be familiar to every Git user. Parallel to the master branch, another branch exists called develop.
We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state.
We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from.
When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number. How this is done in detail will be discussed further on.
Therefore, each time when changes are merged back into master, this is a new production release by definition. We tend to be very strict at this, so that theoretically, we could use a Git hook script to automatically build and roll-out our software to our production servers everytime there was a commit on master.

Supporting branches

Next to the main branches master and develop, our development model uses a variety of supporting branches to aid parallel development between team members, ease tracking of features, prepare for production releases and to assist in quickly fixing live production problems. Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.
The different types of branches we may use are:

• Feature branches
• Release branches
• Hotfix branches

Each of these branches have a specific purpose and are bound to strict rules as to which branches may be their originating branch and which branches must be their merge targets. We will walk through them in a minute.
By no means are these branches “special” from a technical perspective. The branch types are categorized by how we use them. They are of course plain old Git branches.

Feature branches

May branch off from: develop
Must merge back into: develop
Branch naming convention: anything except master, develop, release-*, or hotfix-*
Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).
Feature branches typically exist in developer repos only, not in origin.

Creating a feature branch

When starting work on a new feature, branch off from the develop branch.

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

Incorporating a finished feature on develop

Finished features may be merged into the develop branch definitely add them to the upcoming release:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature. Compare:

In the latter case, it is impossible to see from the Git history which of the commit objects together have implemented a feature—you would have to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it is easily done if the --no-ff flag was used.
Yes, it will create a few more (empty) commit objects, but the gain is much bigger that that cost.
Unfortunately, I have not found a way to make --no-ff the default behaviour of git merge yet, but it really should be.

Release branches

May branch off from: develop
Must merge back into: develop and master
Branch naming convention: release-*
Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release.
The key moment to branch off a new release branch from develop is when develop (almost) reflects the desired state of the new release. At least all features that are targeted for the release-to-be-built must be merged in to develop at this point in time. All features targeted at future releases may not—they must wait until after the release branch is branched off.
It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier. Up until that moment, the develop branch reflected changes for the “next release”, but it is unclear whether that “next release” will eventually become 0.3 or 1.0, until the release branch is started. That decision is made on the start of the release branch and is carried out by the project’s rules on version number bumping.

Creating a release branch

Release branches are created from the develop branch. For example, say version 1.1.5 is the current production release and we have a big release coming up. The state of develop is ready for the “next release” and we have decided that this will become version 1.2 (rather than 1.1.6 or 2.0). So we branch off and give the release branch a name reflecting the new version number:

$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)

After creating a new branch and switching to it, we bump the version number. Here, bump-version.sh is a fictional shell script that changes some files in the working copy to reflect the new version. (This can of course be a manual change—the point being that some files change.) Then, the bumped version number is committed.
This new branch may exist there for a while, until the release may be rolled out definitely. During that time, bug fixes may be applied in this branch (rather than on the develop branch). Adding large new features here is strictly prohibited. They must be merged into develop, and therefore, wait for the next big release.

Finishing a release branch

When the state of the release branch is ready to become a real release, some actions need to be carried out. First, the release branch is merged into master (since every commit on master is a new release by definition, remember). Next, that commit on master must be tagged for easy future reference to this historical version. Finally, the changes made on the release branch need to be merged back into develop, so that future releases also contain these bug fixes.
The first two steps in Git:

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2

The release is now done, and tagged for future reference.
Edit: You might as well want to use the -s or -u flags to sign your tag cryptographically.
To keep the changes made in the release branch, we need to merge those back into develop, though. In Git:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

This step may well lead to a merge conflict (probably even, since we have changed the version number). If so, fix it and commit.
Now we are really done and the release branch may be removed, since we don’t need it anymore:

$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

Hotfix branches

May branch off from: master
Must merge back into: develop and master
Branch naming convention: hotfix-*
Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version.
The essence is that work of team members (on the develop branch) can continue, while another person is preparing a quick production fix.

Creating the hotfix branch

Hotfix branches are created from the master branch. For example, say version 1.2 is the current production release running live and causing troubles due to a severe bug. But changes on develop are yet unstable. We may then branch off a hotfix branch and start fixing the problem:

$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)

Don’t forget to bump the version number after branching off!
Then, fix the bug and commit the fix in one or more separate commits.

$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)

Finishing a hotfix branch
When finished, the bugfix needs to be merged back into master, but also needs to be merged back into develop, in order to safeguard that the bugfix is included in the next release as well. This is completely similar to how release branches are finished.

First, update master and tag the release.

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1

Edit: You might as well want to use the -s or -u flags to sign your tag cryptographically.
Next, include the bugfix in develop, too:

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

The one exception to the rule here is that, when a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of develop. Back-merging the bugfix into the release branch will eventually result in the bugfix being merged into develop too, when the release branch is finished. (If work in develop immediately requires this bugfix and cannot wait for the release branch to be finished, you may safely merge the bugfix into develop now already as well.)
Finally, remove the temporary branch:

$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).

Summary

While there is nothing really shocking new to this branching model, the “big picture” figure that this post began with has turned out to be tremendously useful in our projects. It forms an elegant mental model that is easy to comprehend and allows team members to develop a shared understanding of the branching and releasing processes.
A high-quality PDF version of the figure is provided here. Go ahead and hang it on the wall for quick reference at any time.

How to delete a remote GIT branch

From Chapter 3 of Pro Git by Scott Chacon:

Deleting Remote Branches

Suppose you’re done with a remote branch — say, you and your collaborators are finished with a feature and have merged it into your remote’s master branch (or whatever branch your stable codeline is in). You can delete a remote branch using the rather obtuse syntax git push [remotename] :[branch]. If you want to delete your serverfix branch from the server, you run the following:

$ git push origin :serverfix
To git@github.com:schacon/simplegit.git
 - [deleted]         serverfix

Boom. No more branch on your server. You may want to dog-ear this page, because you’ll need that command, and you’ll likely forget the syntax. A way to remember this command is by recalling the git push [remotename] [localbranch]:[remotebranch] syntax that we went over a bit earlier. If you leave off the [localbranch] portion, then you’re basically saying, “Take nothing on my side and make it be [remotebranch].”

Causas zombie

A lo largo de vueltas y vueltas por Internet he visto guías, libros, infografías y textos sobre todo lo que debe saberse para sobrevivir a un apocalipsis zombie. MAL, muy mal. La cultura del desastre es importante, pero la cultura de la prevención lo es aún más. La mejor forma de combatir a un zombie es evitar que aparezca. Es por eso que he creado esta entrada:

Fuente: http://www.cinismoilustrado.com/2011/10/causas-zombie.html

Add forwards search to bash command history

Hi!

While using the bash console, the ctrl+r command comes extremely handy to search backwards through the command history.

But while searching backwards, we may want to be able to navigate both ways (i.e., backwards and forwards). This is not activated by default.

How to activate it? Just run this command:

$ stty -ixon -ixoff 

Tadaa! And now you can do ctrl+r and ctrl+s to navigate backwards and forwards.

You can also add this to your .profile file (in Mac OS X) or your .bashrc file (in Linux) for this to be available every time you open a Bash terminal.

Cheers!

Update locate database for Mac Os X

Simple command:

$ sudo /usr/libexec/locate.updatedb

How to install GTK and PyGTK in Mac OS X Lion

I run into some problems trying to install GTK and PyGTK, but I found a workaround, so here's the trick:

You'll need to have brew installed in your system. If you don't have brew installed, you can installed just by running this command:

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.github.com/gist/323731)"

 Now you are ready to go!

Install GTK: just run this command:

$ brew install gtk

Install PyGTK:

• Download this: link.
• It is a Mac installer package. Install it.

That's it!

You  can test your installation from a Python console this way:

$ python
>>> import pygtk

How to change blogger's default language?

Weird hidden option, you can set Blogger's / Blogspot's default language from this link:

http://www.blogger.com/language.g

 Short post :)

Salud!

Delete all "Thumbs.db" files

I haven't used windows for about 5 years now. Lucky me! I now see the world with better eyes and my hair health has certainly improved jeje.

Anyway, some trash always remains and have to be taken care of. Like the hideous "Thumbs.db" files that windows creates everywhere.

How to get rid of them?

First, find out how many of them you have, by running this command:

find . -iname "Thumbs.db"

And just run the following command in the base folder from where to erase them:

find . -iname "Thumbs.db" -delete

You can do just the same for the "desktop.ini" files.

Saludos!

Procrastinando una atrocidad, inspirado por @ralsina :P

Acá en PyConAr Junín 2011, inspirado por unos comentarios que hizo @ralsina en una charla, surgiéronme estas atrocidades, que tenía que compartir:




:)

Smells like teen spirit, de Nirvana, versión acústica

Tremenda versión acústica de este temazo de Nirvana:

Aprendiendo de los errores: secuencia de videos.

Vi estos 4 videítos geniales y ¡no podía no compartirlos!

Recomiendo mirarlos en orden.

Salud!

The Evolution of 'Star Trek' (Infographic)

Source: SPACE.com: All about our solar system, outer space and exploration

Después de haber laburado más de 10 horas hoy....

.... llegar al final del día logrando esto, es.... en un modo muy particular, maravilloso! jeje

Acá la cosa en cuestión que me hizo feliz ver:

----------------------------------------------------------------------
Ran 414 tests in 232.764s

OK
Destroying test database for alias 'default' ('test_cpi_mrp3')...

Sí señor! Sí señor! Ahora sí puedo hacer un push a origin e irme a dormir :)

How to install meld in Mac OS X Lion

Missing the nice and sweet meld program for your SVN or GIT diffs in Lion?

Try this:

1. Get and install pygtk:
• http://downloads.sourceforge.net/project/zero-install/PyGTK/2.24.0/PyGTK.pkg
2. Get meld
• http://ftp.gnome.org/pub/gnome/sources/meld/1.5/meld-1.5.2.tar.bz2
3. Extract the tar.bz2, go to the extracted directory and then run:
1. Note: This assumes you have brew installed. If not, see here.
• $ brew install intltool
• $ brew install gettext
• $ export PATH=/usr/local/Cellar/gettext/0.18.1.1/bin/:$PATH
• $ make prefix=/usr/local/ install 
4. Now you should now have the 'meld' command available.

Some useful links I went through to figure the above mentioned steps:

• http://meld.sourceforge.net/
• http://meld.sourceforge.net/install.html
• http://www.mail-archive.com/pygtk@daa.com.au/msg20559.html

Piloteando un día complicado, en el día del programador

Bueno, no todos los días son lindos, simpáticos, brillantes y afortunados. Hasta hay veces en que escribo en mi blog en castellano y sólo porque sí, y no para acordarme y compartir algún tip técnico.

Por ejemplo, hoy empecé mi día pornográficamente temprano, con todos los tests y mi instancia local(sí, soy programador, hoy es el día del programador, y nótese no puse eso entre mis desgracias del día jeje), se me rompió el cosito que hace que salga el agua del inodoro, me golpeé la rodilla con una silla y me cayó perfume en un ojo.

Pero podría ser peor. Por ejemplo, me podría haber caído perfume en el otro ojo también. O en vez de la rodilla me podría haber golpeado la ingle.

Pero toda esta racionalización en la vastísima mayoría de los casos no sirve de nada: uno simplemente se pega unas encabronadas tremendas. El punto de este post es, por si acaso les sirviera, compartirles algo que de vez en cuando me mejora un poquito el humor en estos días parcialmente nublados.

¿Qué hago para desencabronarme un poquito en días como hoy?

Bueno, suelo tomarme un té de boldo y leer el Desiderata. ¿Qué es el té de boldo? Bueno, eso no es tan importante. Tomen la infusión que prefieran, estimo que va a funcionar de cualquier modo.
¿Qué es el Desiderata? Les transcribo un poquito de Wikipedia, para poner contexto a la cuestión:

Desiderata (del latín desiderata "cosas deseadas", plural de desideratum) es un poema muy conocido sobre la búsqueda de la felicidad en la vida. Sus derechos de autor son del año 1927 y pertenecen a Max Ehrmann. Desiderata fue publicado en 1948 (después de la muerte de su autor) en una colección de poemas titulada Desiderata of Happiness, recopilados por la esposa de Ehrmann.
En la década del 60 circuló sin la atribución a Ehrmann, a veces con la afirmación de que había sido encontrado en la iglesia St. Paul de Baltimore, en Maryland, Estados Unidos. También se decía que había sido escrito en 1692 (año de la fundación de la iglesia). Sin embargo, esta poesía ha mantenido el sello de Ehrmann en algunas de sus ediciones.

Fuente: http://es.wikipedia.org/wiki/Desiderata

Bueno, ya que estamos en esto, el Desiderata en sí, es este:

“Camina plácidamente entre el ruido y las prisas,

y recuerda que la paz puede encontrarse en el silencio.

Mantén buenas relaciones con todos en tanto te sea posible, pero sin transigir.

Di tu verdad tranquila y claramente;

Y escucha a los demás,

incluso al torpe y al ignorante.

Ellos también tienen su historia.

Evita las personas ruidosas y agresivas,

pues son vejaciones para el espíritu.

Si te comparas con los demás,

puedes volverte vanidoso y amargado

porque siempre habrá personas más grandes o más pequeñas que tú.

Disfruta de tus logros, así como de tus planes.

Interésate en tu propia carrera,

por muy humilde que sea;

es un verdadero tesoro en las cambiantes visicitudes del tiempo.

Sé cauto en tus negocios,

porque el mundo está lleno de engaños.

Pero no por esto te ciegues a la virtud que puedas encontrar;

mucha gente lucha por altos ideales

y en todas partes la vida está llena de heroísmo.

Sé tu mismo.

Especialmente no finjas afectos.

Tampoco seas cínico respecto al amor,

porque frente a toda aridez y desencanto,

el amor es tan perenne como la hierba.

Acepta con cariño el consejo de los años,

renunciando con elegancia a las cosas de juventud.

Nutre la fuerza de tu espíritu para que te proteja en la inesperada desgracia,

pero no te angusties con fantasías.

Muchos temores nacen de la fatiga y la soledad.

Más allá de una sana disciplina,

sé amable contigo mismo.

Eres una criatura del universo,

al igual que los árboles y las estrellas;

tienes derecho a estar aquí.

Y, te resulte o no evidente,

sin duda el universo se desenvuelve como debe.

Por lo tanto, mantente en paz con Dios,

de cualquier modo que Le concibas,

y cualesquiera sean tus trabajos y aspiraciones,

mantente en paz con tu alma

en la ruidosa confusión de la vida.

Aún con todas sus farsas, cargas y sueños rotos,

éste sigue siendo un hermoso mundo.

Ten cuidado y esfuérzate en ser feliz”.

How to fix Brew Update Error ( mxcl / homebrew, Mac OS X Lion)

Did you, like myself, get something like this while running a brew update?

[matias@MacBookPro]:~ $ sudo brew update
Password:
remote: Counting objects: 588, done.
remote: Compressing objects: 100% (253/253), done.
remote: Total 455 (delta 348), reused 298 (delta 193)
Receiving objects: 100% (455/455), 52.32 KiB, done.
Resolving deltas: 100% (348/348), completed with 124 local objects.
From http://github.com/mxcl/homebrew
 * branch            master     -> FETCH_HEAD
error: The following untracked working tree files would be overwritten by merge:
        .gitignore
        Library/Aliases/0mq
        Library/Aliases/4store
(.... lots of lines ....)
        Library/Formula/android-sdk.rb
        Library/Formula/angband.rb
        Library/Formula/ansifilter.rb
        Library/Formula/antiword.rb
        Library/Formula/antlr.rb
        Library/Formula
Aborting
Error: Failed while executing git pull origin master

The fix is easy. Luckily. Goes like this:

$ sudo chown -R `whoami` /usr/local
$ cd /usr/local
$ git reset --hard origin/master
$ cd

Now you can try again:

[matias@MacBookPro]:local (git: master ?) $ brew update
From http://github.com/mxcl/homebrew
   3dc7fe2..09ebe32  master     -> origin/master
Updated Homebrew from 3dc7fe29 to 09ebe32c.
==> New formulae
aespipe       fuse4x        fuse4x-kext   ntfs-3g       parmetis      s3fs          scotch        sshfs
==> Removed formulae
unix2dos
==> Updated formulae
(.... lots of stuff here ....)

Cómo Instalar NINJA IDE en Mac OS X Lion

Hace poquito actualicé mi compu a Lion y reinstalé NINJA. Con Diego Sarmentero hicimos luego una mini-sprint para dejar NINJA andando aceitadamente y bien nativo en Mac.

Acá les dejo las instrucciones para instalar NINJA desde el repositorio en desarrollo:

1. Instalar XCode desde el App Store:
• http://itunes.apple.com/us/app/xcode/id448457090?mt=12
2. Instalar HomeBrew:
• https://github.com/mxcl/homebrew/wiki/Installation
3. Instalar Qt y PyQt:
• $ brew install qt
• $ brew install pyqt
• Agregar esta línea en el archivo ~/.profile:
• export PYTHONPATH=/usr/local/lib/python:$PYTHONPATH
4. Hacer un checkout del repositorio de NINJA:
• Hace falta tener instalado Mercurial para hacer el clone del repositorio. Si no lo tenés instalado, lo podés instalar así:
• sudo easy_install mercurial
• $ cd ~
• $ mkdir NINJA_IDE
• $ cd NINJA_IDE
• $ git clone https://github.com/ninja-ide/ninja-ide.git ninja-ide
• $ cd ninja-ide
5. Ejecutar NINJA:
• Vamos a la carpeta del checkout:
• $ cd ~/NINJA_IDE/ninja-ide/
•  $ python ninja-ide.py

Y ahora, a disfrutar de NINJA-IDE!

Disable autocorrection in Mac OS X Lion

I found that Mac OS X Lion came by default with an autocorrection functionality. This can be useful... or a big annoyance!

For instance, it annoyed me when I typed "TRAC" and replaced it with "trace" in one of my daily SCRUM meetings.


Then, how to disable it?

Go to System Preferences -> Language and Text -> Text tab, and disable the check:

Done!

Mac OS X Lion, Python, Django and how I'm happier now with my computer

I recently upgraded my MacBook Pro from Snow Leopard to Lion.

The idea of the upgrade unsettled me quite a bit since I use my computer to work and having it off due to OS or setup issues was not an option. Basically I was worried about having problems to install Python packages(I work mostly as a Django/Python developer, and I use a bunch of stuff from PyPi and quite a few Django pluggables) and I've already had some nasty problems installing, for instance, the MySQL connector in the past in Snow Leopard.

After some hesitation, I finally got myself to the task of upgrading.

After I upgraded, I did all the setup of the Python stuff: all the virtualenvs, Python/Django packages, the requirements for NINJA-IDE, everything WORKED PERFECT. I did not have a single issue. Nor even a single one. I'm happy this of not having to write a long, strange and tricky post saying something like "yes, it is a huge pain in the... patience", because it is just not. Everything work perfect.

I believe that the root cause of the difference relies in Mac OS Lion to came bundled with 64-bit versions of Python pre-installed:

It has, pre-installed:

• 32-bit Python 2.5
• 64-bit Python 2.6 (I use this one for work)
• 64-bit Python 2.7 (I use this for NINJA-IDE, both for running it and to develop the code I write for it)

That's good new that Apple got its OS with more Python magic :)

Tip of the day: how to add a Firefox Persona to favorites?

I didn't find how to do that rightaway, I had to do a little googling.

Here's how if you find yourself wondering around the same question:

- go to getpersonas.com
- create an account(if you don't already have one)
- login
- then, on the details page for any persona, in the top-right, just above the image will be a button that says "Add to favorites" (if you are signed in).
- If you have the "Personas addon" installed, you'll be able to see the Personas you add to favorites listed, which is usefull if you, for instance, reinstall Firefox and want to keep its appearance the same:

Installing cairo and pycairo in Mac OS X with python 2.6

Mac OS X includes an old version of Cairo(usually 1.8.6) which is too old for new software to link against. For the installation of py2cairo to succeed, we need 1.8.10.

Let's check which version we have:

$ pkg-config --atleast-version=1.8.10 cairo
$ echo $?
1

That means there's no a version 1.8.10 or above of the 'cairo' lib.

Let's install it using Brew:

$ brew install cairo

Let's now check again:

$ pkg-config --atleast-version=1.8.10 cairo
$ echo $?
1

No luck again! Why? We need to tell the system where the recently installed version of cairo lives:

$  export PKG_CONFIG_PATH=

Note: In my case, the path is: /usr/local/Cellar/cairo/1.10.2/lib/pkgconfig/


Let's check again:

$  pkg-config --atleast-version=1.8.10 cairo
$ echo $?
0

Awesome!

Let's now install py2cairo, the Python binding for cairo:

1. Download this.
2. Uncompress, go inside the directory.
3. Run the following command, expecting an output like the depicted below:

$ ./waf configure
  ./set_options
  ./init
  ./configure
Checking for program gcc or cc           : /usr/bin/gcc
Checking for program cpp                 : /usr/bin/cpp
Checking for program ar                  : /usr/bin/ar
Checking for program ranlib              : /usr/bin/ranlib
Checking for gcc                         : ok 
Checking for program python              : /Users/matias/Dev/CPI/Env/bin/python
Checking for Python version >= 2.6.0     : ok 2.6.1
Checking for library python2.6           : yes
Checking for program python2.6-config    : /usr/local/bin/python2.6-config
Checking for header Python.h             : yes
Checking for cairo >= 1.8.10             : yes
'configure' finished successfully (0.416s)
  ./shutdown

4. Now build:

$ ./waf build

5. Install:

$ ./waf install

6. Update your PYTHONPATH(you may want to add this line at the bottom of your ~/.profile):

export PYTHONPATH=/usr/local/lib/python2.6/site-packages/:$PYTHONPATH 

7. Check everything worked:

$ python
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import cairo
>>> cairo.version
'1.8.10'

 Happiness!

 

FYI: The output of the configure, build and install commands in my case was the following(I include it for reference, in case it might be of any help):

(Env)matias@[13:51:34]:pycairo-1.8.10 $ ./waf configure  ./set_options

  ./init
  ./configure
Checking for program gcc or cc           : /usr/bin/gcc
Checking for program cpp                 : /usr/bin/cpp
Checking for program ar                  : /usr/bin/ar
Checking for program ranlib              : /usr/bin/ranlib
Checking for gcc                         : ok 
Checking for program python              : /Users/matias/Dev/CPI/Env/bin/python
Checking for Python version >= 2.6.0     : ok 2.6.1
Checking for library python2.6           : yes
Checking for program python2.6-config    : /usr/local/bin/python2.6-config
Checking for header Python.h             : yes
Checking for cairo >= 1.8.10             : yes
'configure' finished successfully (0.416s)
  ./shutdown

(Env)matias@[13:52:07]:pycairo-1.8.10 $ ./waf build

  ./set_options
  ./init
Waf: Entering directory `/Users/matias/Dev/CPI/Stuff/pycairo-build'
  ./build
  src/build
[1/9] cc: src/cairomodule.c -> ../pycairo-build/default/src/cairomodule_2.o
[2/9] cc: src/context.c -> ../pycairo-build/default/src/context_2.o
[3/9] cc: src/font.c -> ../pycairo-build/default/src/font_2.o
[4/9] cc: src/path.c -> ../pycairo-build/default/src/path_2.o
[5/9] cc: src/pattern.c -> ../pycairo-build/default/src/pattern_2.o
[6/9] cc: src/matrix.c -> ../pycairo-build/default/src/matrix_2.o
[7/9] cc: src/surface.c -> ../pycairo-build/default/src/surface_2.o
[8/9] copy: pycairo.pc.in -> ../pycairo-build/default/pycairo.pc
In file included from /usr/X11/include/X11/Xlib.h:64,
                 from /usr/local/Cellar/cairo/1.10.2/include/cairo/cairo-xlib.h:44,
                 from ../pycairo-1.8.10/src/surface.c:1360:
/usr/X11/include/X11/Xosdefs.h:145:1: warning: "_DARWIN_C_SOURCE" redefined
In file included from /System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/Python.h:8,
                 from ../pycairo-1.8.10/src/surface.c:32:
/System/Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/pyconfig.h:1075:1: warning: this is the location of the previous definition
[9/9] cc_link: ../pycairo-build/default/src/cairomodule_2.o ../pycairo-build/default/src/context_2.o ../pycairo-build/default/src/font_2.o ../pycairo-build/default/src/path_2.o ../pycairo-build/default/src/pattern_2.o ../pycairo-build/default/src/matrix_2.o ../pycairo-build/default/src/surface_2.o -> ../pycairo-build/default/src/_cairo.so
Waf: Leaving directory `/Users/matias/Dev/CPI/Stuff/pycairo-build'
'build' finished successfully (0.764s)
  ./shutdown

(Env)matias@[14:05:51]:pycairo-1.8.10 $ ./waf install

  ./set_options
  ./init
Waf: Entering directory `/Users/matias/Dev/CPI/Stuff/pycairo-build'
  ./build
  src/build
* installing src/pycairo.h as /usr/local/include/pycairo/pycairo.h
* installing /Users/matias/Dev/CPI/Stuff/pycairo-build/default/src/_cairo.so as /usr/local/lib/python2.6/site-packages/cairo/_cairo.so
* installing /Users/matias/Dev/CPI/Stuff/pycairo-build/default/pycairo.pc as /usr/local/lib/pkgconfig/pycairo.pc
Waf: Leaving directory `/Users/matias/Dev/CPI/Stuff/pycairo-build'
* installing src/__init__.py as /usr/local/lib/python2.6/site-packages/cairo/__init__.py
* byte compiling '/usr/local/lib/python2.6/site-packages/cairo/__init__.py'
'install' finished successfully (0.832s)
  ./shutdown

Más inventos!

Fuente: http://www.educar.org/inventos/lineadeltiempo/default.asp

Ordenamos en este sitio cronológicamente los descubrimientos e invenciones que ha realizado el hombre desde los principios de la humanidad.

Los sucedidos en los milenios anteriores a la era cristiana son cálculos aproximados. Asimismo en muchos de los inventos hay variaciones en las fechas de su aparición en los diversos documentos consultados, por lo que pueden resultar ser aproximadas.

Desde el 20.000 a. de C. al 1 d. de C.
Fechas	Inventos y datos relacionados	Eventos
20.000 aC 18.000 aC 18.000 aC	Agujas de hueso Pinceles Cabañas de hueso de mamut	Se realizan las primeras herramientas de piedra
13.000 aC 12.000 aC 10.500 aC	Arpones Cestería en mimbre Vasijas de arcilla	Se comienzan a domesticar perros (11.000)
10.000 aC 8.000 aC 7.500 aC 6.500 aC 6.000 aC 5.500 aC 5.000 aC	Redes de pesca Peine  Canoas Fundición de cobre Ladrillo Rueda Balanza	Extinción de mamuts de pelo(10.000) Primeras cosechas en Medio Oriente (8.000)
3.500 a 4.000 aC 3.500 aC 3.300 aC 3.000 aC 1.747 aC 1.500 aC 600 aC Siglo III aC 150 aC	Embarcaciones de vela Arado Escritura Cuneiforme Ábaco Calendario Fundición del Hierro Monedas La palanca El tornillo sin fin El tornillo elevador de agua La rueda dentada La balanza hidrostática Los espejos ustorios Sismoscopio	Alrededor del 3.500 comienza la Edad de Bronce. Arquímedes (287-212 a.C.), notable matemático e inventor griego, nacido en Siracusa, Sicilia, y educado en Alejandría, Egipto, se anticipó a su época con investigaciones e inventos.
Año 1 al 1499 d. de C.
Fechas	Inventos	Eventos
50 105 124 200 a 300 350 400 a 500	Herradura Papel Cúpula Carro con ruedas Estribos Astrolabio	0-33 Vida y Pasión de Jesucristo. 300 - El Cristianismo se ha difundido en el Imperio Romano Fines del Siglo V: Caída del Imperio Romano de Occidente (476). Comienzo de la Edad Media.
650 800 a 900 800 a 900 868 950 999 800 a 1.100	Molino de Viento Papel Moneda Pólvora Impresión de libros  Arado de ruedas Cristales coloreados en ventanas de Inglaterra Partituras	Pleno desarrollo precolombino de las civilizaciones aborígenes americanas, especialmente Mayas, Aztecas, Chibchas e Incas. En el S. X aparece la herradura para caballos y un arnés
1.000 1.000 1.100 1.105 1.118 1.121 1.200 1.232 1.257 1.268 1.272 1.280 1.298 1.400 1.420 1.450 Siglo XV	Lentes Cámara oscura Brújula magnética  Primer molino de viento en Francia Cañón (Usado por los moros) Clavecín Timón de popa Globos de aire caliente (China) Espejos cóncavos  Anteojos Máquina de bobinas de seda en Bolonia Reloj mecánico  Rueda de hilar Pinturas al óleo Velocípedo Imprenta de tipos móviles Laúd	Hacia 1140- "Mio Cid" - Dos juglares de Medinacelli componen el primer texto en lengua romance castellano. 1271. Parte de Venecia Marco Polo rumbo a China. En el S. XIV se perfecciona la fabricación del vidrio y se inventa el telar a pedal. 1492 - Descubrimiento de América.
Año 1500 a 1699
Fechas	Inventos	Eventos
1.500 1.500	Reloj (1.500) Puntilla (1.500)	1522 - Sebastián Elcano completa el viaje alrededor del mundo. 1530- Comienza el comercio de esclavos
1.565 1.581 1.569 1.589 1.589 1.590 1.593	Lápiz Péndulo Mapa en proyección Telar Inodoro Microscopio compuesto Termómetro de agua	1589: Sir John Harrington (GB) inventa el inodoro con depósito, pero pasó mucho tiempo antes de imponerse, y se siguieron usando bacines y retretes con agujeros hacia pozo o foso.
1.609 1.620 1.620 1.640 1.642	Telescopio refractor Diligencia Submarino Bayoneta Calculadora de Pascal	1605 / 1615: Cervantes publica "El Ingenioso Hidalgo Don Quijote de La Mancha" 1620: Arriba el "Maryflower" a América del Norte.
1.657 1.665 1.668 1.672 1.687	Reloj de péndulo Microscopio mejorado Telescopio reflector Bomba neumática Higrómetro	Halley descubre el cometa denominado con su nombre (1682)
Año 1700 a 1899
Fechas	Inventos	Eventos
1.709 1.710 1.712 1.714 1.731 1.733 1.740 1.740 1.742 1.745	Piano  Termómetro de alcohol Máquina de vapor Newcomen Termómetro de mercurio Octante Lanzadera automática Estufa Franklin Imprenta en colores Escala centígrada Condensador eléctrico	Fundación en 1.724, de la Academia de Ciencias de Rusia
1.752 1.757 1.761 1.763 1.769 1.776 1.782 1.783 1.784 1.785 1.790 1.795 1.796 1.796	Pararrayos Sextante Cronómetro Reflectores Parabólicos Automóvil de vapor Volante Máquina de vapor Watt Globo de aire caliente Lámpara de aceite, con mecha hueca Electróforo Hélice Sistema métrico Vacuna Litografías	1.789: Revolución Francesa Termina la Edad Moderna y comienza la Edad Contemporánea.
1.800 1.801 1.801 1.801 1.802 1.803 1.805 1.816 1.821 1.827 1.830 1.831 1.834 1.837 1.837 1.838 1.839 1.840 1.840 1.842 1.846 1.846 1.846 1.848	Martillo Pilón Pila eléctrica Electróforo Endiómetro Locomotora de Vapor Acumulador eléctrico Telar Jacquard Lámpara de seguridad para mineros Termoelectricidad Fósforos Cortadora de césped Dínamo eléctrica Cosechadora Telégrafo eléctrico Alfabeto Morse Estereoscopio Bicicleta Estampilla de Correos Buques con casco de hierro Reloj eléctrico Anestésicos Saxofón Prensa rotativa Cerradura de seguridad	Napoleón es derrotado en Waterloo (1.815)
1.851 1.860 1.860 1.870 1.876 1.876 1.877 1.877 1.880 1.884 1.885 1.885 1.888 1.889 1.890 1.890 1.894 1.894 1.897 1.897 1.899	Cámara de placas Linóleo Esquiladora Máquina de escribir Teléfono Frigorífico Fonógrafo Motor de cuatro tiempos Bombita eléctrica Generador de turbina de vapor Automóvil Bicicleta de pedales Gramófono Ascensor eléctrico Rayos X El tubo  de Crookes Radio Primer periscopio Motor Diesel Motor eléctrico compacto	El motor de cuatro tiempos inventado por Otto (Al. 1877) permitió la invención del automóvil Luis Pasteur, en 1881 comenzó sus experimentos contra la rabia.
Año 1900 a la actualidad
Fechas	Inventos	Eventos
1.900 1.900 1.901 1.902 1.903 1.903 1.903 1.903 1.903 1.906 1.907	El dirigible rígido Zeppelin Tractor Mecano Frenos de disco Cuchilla de seguridad Máquina de hacer botellas Electrocardiograma Cinturón de Seguridad Osito de peluche Lámpara Termoiónica Lavarropas	En 1901, Marconi emite un mensaje de radio a través del Océano Atlántico. Se abre el Canal de Panamá en 1904
1.910 1.911 1.913 1.913 1.913 1.914 1.914 1.916	Se funda la Sociedad de Inventores Argentinos. Modelo nuclear del átomo Acero inoxidable Cadena de montaje Heladera Eléctrica Cremallera Semáforos luminosos Limpiaparabrisas	Comienza la Primera Guerra Mundial (1.914). Albert Einstein desarrolla y enuncia su teoría de la Relatividad (1.915).
1.920 1.921 1.922 1.925 1.926 1.927 1.927 1.928 1.929	Secador de Pelo Autopistas Se funda el Círculo Argentino de Inventores. Contador Geiger Televisor Tostadora Caucho sintético Antibióticos Ciclotrón	Se engrandece la figura del Mahatma Gandhi, en su posición contra el gobierno británico en la India.
1.930 1.931 1.932 1.933 1.933 1.934 1.935 1.938 1.938 1.938	Motor a Reacción Microscopio Electrónico Guitarra Eléctrica Grabaciones Estéreo Polietileno Nylon Radar Café Instantáneo Fotocopiadora Bolígrafo	1936: Guerra Civil Española 1939: Comienza la Segunda Guerra Mundial
1.941 1.942 1.942 1.943 1.946 1.946 1.946 1.947 1.948 1.949	Aerosoles Reactor Nuclear Equipo de Inmersión Turbina de reacción para aviones Horno de Microondas Calculadora electrónica Computadora Transistor Long Play - Disco de Larga Duración Neumáticos Radiales	La Bomba atómica destruye Hiroshima y Nagashaki, Japón, en 1.945
1.950 1.954 1.954 1.955 1.956 1.956 1.957 1.958 1.959 1.959	Tarjeta de Crédito Central Nuclear Radio a transistores Plancha de vapor Velcro Video Cámara Satélite Espacial Aerodeslizador Chip de Silicio Lycra	Mediante arduas investigaciones, se descubre la estructura del ADN (1.953). Realizan el ascenso al Everest, en 1.953, Hillary y Tenzing
1.960 1.962 1.962 1.963 1.964 1.969	Teflón Robot Industrial Satélite de Comunicaciones Video Casettera Procesador de Textos Avión Jumbo	El hombre posa su pie en la luna. En 1.969 los astronautas estadounidenses llegan a la Luna.
1.971 1.972 1.972 1.973 1.974 1.978 1.979 1.979	Reloj Digital Escáners Rayos X Video juegos domésticos Protocolo de Internet (IP) y  Protocolo de Control de Transmisión (TCP) Códigos de Barras Computadora Personal Walkman Catalizadores para automotores	Nace el primer bebe de probeta, en 1978.
1.980 1.981 1.981 1.982 1.982 1.982	Cubo de Rubik Transbordador Espacial Papeles autoadhesivos Tarjeta inteligente Corazón Artificial Discos Compactos	Explosión del reactor nuclear de Chernobyl en 1986. Cae el Muro de Berlín en 1989
1.990 1.990 1.990 1.990 1.991 1.993 1.994 1.995 1.999 2.000	Realidad Virtual Fusión Nuclear Identificador de voz Se funda la Asociación Argentina de Inventores y la Escuela Argentina de Inventores. Videófono Se realiza en Buenos Aires el Primer Congreso Iberoamericano de Inventores Se celebra en Argentina el 50° Aniversario de la invención del bolígrafo. El Correo Argentino emite estampillas conmemorativas, en honor de Biro, y otros inventores argentinos destacados: Pescara, Cristiani y Finochietto. Internet: se populariza el uso de redes con protocolos TCP/IP Se crea en Argentina la Fundación Biro, en el centenario del nacimiento de Ladislao José Biro. Se organiza en Buenos Aires el Simposio Internacional de Inventores (WIPO-IFIA Symposium), por primera vez en el hemisferio Sur	Invasión a Kuwuait por parte de Irak en 1990. Se agilizan las comunicaciones instantáneas y se afianza el concepto de globalización

Algunos inventos argentinos

Buscando algunos inventos por año en que se inventaron, dí con este sitio, que me resultó más que interesante. Siguiendo mi recorrido por el sitio, encontré una sección dedicada a recopilar algunos de los inventos que se hicieron en Argentina y/o por argentinos/as. Acá van algunos: Fecha Inventor Invento 1810 Miguel Colombise Nuevo control de navegación para aeróstatos. 1813 Andrés Tejeda Máquina hiladora. 1813 Fray Luis Beltrán Herramientas metalúrgicas, arneses y batanes para el Ejército de los Andes. 1876 Elías O´Donell Nuevo tipo de aeróstato. 1891 Juan Vucetich Sistema Dactiloscópico para la identificación de las personas. 1914 Luis Agote Instrumentos para la transfusión sanguínea. Realiza por primera vez en el mundo una transfusión con sangre almacenada.   1916 Raúl Pateras de Pescara Primer helicóptero eficaz en la historia de la aviación. 1917 Quirino Cristiani Tecnología para realizar dibujos animados. Filma el primer largometraje de dibujos animados. 1925 Vicente Almandos Almonacid Sistema de navegación nocturno de  aviones  y guías para bombarderos. 1928 Ángel Di Césare y Alejandro Castelvi Colectivo 1929 Francisco Avolio Amortiguador hidroneumático 1930  Enrique Finochietto Instrumental quirúrgico, por ejemplo el separador intercostal a cremallera 1953  José Fandi Secador de pisos de una sola pieza, instrumento doméstico 1968 Jorge Weber Tapa de rosca degollable 1970 Eduardo Taurozzi Motor pendular de combustión interna 1970 Juan Bertagni Plano sonoro 1979  Francisco De Pedro Soporte fijo para marcapasos 1983 Mario Dávila   Semáforo para ciegos 1989 Carlos Arcusín Jeringa autodescartable. Capuchón de seguridad para agujas hipodérmicas 1994  Claudio Blotta Camilla automática para emergencias

Fuente: http://www.educar.org/inventos/inventosargentinos.asp