El señor Joel [1] escribe muchas verdades sobre control de versiones distribuido:

“No puedo decirte cuantos usuarios de Subversion me han contado esta historia:

«Tratamos de hacer un branch de nuestro código, y funcionó bien. Pero cuando llego el tiempo de hacer el merge, fue una pesadilla y prácticamente tuvimos que aplicar cada cambio a mano. Juramos nunca más volverlo a hacer y desarrollamos una nueva manera de desarrollar software utilizando condicionales if’s en lugar de branches»

A veces hasta están un poco orgullosos de esta nueva invención de ellos. Como si fuera una virtud el hecho de que tu control de versiones no esta haciendo lo que esta supuestamente destinado a hacer.”

¿A quién no le ha pasado? hacer merges después de muchos cambios en Subversion es un dolor de cabeza.

Yo solo he trabajado en proyectos personales con Git, pero el hecho de que te permita trabajar sin conexión y hacer commits localmente es oro puro. Pero para equipos tiene aún más ventajas. En serio, el hecho de poder hacer cambios como loco, guardando un historial de ellos sin que temas romper el repositorio de los demás no es apreciado lo suficiente. Agrega a eso branching y merges que funcionen como se supone que deben de funcionar y no hay ninguna razón para que no lo pruebes [2].

Git y Mercurial son a Subversion lo que el mismo fue para CVS. Simplemente son mejores.

[1] Por mucho uno de mis bloggers favoritos, es una verdadera lástima que se retire.
[2] HG Init es una gran guía para entender sistemas de version distribuidos, aunque esta orientado a Mercurial, te servirán los conceptos para Git. learn.github es el imprescindible si estás interesado en Git.

Para la creación de interfaces de iPhone hay de dos sopas; o las haces puramente con código, o utilizas Interface Builder. Unos juran por sus hijos que hacerlas con código resulta en una aplicación más rápida, otros dicen que da lo mismo. ¿A quien creerle?

Matt Gallagher escribió un artículo -buenísimo- sobre el tema, y yo me quedo con la conclusión.

La conclusión es que ya sea elijas usar un NIB o no, deberías escoger aquello con lo que te sientas más cómodo y lo que sea que mantenga tus gastos de mantenimiento de código más bajos. No te preocupes con que algún enfoque u otro vaya a causar que tu interfaz sufra.

En sus pruebas si que hacerlo con puro código era más rápido -en la mayoría de los casos-, pero realmente la diferencia no era tan abrumadora -5% a 10%- como me imaginaba. Me gustaría más ver comparaciones con una aplicación real, algo pesado como la de Facebook por ejemplo.

“Hay un consejo muy simple que casi cualquiera puede usar para incrementar tremendamente su productividad. Y no solo es gratis, sino que hasta puede hacer que ganes un poco de dinero. Y te hará más listo. Es muy fácil, solo consiste de un paso: Vende tus televisiones.”

~ Lukas Mathis sobre productividad.

Por un lado me molesta como Apple piensa imponer su sistema de distribución no solo en el iPhone y Ipod, sino también para más dispositivos. Ese sistema tan cerrado donde dependes completamente del fabricante para distribuir tu software. Donde en cualquier momento pueden bloquearte o retrasar tus actualizaciones al criterio de un software automatizado.

Por otro lado, me gusta ese sistema tan bueno que permite sucedan noticias como la de Plants vs Zombies, que tuvo un millón de dólares en ventas en solo 9 días. Ese sistema donde cualquier “Pepito el desarrollador” puede disponer de una plataforma de venta y distribución ya lista, donde las personas están a un solo clic toque de pagar por su juego.

Pepito siempre soño con hacer juegos para una plataforma importante, y ahora lo puede hacer por si mismo.