Esenciales 2009
Mar 30, 2009 Articulos
Mark Pilgrim, autor de Dive Into Python (y preparando Dive Into Python 3) hace cada tanto una lista del software que esta usando llamada “Essentials” (la ultima es “Essentials 2008”) en la que enumera las versiones que usa, que tan contento esta y que opciones esta viendo. Me parece interesante de hacerlo porque las herramientas que cada uno utiliza son muy importantes y siempre es bueno hacer una elección pro-activa de las mismas.
Así que acá van los Esenciales 2009 de Angel Freire:
Gentoo Linux, menos contento que otros años, cada ves le encuentro mas problemas de QA, con ebuilds mal hechos y problemas entre las dependencias. Pero aun así y todo sigue siendo la distribución donde me siento mas cómodo, Exherbo es una opción que me esta interesando mucho, aunque como bien dice la página todavía le falta mucho para que sea estable en el día a día.
Vim + snippetsEmu + tabs mapeadas a los mismos keybinds que Firefox + ctags. Trato de ejercitar un poco todos los días y tengo colgado al lado de mi escritorio “The Semi-Official IBM DeveloperWorks ™ Vim Cheatsheet”.
Firefox + Mouse Gestures Redox + Web Developer + Firebug (c/YSlow) + User Agent Switcher + Modify Headers + Xmarks (ex Foxmarks, que reemplazo a Google Browser Sync bastante bien, Weave no funciono nunca). Estoy acumulando ganas para darle una buena oportunidad a vimperator.
Pidgin para casi todo lo que es mensajería, menos para IRC donde irssi dentro de un screen sigue siendo la mejor opción.
Thunderbird para el email + Tag Toolbar + XNote + Buttons! + External Editor, algún día haré un post en este blog explicando como combino todo eso. Pero últimamente me esta llamando mucho la atención usar mutt, ya uso getmail + maildrop así le puedo sacar mas provecho a vim.
gqview para ver imágenes, epdfview para pdfs y OpenOffice para la mayoría del trabajo.
Para música, sigo utilizando mpd, pero estoy empezando a encontrarle el gusto a Exaile. Y en cuanto a películas sigo con (¿el ya obsoleto?) mplayer que cumple su trabajo muy bien.
En cuanto al entorno gráfico, Fluxbox sigue siendo mi elección de WM, tuve un intento con Gnome este año pero no perduro, y aterm como terminal sigue siendo rápida y cómoda, aunque estoy pensando en empezar a usar urxvt ya que en aterm estoy encontrándome cada ves mas con caracteres en unicode que no muestra bien.
Para p2p estoy usando Transmission, el único problema que le encontré es la falta de soporte para RSS, pero con un pequeño script en Python que lea los RSS que me interesan, les aplique regex, y utilice la api de Transmission para que los baje. Soy mas que feliz con esa solución.
Deje de usar gkrellm y empecé a usar conky, no ocupa espacio en la pantalla y me resulta gráficamente mas atractivo.
Como shell zsh me sigue brindando un buen equilibrio entre interactiva/scripteable, probé escribir algunos scripts en ksh pero todavía estoy muy verde, y en la mayoría de los servidores donde tengo que trabajar me encuentro bash así que también tengo que mantener un .bashrc ajustado a mis gustos.
Voy a tratar de hacer este post todos los años para mi cumpleaños, es una fecha fácil para recordar de repasar todo esto 
Tags: 2009, esenciales, software
Ortogonalidad (o “Cada cosa en su lugar”)
Mar 25, 2009 Articulos
Orthogonality means that features can be used in any combination, that the combinations all make sense, and that the meaning of a given feature is consistent, regardless of the other features with which it is combined. The name is meant to draw an explicit analogy to orthogonal vectors in linear algebra: none of the vectors in an orthogonal set depends on (or can be expressed in terms of) the others, and all are needed in order to describe the vector space as a whole.
Programming Language Pragmatics, Michael Scott, Morgan Kaufmann 2000
Ortogonalidad (en ingles Orthogonality) es una filosofía del diseño de sistemas que propone dividir de forma clara las distintas funcionalidades de estos, haciendo que estas funcionalidades no se pisen entre si y que compartan la mínima cantidad de código. El objetivo subyacente es el de evitar que cambios en alguna de las secciones de un programa repercuta en otra sección.
El nombre del concepto viene de la geometría, y en el desarrollo de software se adapta su significado para formar una metáfora que resalta la independencia, tanto en código como en utilidad, de dos componentes distintos de un mismo sistema.
Eric Lippert, diseñador de lenguajes en Microsoft (de los buenos, no de los otros) hizo un post en el 2005 sobre ortogonalidad titulado “Five-Dollar Words for Programmers, Part Two: Orthogonal”, en el definió el concepto de la siguiente manera:
Imagine for instance that you were trying to describe how to get from one point in an empty room to another. A perfectly valid way to do so would be to say how many steps to go north or south, and then how many steps to go northeast or southwest. This hockey-stick navigation system is totally workable, but it feels weird because north and northeast are not orthogonal — you can’t change your position by moving northeast without also at the same time changing how far north you are. With an orthogonal system — say, the traditional north-south/east-west system — you can specify how far north to go without worrying about taking the east-west movement into account at all.
Nonorthogonal systems are hard to manipulate because it’s hard to tweak isolated parts. Consider my fish tank for example. The pH, hardness, oxidation potential, dissolved oxygen content, salinity and conductivity of the water are very nonorthogonal; changing one tends to have an effect on the others, making it sometimes tricky to get the right balance. Even things like changing the light levels can change the bacteria and algae growth cycles causing chemical changes in the water.
Con este ejemplo Lippert deja en claro lo difícil que son de mantener los sistemas no-ortogonales donde la modificacion de un punto de un programa afecta a otras partes de este sin saberlo.
Otro ejemplo claro es el que da Dave Thomas con su analogía del helicóptero:
A helicopter has four main controls: foot pedals, collective pitch lever, cyclic, and throttle. The foot pedals control the tail rotor. With the foot pedals you can counteract the torque of the main blade and, basically, point the nose where you want the helicopter to go. The collective pitch lever, which you hold in your left hand, controls the pitch on the rotor blades. This lets you control the amount of lift the blades generate. The cyclic, which you hold in your right hand, can tip one section of the blade. Move the cyclic, and the helicopter moves in the corresponding direction. The throttle sits at the end of the pitch lever.
It sounds fairly simple. You can use the pedals to point the helicopter where you want it to go. You can use the collective to move up and down. Unfortunately, though, because of the aerodynamics and gyroscopic effects of the blades, all these controls are related. So one small change, such as lowering the collective, causes the helicopter to dip and turn to one side. You have to counteract every change you make with corresponding opposing forces on the other controls. However, by doing that, you introduce more changes to the original control. So you’re constantly dancing on all the controls to keep the helicopter stable.
That’s kind of similar to code. We’ve all worked on systems where you make one small change over here, and another problem pops out over there. So you go over there and fix it, but two more problems pop out somewhere else. You constantly push them back—like that Whack-a-Mole game—and you just never finish. If the system is not orthogonal, if the pieces interact with each other more than necessary, then you’ll always get that kind of distributed bug fixing.
The funny thing about the helicopter story is that I’m not a helicopter pilot. When I wrote the helicopter story, I wanted to make sure it was accurate. I knew of a USENET group on helicopters, so I posted the helicopter story saying, “This is what I’m intending to write about how helicopter controls work. Is it correct? A helicopter pilot emailed me and said, “I read what you wrote about controlling helicopters. I didn’t sleep all night.”
El ejemplo del helicóptero es un clásico al explicar ortogonalidad, de hecho Thomas vuelve a usar esta analogía en el libro The Pragmatic Programmer (Andrew Hunt y David Thomas, Addison-Wesley 1999), creo que la encuentra bastante efectiva para explicar la idea.
¿Alguna ves les paso tener un sistema donde un cambio en una función o clase tuvo efecto en otro extremo del programa, aun cuando no parecían estar relacionados en nada? Ese es un ejemplo de sistema-no ortogonal.
El logro de los sistemas ortogonales es que eliminan efectos entre elementos de nuestros programas que no están relacionados. La separación y buena encapsulacion facilitan mucho el poder programar sobre seguro, sabiendo que los cambios hechos solamente van a afectar las partes del programa que estamos modificando.
Otro beneficio de los sistemas ortogonales es que facilitan reutilizar el código. Si el código es realmente independiente del resto del sistema y no depende de otros elementos es muy simple la tarea de aislarlo en su propio modulo y reutilizarlo en otros programas.
También los sistemas ortogonales son fáciles de tededear (Lease diseñar/programar con Test Driven Development mas conocido como TDD y pronunciado tedede): Unit test y test funcionales pueden ser aplicados a secciones mucho mas limitadas (menos variables y condiciones extraordinarias), permitiendo que estos tests sean claros y mas confiables.
Yo tuve una experiencia muy grata participando del equipo que diseño y programo el reemplazo del sistema para edición y envío de noticias por SMS donde trabajo. Primero una pequeña descripción del sistema viejo:
Era monolítico. Se basaba en dos bases de datos, una que tenia los usuarios subscriptos al servicio, y otra que tenia los horarios de envío, las noticias a enviar, las noticias enviadas, y los distintos canales en los que se organizaban esas noticias. También los programas que cargaban datos en esas bases estaban viciados de no-ortogonalidad: Compartían funciones de formas no-directas (marcaban un campo en la base de datos, o un archivo en disco, o un registro en el registro de Windows). De mas esta decir que el sistema era inmantenible, estuvo funcionando mal durante varios años antes de que se planteara reemplazarlo. Y aun así cuando se lo hizo fue difícil hacer un relevamiento de que hacia exactamente para poder empezar a hacer un nuevo sistema.
Para el sistema nuevo nos pusimos como objetivo que sea ortogonal. En ese momento no conocíamos el concepto por su nombre, llamábamos al diseño “modular”, pero la definición de ese objetivo coincidía con la de ortogonal. Separamos las distintas funcionalidades del sistema en partes bien definidas, que de hecho eran programas separados y tenían su propia base de datos, código, y en algunos casos hasta lenguajes de programación distintos. El resultado final fueron varios sistemas: Uno mantiene los subscriptos a los servicios. Otro tiene un editor de contenidos web. Un tercero mantiene los horarios de envío. Y finalmente un “enviador” que consulta esas tres fuentes de datos y envía las noticias en el momento correcto a los usuarios que así lo desean.
No existe punto de comparación entre la complejidad de los dos sistemas. El viejo, no ortogonal, tenia muchas mas lineas de código y llevaba mas tiempo mantener a los programadores a cargo. Su diseño no-ortogonal hacia confuso cuando algo fallaba: No se sabia por donde empezar a buscar. El nuevo funciona en horario, es mucho mas claro que falla cuando hay algún error y requiere de muchas menos horas-hombre para mantenerlo ¡y extenderlo!. Aparte, como beneficio del diseño ortogonal, los nuevos sistemas se utilizan para otras tareas que la de envío de SMS; como la base de datos de subscriptores que ahora tiene usuarios de otros sistemas.
La ortogonalidad también tiene sus críticos, Ian Bicking en su articulo “Orthogonality is Pretentious” propone que el diseño de lenguajes de programación ortogonales puede resultar en varios problemas, como Ravioli Code donde terminan existiendo miles de pequeñas funciones no relacionadas entre si (¿Alguien dijo PHP?).
Finalmente esta ha sido llamada una de las “Five Dollar Programming words”, es decir uno de esos conceptos que al tener un nombre se vuelve mas fácil el ponerlos como un objetivo.
Tags: conceptos, orthogonality, ortogonalidad
Sobre editar…
Mar 22, 2009 Articulos
Developers still spend a lot of time with plain text. No matter how many wizards and other sorcerers we develop most coding is still in plain text. Most of the information you keep should also reside in plain text because you never know if the tool you are using will be around in five years. It’s a good bet that you’ll be able to read plain ASCII (and probably Unicode) for the next century or so.
The Productive Programmer, Neal Ford y David (FRW) Bock, O’Reilly 2008
El editor de texto es quizás la mas preciada de las herramientas para un programador. El código de cada uno de los programas y scripts que escribimos esta en texto plano, y como bien dice la cita anterior incluso los datos que manipulan esos programas están de alguna forma en texto plano también.
¿Pero le damos la importancia que merece? Como programador, en un día normal, si excluyo las reuniones y conferencias telefónicas, el resto del tiempo, estoy frente a un editor de texto o un navegador web, rara ves me enfrento con herramientas que no reciban datos a través del teclado. Esto da la pauta de lo mucho mejor que se puede programar si se utiliza bien el editor de texto. Hasta llegue a leer en algunos artículos de distintos blogs sobre que al entrevistar gente para puestos de IT una de las preguntas que no puede faltar es “¿Que editor de texto usa?” (Por cierto, las respuestas “validas” que daban los autores eran Emacs, Vim y Textpad).
Bram Moolenaar, autor de vim en su charla de Google Edu sobre como editar texto de forma efectiva distingue tres pasos para ser mas efectivo:
- detect inefficiency
- find quicker way
- make it a habit
Son tres pasos muy simples, que imponen una curva de aprendizaje bastante alta, dado que al principio vamos a encontrar muchas insuficiencias en la forma que editamos texto, y de hecho hasta tengamos que cambiar el programa que usamos para encontrar mejores formas de hacer las tareas diarias.
El mismo Moolenar tiene un muy buen texto “Seven habits of effective text editing” en el que distingue varios puntos en los que uno tiene que poder contar con su editor de texto para ser efectivo:
- Move around quickly: Navegar el texto de forma cómoda, sin depender del mouse o teclas que se ubican lejos de la posición normal de las manos en el teclado (como pageup/down y las “flechitas”).
- Don’t type it twice: Poder tener varios textos copiados en varios clipboards y elegir cual pegar, facilitar elegir donde va a ser pegado el texto, permitirme hacer tareas como reemplazar X palabra en el texto que pegue, etc.
- Fix it when it’s wrong: “typos” es uno de los tipos de bugs mas faciles de cometer y donde el editor de texto te puede dar mas ayuda.
- A file seldom comes alone: ¿Que programa mas o menos complejo ocupa un solo archivo de codigo fuente? La habilidad de editar mas de un archivo a la ves es obligatoria.
- Let’s work together: El editor en si es solo una parte de todo el arsenal de herramientas para modificar texto, ¿Para que hacer que el editor ordene alfabéticamente algo cuando ya tengo sort? ¿Para que hacer una compleja función de buscar en todos los archivos del directorio cuando ya tengo grep?
- Text is structured: Que el editor nos ayude a mantener la estructura del texto/código, como la identacion en Python (si usas espacios que te autoidente con espacios, si usas tabs con tabs), que te avise cuando no cerraste una llave en C, o si tenes un end sin begin en un bloque de Ruby).
- Make it a habit: Encontrás la mejor forma de hacer una tarea, sabes que te ahorraste 10 o mas pasos que hubieras tenido que hacer para obtener el mismo resultado de otra manera: ¿Vas a tirar ese conocimiento a la basura? Editar texto es algo que aprendes y mejoras todos los dias y no tenes por que perder ese conocimiento cuando pases a trabajar en otro lenguaje o en otro sistema operativo, utiliza un editor que te permita abstraerte de esa particularidad y lo tengas disponible en cualquier lado.
En su libro “The Pragmatic Programmer” (Addison-Wesley 2000) Andrew Hunt y David Thomas distinguen tres grandes puntos al momento de elegir el editor: Configurable, Programable y Extensible.
Configurable: hace referencia a la capacidad de editar cosas como los colores, tipografía, y apariencia en general. Suena trivial pero como aclare antes la mayor parte del tiempo que uno pasa frente a la computadora programando lo hace en frente del editor de textos, es muy importante que luzca amigable, cómodo, y nos permita resaltar las cosas que nos importan.
Hay un viejo tip entre programadores que dice que cosas como los “magics numbers” (números dentro del código que aparezcan directamente en las funciones y no declarados en una variable o constante cuyo nombre nos ayude a identificar la razón de la misma) deben resaltarse con un color chocante, que salga del esquema de colores al que estamos acostumbrados hasta si se quiere decir así “se vea feo”, para que tratemos de tener la menor cantidad (o si es posible ninguno) de ellos.
Programable: Muchas tareas que hacemos cuando escribimos texto responden a un patrón, y la mayoría de esos patrones podemos programarlos para que el editor de texto lo haga por nosotros. Extender el editor con un lenguaje de scripting como Python o Perl puede resultar muy útil cuando trabajamos, a veces invertir 10′ en una pequeña extensión nos ahorra horas. Hay editores que tienen su propio lenguaje de scripting, otros que utilizan lenguajes conocidos (Emacs con Lisp), y otros que brindan ambas opciones (Vim tiene bindings para Python, Perl y Ruby, y aparte tiene su propio “lenguaje”).
Extensible: Aparte de la configuración y las opciones, esta el hecho de poder extenderlo mas allá del uso que le damos hoy, en este punto es difícil distinguir una buena herramienta que este preparada “para lo desconocido”, pero nos ayuda mirar al pasado y ver que editores como vim, emacs, y otros han sido usados para APL, C, Pascal, y después se adaptaron a lenguajes como Ruby y Perl sin mayores cambios.
¿Como elegir un editor? Joel Spolsky tiene el “The Joel Test” donde habla de 12 pasos a seguir para tener mejor codigo y en el punto 9 dice “Las mejores herramientas que el dinero pueda comprar”, y si bien coincido con la idea que el gasto en herramientas y programas para que los equipos de programadores trabajen mejor y mas cómodos se traduce en mejor código, en el caso del editor de texto encontré, en mi experiencia, que los mejores son gratuitos.
Las funcionalidades de editores como Vim y Emacs no estan en Ultraedit, Textpad o BBEdit, existen varios comparaciones de editores, y como la mayoría de las comparaciones suelen estar viciadas por quien hizo la comparación, así que un buen criterio el que puede dar una fuente neutral de información como Wikipedia.
Les dejo a ustedes la tarea de elegir uno, pero el desafió es hacerlo conscientemente, no dejar que el entorno en el que trabajan o el lenguaje de programación que usan elija las herramientas con las que tienen que lidiar a diario. Me gustaría leer sobre su elección en los comentarios.