13 de diciembre de 2011

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.

10 de noviembre de 2011

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

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].”

31 de octubre de 2011

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

25 de octubre de 2011

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!

27 de septiembre de 2011

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

26 de septiembre de 2011

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!

24 de septiembre de 2011

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:




:)

15 de septiembre de 2011

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 :)

13 de septiembre de 2011

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:
  2. Get meld
  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 ....)

9 de septiembre de 2011

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
  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!

7 de septiembre de 2011

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:



9 de agosto de 2011

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


N
uevo
control de navegación para

aeróstatos.


1813


Andrés Tejeda


M
áquina
hiladora.


1813


Fray Luis Beltrán


H
erramientas


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


I
nstrumentos
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


P
rimer
helicóptero



eficaz

en la

historia de la aviación
.



1917


Quirino Cristiani


T
ecnología
para



realizar

dibujos animados
.


F
ilma
el primer largometraje de dibujos animados
.


1925


Vicente Almandos Almonacid


S
istema
de navegación nocturno


de


 aviones




 y guías para bombarderos.


1928


Ángel Di Césare y Alejandro
Castelvi

Colectivo


1929


Francisco Avolio


A
mortiguador
hidroneumático


1930


 Enrique Finochietto


I
nstrumental
quirúrgico,


por ejemplo

el separador intercostal a

cremallera


1953


 José Fandi


S
ecador
de pisos de una sola

pieza
,


instrumento doméstico


1968


Jorge Weber


T
apa
de rosca degollable


1970


Eduardo Taurozzi


M
otor
pendular de combustión

interna


1970


Juan Bertagni


P
lano
sonoro


1979


 Francisco De Pedro


S
oporte
fijo para


marcapasos


1983



Mario Dávila

 


S
emáforo
para ciegos



1989


Carlos Arcusín


J
eringa
autodescartable
.



C
apuchón
de seguridad para agujas hipodérmicas


1994


 Claudio Blotta


C
amilla
automática para emergencias


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