Git, Parte 1
Un fauvista con cubiertos de gala
No hace mucho que, gracias a un proyecto paralelo a mi trabajo, estoy aprendiendo a usar Git. Encontré que es una herramienta sumamente compleja y flexible, distribuida y rápida.
Un poquito de historia
Git, para quién no lo sabe, es un sistema de control de versiones, distribuído, enfocado en la velocidad, y que fue desarrollado por Linus Torvalds exclusivamente para el desarrollo de Linux, luego dejándolo libre para su uso indiscriminado. La historia es algo humorística, ya que, en pocas palabras, Linus decía que todos los sistemas de control apestaban de una forma u otra, y quiso hacer algo que fuera bueno de verdad. Quizá no estén de acuerdo con que sea tan superior, pero tienen que aceptar que es realmente radical. Si no saben por qué, sigan leyendo.
Con su primer release en el 2005 y ganando más popularidad en la actualidad, Git ha probado ser eficiente y un buen recurso para el control de versiones. Mejor aún, para el programador.
De qué va a tratar esto
Soy un novato todavía, pero quiero compartir mis pequeños avances con Git como para que los demás puedan aprender conmigo. Suelo trabajar mucho en Windows y si bien mis primeras experiencias fueron con Git Extensions, al final el uso de la consola terminó siendo mucho más efectivo. Git Extensions mismo viene con una consola y si están en Linux, hay versiones de Git de sobra que pueden utilizar.
Nuevamente, decía que soy solo un novato por ahora, y si bien creo tener razón en lo que voy a afirmar, entiendo que puedo estar totalmente equivocado. Sientansé libres de contactarme y corregirme. Estoy dispuesto a hacer crecer esto todo lo que sea necesario, o de hacer muchas entregas como para aportar información interesante. No sé en qué terminará esto, pero mientras más informativo, mejor.
La filosofía de Git
Git, a diferencia del resto de los sistemas de control de versiones, funciona de una forma tan granular que nos permite generar nuestro propio proceso en lugar de adaptarnos a un proceso estándar. Hay quienes prefieren trabajar de alguna forma y quienes prefieren trabajar de otra, pero una vez que se entiende bien la filosofía de Git, es todo , en el fondo, lo mismo. Comencemos.
La filosofía de Git, en pocas palabras, es de apartarse del trabajo diario del programador (o diseñador, o lo que sea que hagamos) y dejarnos hacer nuestro trabajo. Git se encargará, cuando se lo indiquemos, de identificar las diferencias, y de convertirlas en cambios graduales que querremos versionar de forma conjunta o de forma separada. Cambiar un archivo dos veces no implica un único cambio. Cambiar varios archivos no implica cambios separados. Todo queda a nuestra discresión.
Y eso es parte de lo importante: Git nos permite hacer nuestros cambios de una forma “ordenada” y hasta semántica. (Me gusta mucho últimamente esa palabra.) Podemos dar determinado significado al progreso de nuestros cambios, de forma que tengamos controlado cuando podemos volver atrás y cuándo podemos seguir adelante. Cabe destacar que ambos son posibles en cualquier punto de nuestro trabajo. Más adelante se darán cuenta de por qué digo esto.
Para aquellos que estábamos acostumbrados a VSS, TFS o SVN, nos daremos cuenta de que es algo distinto. Quizá los que usaban SVN desde la consola lo encuentren, en algo, similar, pero la filosofía en la que se manejan los cambios es totalmente distinta. Se darán cuentas que cosas que por lo general son imposibles de hacer, son totalmente naturales, y de hecho, se hacen todo el tiempo. Esa es, en pocas palabras, la filosofía de Git: No ponerse en el camino del programdor. Ser una herramienta, no un obstáculo.
Un sistema distribuído
Distribuído, cloud computing y todo lo demás es un término exageradamente abusado hoy en día. Todos sabemos las ventajas que esto tiene y en general por qué convienen (o por qué no). En el caso de Git, es realmente una ventaja, y no tenemos por qué sufrirla si un sistema distribuído no nos conviene.
Que Git sea distribuído significa que no hay ningún repositorio central, ninguno vale realmente más que otro. Por supuesto, muchas veces nuestra organización hace que hagamos de uno de ellos el repositorio central, pero cualquiera de ellos podría hacerlo, y esto significa que los repositorios centrales también pueden invertir su rol de a ratos. Supongamos que Alice y Bob se copian un repositorio central de Carlos (esto se llama clonar). Ambos trabajan sobre A y B, pero Carlos también sigue trabajando en C. Si Bob quiere obtener la última versión de todos ellos (así convirtiéndose en un repositorio central por un momento), sólo tiene que “jalar” los datos (pull) desde los repositorios A y B. Cualquiera de ellos puede hacer lo mismo.
Mejor aún, con los permisos necesarios, cualquiera de ellos puede “empujar” cambios (push) a los otros repositorios. Claro, que si no hubiera reglas, todo sería un descontrol, pero Git nos permite acomodar la organización como mejor queramos. Los repositorios son gratis, ocupan poco espacio y pueden clonarse infinidad de veces.
Se imaginan que con una característica tal, cada repositorio copia es, en cierta forma, un backup del repositorio central (o del que designemos como repositorio central). Cada cambio puede pasar por un proceso separado y por una cantidad de repositorios distinta hasta llegar a estar presente en todos lados. “Qué desastre!”, pensarán. Y eso les comienza a dar la idea más importante: Git es una herramienta muy avanzada, podemos realmente hacer desastres catastróficos con ella, pero también podemos hacer procesos elegantes y simples, sin comprometer las necesidades.
Un ejemplo real: en un proyecto en el que actualmente estamos trabajando, A, B y yo (yo seré C), tenemos un repositorio central en GitHub, online. Cada uno de nosotros tiene su fork (copia) del mismo repositorio también en GitHub, y a la vez, cada uno de nosotros tiene una copia local. Todos trabajamos en la copia local, hacemos nuestros branches, commits, etc. Cuando es necesario, empujamos nuestras cosas a nuestro repositorio de GitHub, de forma que ambos están sincronizados. Cuando el momento es el apropiado, enviamos pushes al repositorio central. Cada uno de nosotros tiene acceso al repositorio central de la misma forma que al suyo, lo cual permite muchas veces arreglar errores del pasado (sí, Git permite eso) pero en general, esta estrategia ayuda a sincronizarnos. A veces trabajamos trayendo y llevando cosas entre nuestros repositorios, sin uso del central, hasta que una característica esté lo suficientemente madura.
Dejo esto por ahora. Prefiero hacer los posts cortos y que sean muchos, a que sean grandes, largos y nadie los lea.
Soy un zorrinito distribuído.
Pro ASP.NET MVC3 Framework
Acabo de terminar de leer Pro ASP.NET MVC3 Framework, un libro de Apress, escrito por Adam Freeman y Steven Sanderson. En pocas palabras, el libro es muy bueno, no exageradamente detallado pero buena aproximación para quiénes quieran ganar un nivel principiante/intermedio en la plataforma. Determinadas características han quedado afuera, y por supuesto, detalles de la implementación del framework también. Eso habría sido material para una buena cantidad de otros libros. Este en particular está muy orientado al ejemplo práctico, y es ideal para afianzar teoría con pequeños snippets de código que la hacen práctica. Cubre algunos aspectos relacionados a esto para darle un buen contexto y es una buena opción por su precio, pero no es suficiente para el que quiera entrar demasiado profundo en los interiores de la plataforma.
El libro se divide en tres grandes partes. La primera parte, llamada Introduciendo ASP.NET MVC 3, es una explicación muy a vuelo de pájaro de qué es MVC, cómo es la aproximación de Microsoft a él y unos ejemplos básicos para demostrar la organización de una aplicación MVC. Se habla un poco de inyección de dependencia, haciendo uso de Ninject, pero su aplicación es de lo más básica y no justamente asociada a las buenas prácticas, aunque como primer paso, es bueno. Habla de DDD y de TDD, ayudado de Moq, desde un punto de vista tan superficial que no hacen impacto en el resto del contenido, pero siguen estando ahí.
La segunda parte del libro, ASP.NET MVC3 en Detalle, comienza a hablar del sistema de ruteo, de cómo se enlazan a él los controladores y las acciones, el uso de filtros (casi tocando AOP para controladores, pero no mencionándolo), uso de controladores propios, autorización, generación de un engine propio de vistas, uso de helpers, vistas parciales, acciones hijas, templates de modelos, binding de modelos, validación, AJAX, y el uso de jQuery. En estos últimos dos puntos debo hacer una aclaración: la forma en la que se implementa AJAX es todavía muy Microsoft-oriented, del estilo de hacer una receta y que todo funcione de forma mágica. Se queda muy corto para customizaciones y aplicaciones reales con lógica de cliente compleja, pero recordemos que este libro es sobre ASP.NET MVC, no sobre JavaScript. Aún así, es un buen comienzo para profundizar en otro libro.
La tercera y última parte, Entregando Projectos ASP.NET MVC 3 Exitosos, cubre varios puntos extras no exactamente de a la plataforma pero relacionados. Uno de ellos es la seguridad. Se le dedica un capítulo entero a determinados tipos de ataque y forma de evitarlos. Como los otros temas tangenciales, no es una guía definitiva, pero un buen punto para comenzar. Otro capítulo está dedicado a la autenticación y la autorización, sin mucho detalle y sin mucho ejemplo esta vez, pero pasos básicos que nos permiten conocer varias opciones distintas para las distintas situaciones que debamos afrontar. El último capítulo de esta parte se enfoca en el deployment y la generación de paquetes de instalación. Nuevamente, no contiene mucho detalle.
El libro en general es bueno como introducción y bueno como ejercicio de aprendizaje. Es detallado en el comienzo y light al final, con lo cual sus 836 páginas en realidad son un resumen de mucho más que podría cubrirse. Es un balance apropiado, con lo cual recomiendo su lectura. Le otorgo unos 4 zorrinitos.
Principios Universales del Diseño
Partiendo desde la base de lo básico
Este es otro de esos encuentros que hago en los foros de StackExchange, específicamente en el de User Experience. Aquí alguien preguntó ¿Cómo es que los bordes redondeados afectan la usabilidad?
La pregunta estaba orientada al saber el por qué los bordes redondeados son algo deseable, y de qué forma afectan a nuestra experiencia de una página web. Al mismo tiempo, también pregunta por qué la mayoría de los sitios permite que estos bordes aparezcan no-redondeados en versiones viejas de algunos navegadores, si es que es una característica tan importante.
La respuesta más votada habla de la psique humana y cómo el ser humano responde de forma más amigable a objetos redondeados. Hizo una referencia muy interesante también, basándose en el libro Universal Principles of Design, un libro que analiza desde lo más básico la experiencia de usuario en mundos más allá de la informática (incluyéndola también). Mostrando cosas como desde el diseño de juguetes, al diseño de menúes y pasando por el diseño de elevadores, este libro parece ser una de esas joyitas que iluminan más el por qué que el cómo hacemos lo que hacemos todos los días.
Soy un zorrinito especulativo.
GoMo
La iniciativa mobile de Google
Gracias a i.MicroSiervos me enteré de GoMo, una aplicación web que toma nuestro sitio y nos analiza de forma personalizada las características del mismo y nos da sugerencias para pasar al mundo mobile. Cosas como la visibilidad de la página, los links, las tecnologías utilizadas y demás, está todo disponible en un reporte de forma gratuita.
Cabe destacar que este sitio es en realidad una iniciativa de Google, con lo cual gana un poco más de renombre.
Les recomiendo también visitar el mismo sitio desde un dispositivo movil, la enorme diferencia con el sitio original realmente habla de tomar una aproximación diferente al momento de pensar en mobile.
Soy un zorrinito móvil.
Udacity
Otra iniciativa más de enseñanza online
Me encontré como noticia en ALT 1040 que Sebastian Thrun dejó Stanford para comenzar su propia iniciativa de enseñanza online, llamada Udacity. En este preciso momento se están enseñando sólo dos cursos: Cómo construir un auto que se maneja solo y Cómo construir un motor de búsqueda. Ambos están dados por Thrun y el del motor de búsqueda está también asociado con David Evans.
Se vienen nuevos cursos durante este año, que también parecen ser muy interesantes, como Sistemas Operativos, Sistemas Distribuidos, Redes, Seguridad, Algoritmos y estructura de datos, Prácticas de Ingeniería de Software, Construir aplicaciones web, etc. Nombré los cursos que están nombrados en la página al día de hoy, pero quién sabe qué traerá el futuro. Parece que por hoy está teniendo mucho éxito.
Soy un zorrinito estudioso.
Jugando con la productividad
Conseguí una lapicera dorada +20!
La gamification (…jueguización? ugh) es algo muy común y popular en estos días para aplicar a distintas actividades, y alguien en Productivity de StackExchange decidió preguntar si existen técnicas de productividad basadas en juegos. Desafortunadamente las respuestas no son muchas y no hay demasiadas opciones, pero las pocas que hay son iluminadoras.
Uno es el caso de EpicWin, una aplicación de iPhone que en base a las tareas que uno completa va ganando puntos de experiencia y subiendo su nivel, obteniendo items, y equipando así a un personaje. Sus contrapartes en el Android Market son Task XP y RLRPG.
Hubo alguien que utilizó automatización sobre su inbox para generar gráficos de productividad. Muy seguramente esté trabajando bajo la premisa de Inbox Zero, también muy útil para tener la mente y el inbox limpio.
Alguien más se basó en Pomodoro y creó un juego integrado en su sistema de tiempos. Mantiene una wishlist de cosas que le gustaría comprarse, pero sólo se lo permite cuando, tras terminar una tarea, su oportunidad de tirar los dados le favoreció. No gana todo el tiempo, pero mientras más tareas haga siempre va a tener una oportunidad extra, aumentando las posibilidades.
Soy un zorrinito jugador.
Naked password
yeaaah, venga esa complejidad!
De los rincones recónditos de User Experience en StackExchange y una pregunta de cómo incitar a los usuarios a poner passwords fuertes, me entero de la existencia de Naked Password, un plugin de jQuery que en sitios informales (muy informales) incentiva a los usuarios a usar passwords complejos, de forma… digamos… “natural”. Pueden probar el demo en su misma página.
Dicho sea de paso, otras buenas respuestas fueron:
- Asustar al usuario (mostrando en cuánto tiempo se podría crackear su password)
- No hacer nada (considerando la mejor experiencia general, que el usuario decida como más quiera)
- Recompensarlos con características extras (por ejemplo, funcionalidades en beta)
Soy un zorrinito de poca complejidad.
wkhtmltopdf
De HTML a PDF
Nombre complicado, pero aplicación muy útil. Hace algunos días ando trabajando con wkhtmltopdf, una aplicación basada en QT y en Webkit que renderiza páginas web y las convierte en PDFs. Lo interesante es la forma en la que se puede automatizar este proceso, generando elementos más allá del contenido en sí (como tablas de contenido, encabezados y pies de página, etc). Mejor aún, este paquete contiene wkhtmltoimage.
Por supuesto, todo esto puede ser parte de una aplicación mayor que genere PDFs o imágenes desde otro documento (luego publicaré algo sobre eso) basándose en un proceso automatizado. Parece que es muy comùn que aplicaciones utilicen esto de fondo para generar screenshots de páginas web o reportes PDF desde un HTML.
Soy un zorrinito screenshoteado.
dnndev.me → 127.0.0.1
Dominio para desarrollos locales
En geeks.ms (via los enlaces interesantes de VariableNotFound) publicaron un artículo/tip/huevo de pascua (no lo considero un huevo de pascua) sobre dnndev.me, un dominio registrado y apuntando sus entradas DNS a 127.0.0.1. La idea detrás de esto es que los desarrolladores puedan utilizarlo para no modificar sus entradas en el archivo hosts. El nombre del dominio viene realmente de DotNetNuke Development, que es la razón que llevó a registrar este dominio. Yo me hubiera conformado con un localhost.com, o loopback.me, o algo así.
Realmente no es tan útil si uno sabe cómo editar los archivos de host, pero – y acá lo interesante – muchas veces no tenemos accesos de administrador para lograrlo, y en ese caso es en donde necesitamos un DNS que nos devuelva 127.0.0.1 para estas cosas. Ahí es donde esto se vuelve realmente útil.
A ver quién tiene una idea similar y registra dominios para apuntarlos a direcciones de redes C. No les gustaría ir a 192-168-0-1.my.net y que tengan acceso a su router? Mejor aún, podrían usarse alias en subdominios para IPs conocidas dentro de las redes. linksysrouter.my.net, broadcast.my.net, etc. ¿Quién será el valiente?
Soy un zorrinito cobarde.
SOPA, PIPA, y MEPA que se están equivocando
El problema es la receta, no la sopa.
Hace mucho que todos estamos siendo bombardeados por la historia de esta ley que casi sigue su curso, pero hay un tema en particular que no veo nombrar y que creo es el más importante. Es como si todos se quejaran de un dolor de cabeza pero no se preguntaran por la enfermedad, sino sobre como quitárselo.
Esta es mi (humilde e ingenua) opinión al respecto.
¿Por qué SOPA tenía sentido?
(Antes de matarme, por favor lean lo que tengo para decir.)
Creo que el argumento de que los senadores no entienden de tecnología como excusa para decir que la ley no tiene sentido es un poco simplista. Puede que no haya sido una buena idea, pero estas cosas se piensan antes de convertirse en propuesta. Dejando de lado que esto puede haber sido algo que surgió de las empresas multimediales, la ley tenía un sentido práctico: detener la piratería.
Muchos critican que la ley era dirigida a regular a quienes permiten los accesos a la piratería más que a la piratería en sí. Eso también tiene sentido. Cuando el asesino serial no hizo caso a la ley de “no matar”, hay que asegurarse que nadie lo ayude. Si drogarse fuera ilegal, vender droga también lo sería, es natural pensar que si la piratería es ilegal, llevar a piratería también lo sería.
Por otro lado, los comentarios que he visto al respecto muestra muy poco conocimiento sobre las leyes de copyright. Las leyes de propiedad intelectual están muy claras y son vigentes. Esta ley no era nada nuevo en cuanto a qué regulaba, era nuevo en cuanto a quién estaría obligado a reaccionar y las medidas a tomar. (Más un par de detalles que a drede voy a dejar fuera.) En resumen, la ley decía “tomemos más seriamente las leyes que ya tenemos”.
¿Por qué SOPA no tenía sentido?
El problema de SOPA estaba más allá de SOPA, y esto es lo que veo que muy pocos dicen. El problema de SOPA era el copyright en sí mismo, pero cuando SOPA iba a aplicar esas reglas “de a de veritas”, todos nos preocupamos.
El problema con las leyes de la propiedad intelectual es que crean una propiedad sobre elementos que no pueden ser reclamados ni robados. Para hacerlo aún más obvio: reclaman propiedad en donde no se puede reclamar propiedad.
El mundo de a poco ha reaccionado un poco a esto haciendo de las licencias libres algo muy natural en entornos en donde no se puede ganar esa pelea. El software es un campo de batalla que el open source está ganando de a poco. (El modelo as a Service no probó ser rentable de casualidad.) La música y las películas es una batalla que el propietarismo ya perdió pero que resiste a retirarse.
Propiedad intelectual y derechos de propiedad
Tuve una charla con un colega al que le expliqué mi punto de vista de esta forma: ¿Qué es una canción, si no un montón de ruidos juntos? ¿Podemos decir que alguien es dueño de ese ruido y nadie más debe poder usarlo? ¿Los libros, un manojo de palabras?
Por supuesto, la respuesta de esta persona fue muy apropiada: hacer música cuesta dinero, tiempo y aprendizaje. Hacer libros requiere también tiempo, dinero, investigación, edición, etc, etc. ¿Cómo fomentar la cultura si esta gente no recibe dinero por lo que hace?
Y mi respuesta es que lo que esta gente vende no es ni ruido ni palabras, es lo extra que todo eso tiene. Uno no escucha música porque sí, sino que uno la experimenta y la disfruta (como todo arte, lo que se vende es el sentimiento – incluso aunque sea un resultado de una fórmula marketinera). Un libro no es un montón de palabritas juntas, sino la información extra que aporta. Lo que compro cuando compro algo de eso no es el material ni el medio (que, según la ley de copyright, no deben tener dueño), sino el ahorrarme tener que hacerlo yo. Estoy comprando trabajo pre-hecho.
En ese sentido, este trabajo es un trabajo como cualquier otro. Quienes escriben libros deben poder vivir de ello, quienes hacen música deben poder vivir de ello. Pero como un trabajo justo, debe pagársele por su trabajo, nada más. Su éxito es un resultado de qué tan bien está hecho su trabajo. Recuerden: cultura. La comercialización no es algo malo, pero ese es otro trabajo. Si lo que queremos es que alguien talentoso haga un buen trabajo, hay que mantenerlo bien pagado mientras ese trabajo se hace, no cuando ya está hecho. Hay que recompensar el buen trabajo, no el buen descanso.
Una vez hecha la obra, vale tanto como su material, porque ya no hay nada más que debería pagarse. ¿O acaso solo los que tienen dinero deben acceder a nueva información? ( ¿Es así como fomentamos la cultura?) Si el medio no vale nada, la obra en el mercado no debería valer nada. La piratería es la respuesta natural del mundo a eso.
Quiénes exigen que el copyright se pague caen en una de las siguientes categorías:
- Parásitos: son los que quieren trabajar una sola vez, hacerse famosos y vivir de los que eso les de. Si de verdad quisiéramos fomentar la cultura, alguien talentoso debería trabajar más, no menos. Sin discriminar, todos deberían trabajar para pagar sus cuentas. (O nadie… pero esa es otra historia sobre la que no voy a hablar ahora.)
- Narcisistas: exigen reconocimiento. (Yo caigo en esta, pero Creative Commons me da lo mejor de los dos mundos.)
- Multimediales: (esta es la más interesante.) Estas son las empresas que consumen a los artistas y viven de ello. Por supuesto, ellos fabrican, distribuyen, venden, publicitan, etc. Estoy de acuerdo con que ese trabajo se pague… Pero no más que lo que ese trabajo vale. El copyright no tiene nada que ver acá.
La discusión sobre cuánto es lo justo para cada empresa es otra discusión extensa, y creo que abarca más de lo que puedo opinar acá. Pero no, la propiedad intelectual no tiene cabida ahí, solo el trabajo realizado.
¿Y entonces qué hacemos?
Primero, démonos cuenta de que estamos ladrándole al árbol equivocado. El problema no es SOPA ni la internet. El problema es el copyright y lo que estamos pagando.
Segundo, denunciemos las extorsiones de compañías a artistas. Si alguna vez tuvieras la oportunidad, exigí que tu contrato esté libre de copyrights propietarios. Si realmente amás lo que hacés, vas a comprender mis palabras. Si ves que tu copyright ya no te genera dinero, no nos hagas perder el tiempo y cambialo. Si tu película o tu canción ya se pirateó, ofrecé una descarga oficial y promové el modelo pay as you want, donaciones, vendé publicidad o merchandising, etc, etc.
Tercero, prestemos un poco más de atención a las injusticias de la propiedad intelectual que ocurren todos los días y protestemos por eso también. No esperemos a que la ley se tome en serio para darnos cuenta de que estaba mal.
Cuarto, dejemos de actuar como si la cultura fuera algo que nació en internet. Vivimos el 90% de nuestras vidas fuera de él (bueno… algunos un poco menos). Hagamos énfasis en que la libertad esté fuera de él también.