Páginas

20150805

Más allá de Ruby: Formas fáciles de volverse un programador políglota

Aprender varios lenguajes de programación es cada vez más fácil e útil. Si usas Java, Ruby o JavaScript, puedes utilizar en tus proyectos lenguajes compatibles que te ofrecen ventajas cómo una sintaxis más amigable o un mejor diseño de sus características.

Pero, ¿cómo lograrlo cuando no tienes tiempo por las tareas del trabajo? Para comenzar, puedes aprovechar cuando tengas que realizar pequeñas tareas no-criticas, especialmente si:

* Usan arquitecturas con modelos publicar-suscribir u orientadas a servicios.
Éste tipo de arquitecturas, al conectar sus partes de forma holgada mediante APIs que intercambian mensajes con JSON o protocol buffers, permite que cualquiera de las partes sea intercambiada por otra implementación sin que el resto se percate de ello.

* Suelen crear aplicaciones con Rails.
Rails es un gran framework, pero en la búsqueda de tener herramientas que puedan escalar con mayor facilidad, ha llevado a la implementación de frameworks con la misma filosofía y estilo en otros lenguajes. En Elixir se encuentra Phoenix y en Haskell se encuentra Yesod. Con ambos, los desarrolladores acostumbrados a trabajar con Rails se encontrarán en un ambiente familiar, obteniendo las ventajas de los respectivos lenguajes.

* Tienen que usar JavaScript para cualquier cosa.
Nos guste o no, JavaScript (acompañado de sus detalles) está cada vez en más lugares... afortunadamente, ¡eso no significa que tienes que usarlo todo el tiempo! Muchos buenos desarrolladores han creado formas de compilar el código fuente de otros lenguajes, unos 300+, a JavaScript. Así que, en vez de pelear en el infierno que puede ser el debugging, puedes aprovechar para aprender un nuevo lenguaje que como Elm o ClojureScript.

* Se requiere un programa de un sólo uso.
Hay tareas para las cuales se escriben programas que seguramente quedarán olvidados después de usarlos una vez, como la migración de una base de datos a otra, así que no hay que preocuparse de su mantenimiento. Aprovecha esas oportunidades para hacerlo en un lenguaje de tu interés.

Una vez que te hayas decidido, procura escribir código que no te duela perder. Algo que puedas hacer en un día o dos. Realizar benchmarks para justificar tus cambios de implementación si alguien se acerca a discutirlos. Y finalmente, no te preocupes por los errores (siempre que hayas seguido el consejo de no experimentar con partes criticas), cuando pasen, te buscarán. Aprovecha para preguntar que no les gustó de tu solución.


Ésta entrada es un condensado de la charla «Beyond Ruby: Easy ways to go polyglot», impartida por Wojciech Ogrodowczyk en la edición 2015 de la Poly Conf.


20150608

Una revisión de código sin tus lentes



Ésta entrada es una traducción y adaptación de la titulada «Code Review Without Your Glasses», escrita originalmente por Robert Heaton el 20 de Junio de 2014.


Imagina que eres parte de un equipo de desarrollo con una sabiduría más allá de lo normal y han destinado un día completo sólo para revisiones de código. Sin embargo, después de las dos primeras horas, te das cuenta que has olvidado tus lentes y has estado viendo fijamente coloridos difuminados toda la mañana. ¿Qué puedes hacer?

La respuesta correcta es ir de regreso a casa y obtener tus lentes, ya que se encuentra a sólo 10 minutos caminando y es un día agradable. Pero asume que, en cuanto dejabas tu casa ésta mañana, descubriste que un enjambre de avispas particularmente aguerridas recién había completado la construcción de un nido en el guardarropa donde guardas tus lentes y no se observaban deseosas de ser molestadas. ¿ENTONCES QUÉ?

Ahora la respuesta correcta es, por supuesto, evitar la pena de pretender que estás usando lentes de contacto y recordar que puedes decir mucho de un archivo sin tener que leer su contenido.

Imagen 1
Imagen 1

Podemos acordar que las responsabilidades deben estar absolutamente separadas. Y, por supuesto, cada clase sólo debe ser responsable de hacer una cosa. Pero, éste objeto CreadorDeUsuarios que has construido aquí probablemente está llevando las cosas demasiado lejos. Si esto es todo lo que el CreadorDeUsuarios tiene que hacer, entonces los Usuarios pueden crearse a sí mismos por ahora. De otra forma, lo que era antes un simple Usuario.new innecesariamente se vuelve una infernal pesadilla de  tener que usar grep durante la mitad del camino alrededor del mundo, a través de múltiples pequeños archivos en el momento que quieras cambiar algo o entender que foo está pasando.

imagen 2
Imagen 2

Observando éste largo método disfrazado cómo clase, se ve técnicamente todo muy DRY y no hay nada que pueda ser refactorizado en el sentido literal de la palabra. Pero algo me dice que no usaste pruebas unitarias. Y mientras que, si me das una tarde y algo de café fuerte, puedo trabajar a través de ese bloque de 20 líneas de en medio que es usado para decidir a que usuarios necesitamos enviarles correos, humildemente te sugeriría que metieras en medio un def usuarios_a_enviar_correo para no tener que hacerlo.

imagen 3
Imagen 3

Bien, así que los métodos en ésta clase son mucho más cortos y eso es probablemente un progreso. Sin embargo, haces algo bueno en exceso. Mientras que al intérprete de Ruby no le importan tus continuos saltos entre métodos, pero a la mayoría de los intérpretes humanos le importa. Soy tan feliz cómo cualquiera de deslizarme alrededor del archivo un poco, pero cuando tengo que comenzar a escribir un registro del stack en mi brazo para recordar desde donde llegué, es probablemente tiempo de agrupar y consolidar algunos de esos métodos.

imagen 4
Imagen 4

Veo que estás dispuesto a hacer que ésta clase ocupe exactamente el namespace correcto. Muy bien, crear namespaces es bueno. Pero para el momento en que llegaste al sexto nivel, parece que estás intentando meter mucho en un espacio pequeño. Considera bien dejar de dividir namespaces de forma tan fina (sí, puedo ver que esas dos clases Ayudante podrían tener su propio namespace Ayudante, pero ¿están realmente dañando algo si se colocan en el siguiente nivel arriba?), o desacopla y divide parte del código en un namespace completamente diferente.

Imagen 5
Imagen 5

Explicaciones en comentarios, ¡muy bien! Código que requiere se acompañado de un ensayo de varios capítulos, muy mal.

Imagen 6
Imagen 6
Observa detenidamente al segundo método hacia abajo. Si el método necesita 8 argumentos para saber que tiene qué hacer y cómo hacerlo, ese método está muy sobrecargado. Distribuye la carga y quita algo del peso de sus hombros con una refactorización temprana. Divídelo en dos (o más), o tal vez tiene más sentido pasar algunos de esos argumentos a la instancia en su inicializador. ¿Podrías tú manejar 8 argumentos de forma simultánea? Entonces no esperes que tus métodos lo hagan.

- o -

Así es el cómo hacer una revisión de código cuando has olvidado tus lentes o has estado mirando fijamente el sol por más tiempo del que los médicos recomiendan. Si fuera mejor programando tal vez hubiera podido ofrecer algunos ejemplos mucho más sutiles. Por otro lado, podría argumentar (y tengo la completa intención de hacerlo) que la trivialidad puede ser interesante aveces. Por más claro, simple y bien formado que pueda ser tu diseño, no sirve de nada si lo construyes con lodo y palillos de madera.

20150520

Buenas prácticas para revisiones de código




Ésta es una traducción y adaptación del artículo titulado «Code Review Best Practices», escrito y publicado originalmente por Kenvin London el 5 de Mayo de 2015.


En Wiredrive realizamos bastantes revisiones de código. Nunca había hecho una antes de comenzar a trabajar aquí, así que fue una nueva experiencia. Creo que es una buena idea cristalizar algunas de las cosas en las que me enfoco cuando hago revisiones de código, hablando sobre la mejor forma que he encontrado para acercarme a ellas.

Rápidamente, una revisión de código es una discusión entre dos o más desarrolladores a cerca de cambios en el código para solucionar un problema o agregar una nueva característica.

¿Qué observar al hacer una revisión?


Arquitectura / Diseño


  • Principio de la responsabilidad única: La idea de que una clase debe tener una y sólo una responsabilidad, es más difícil de lo que uno podría esperar. Usualmente también aplico éste principio a los métodos: si se tiene que usar una conjunción «y» para terminar de describir lo que un método es capaz de hacer, puede tratarse de un mal nivel de abstracción.
  • Principio abierto/cerrado: Si el lenguaje usado es orientado a objetos, ¿los objetos pueden ser extendidos pero están protegidos para no ser modificados? ¿Qué pasa si necesitamos agregar un atributo, función o pieza de código?
  • Duplicación de código: Prefiero seguir la regla de los tres  strikes. Si el código está replicado una vez, usualmente está bien aunque no me agrade. Si está replicado más de una vez, debe hacerse una refactorización para separar las funciones comunes.
  • Prueba de los ojos entornados: Si entorno los ojos, ¿la forma de éste código se ve idéntica a otras? ¿Hay patrones que pueden indicar otros problemas en la estructura del código?
  • Código en un mejor estado: Si estoy cambiando un área desordenada del código, es tentador agregar un par de líneas y dejarlo así. Recomiendo ir un paso más allá y organizar el código para dejarlo mejor a cómo lo encontré.
  • Errores potenciales: ¿Hay errores de diferencia por un paso? ¿Los ciclos terminan en la forma que se espera? ¿A caso terminarán?
  • Eficiencia: Si se ha implementado un algoritmo en el código, ¿se está usando una implementación eficiente? Por ejemplo, iterar sobre una lista de llaves en un diccionario es una forma ineficiente de buscar el valor deseado.


Estilo


  • Nombres de los métodos: Darle nombre a las cosas es uno de los problemas difíciles en ciencias de la computación. Si un método es llamado `obtener_nombre_del_mensaje_en_la_fila` y en realidad está hace algo completamente diferente, como sanear el HTML de una entrada, entonces no es un nombre descriptivo para el método y causará confusión.
  • Nombres de variables: `foo` y `bar` probablemente no son nombres útiles para estructuras de datos. De forma similar, `e` no es tan útil comparado con `excepcion`. Se tan explicito como necesites (dependiendo del lenguaje). Nombres de variable expresivos hacen más fácil entender el código cuando se tiene que volver a leer.
  • Longitud de una función: Mi regla del pulgar es que una función debe tener menos de 20 líneas, aproximadamente. Si veo un método de más de 50 líneas, siento que lo mejor es dividirlo en partes más pequeñas.
  • Longitud de una clase: Creo que las clases deben tener menos de 300 líneas en total, e idealmente menos de 100. Es usual que clases muy largas puedan ser separadas en objetos diferentes, lo que hace más fácil entender el propósito de cada clase.
  • Longitud de un archivo: Es algo variable, dependiendo del lenguaje, pero para lenguajes dinámicos como Python, creo que alrededor de 1,000 líneas de código es lo máximo que deberíamos tener en un archivo. En caso de ser más grande, es una buena señal de que el contenido debe ser dividido en archivos más pequeños y enfocados. Mientras más grande sea un archivo, es más difícil encontrar información.
  • Documentación en comentarios: Para métodos complejos, los que su funcionamiento no es obvio o aquellos con una larga lista de argumentos, ¿hay un comentario (docstring) explicando la función de cada argumento?
  • Código comentado: Es una buena idea remover código que ya no se utiliza y que se ha dejado cómo comentarios.
  • Número de argumentos en un método: Para métodos y funciones, ¿tienen 3 o menos argumentos? Más de 3 probablemente significa que pueden ser agrupados de otra forma.
  • Facilidad de lectura: ¿El código es fácil de entender? ¿Tienen que detenerte frecuentemente durante la revisión para descifrarlo?


Pruebas


  • Cobertura de las pruebas: Me gusta ver pruebas para nuevas características. ¿La pruebas indican que se pensó en ellas antes de escribirlas? ¿Cubren los casos en que habría fallos? ¿Qué tan frágiles son? ¿Qué tan amplias son? ¿Son lentas?
  • Pruebas en el nivel correcto: Cuando reviso las pruebas también me aseguro que estén probando el nivel correcto. En otras palabras, ¿están al nivel suficientemente bajo para corroborar la funcionalidad esperada? El desarrollador Gary Bernhardt (Destroy All Software) recomienda una relación de 95% de pruebas unitarias con un 5% de pruebas de integración. Me he dado cuenta que en proyectos con Django, es fácil crear pruebas de alto nivel por accidente, terminando con un conjunto de pruebas lento, así que es importante mantenerse alerta.
  • Número de objetos simulados: Crear objetos simulados (mocks, dobles) es genial, pero simular todo no lo es. Como regla del pulgar, si hay más de tres objetos simulados en una prueba, el código debe ser reestructurado. Puede ser que la prueba sea demasiado amplia o que la función que evalúa sea demasiado grande. Tal vez no necesite una prueba a nivel unitario y con una prueba de integración sea suficiente. De cualquier forma, es algo que se debe discutir.
  • Cobertura de los requerimientos: Usualmente, como la parte final de una revisión, observo los requerimientos de la historia, tarea o bug que dio origen al código. Si no cubre alguno de los requerimientos, es mejor no aceptar el código antes de que sea enviado a QA.


Revisa tu propio código


Antes de enviar mi propio código, hago un `git add` de los archivos y/o directorios afectados, y luego ejecuto un `git diff --staged` para examinar los cambios que aún no he integrado al repositorio. Usualmente busco cosas como:

  • ¿Dejé un comentario o TODO en los cambios?
  • ¿Los nombres de las variables tienen sentido?
  • ...y alguna violación a lo discutido en puntos anteriores.

Quiero estar seguro de que pasaría mi propia revisión de código antes de pedirle a otras personas que lo revisen. También, duele menos recibir comentarios de uno mismo que de otros.

Manejando las revisiones de otros


He encontrado que la parte humana de la revisión de código ofrece tantos retos como la parte técnica. Aún sigo aprendiendo como manejar ésta parte. Aquí presento algunas aproximaciones que han funcionado cuando discuto sobre código:


  • Haz preguntas: ¿Cómo funciona ese método? ¿Si éste requerimiento cambia, qué más tendría que cambiar? ¿Cómo podemos hacer esto más fácil de mantener?
  • Refuerza y felicita las buenas prácticas: Una de las partes más importantes de la revisión de código es recompensar a los desarrolladores por su crecimiento y esfuerzo. Pocas cosas se sienten mejor que recibir el reconocimiento de un compañero. Yo trato de ofrecer la mayor cantidad posible de comentarios positivos.
  • Obtén más detalles en persona: En ocasiones, un cambio en la arquitectura puede ser muy grande y es más fácil discutirlo en persona que a través de comentarios. De forma similar, si la discusión de un punto genera comentarios de ida y vuelta, con frecuencia prefiero retomarlo en persona para finalizar la discusión.
  • Explica el razonamiento: He encontrado que es mejor preguntar si hay alguna alternativa superior y justificar porque es importante arreglarlo. Algunas veces puede haber la sensación de que los cambios sugeridos son superficiales si no hay algún contexto o explicación.
  • Mantén el enfoque en el código: Es fácil tomar de forma personal los comentarios en las revisiones de código, especialmente si nos enorgullecemos de nuestro propio trabajo. No hay que olvidar que las discusiones son acerca de cómo mejorar la calidad del código y no son específicos a los desarrolladores. Esto disminuye la resistencia.
  • Haz notar los cambios importantes: Es común que ofrezca varias sugerencias, pero no es necesario actuar en todas. Aclarar si es importante arreglar un punto antes de considerarlo terminado es útil tanto para quien revisa como para quien somete el código a revisión. Hace los resultados de la revisión claros y de valor práctico.


En cuanto a la mentalidad


Como desarrolladores, somos responsables de crear código funcional y fácil de mantener. Puede ser fácil posponer la segunda parte debido a las presiones para entregar el código. La refactorización no modifica la funcionalidad por diseño, así que no dejes que los cambios sugeridos te desanimen. Mejorar la mantenibilidad del código puede ser tan importante cómo arreglar la línea de código que causa un bug.

Además, recuerda mantener una mente abierta durante las revisiones. Creo que es algo con lo que la mayoría tenemos problemas. Uno puede ponerse a la defensiva porque puede tomarlo personal cuando alguien te dice que tu código podría ser mejor.

Si la persona que revisa el código hace una sugerencia y no tengo una respuesta clara de porque esa sugerencia no debería ser implementada, usualmente hago el cambio. Si me hacen una pregunta acerca de una línea de código, quiere decir que podría confundir a otros desarrolladores en el futuro. Otro beneficio, es que el hacer los cambios puede revelar otros problemas de arquitectura u otros bugs.

(Gracias a Zach Schipono por recomendar que se agregará ésta sección.)

Atención a los cambios sugeridos


Nosotros usualmente dejamos comentarios en cada línea de código con nuestro pensamiento sobre ellas. Yo observo las notas de la revisión en el stash, y al mismo tiempo, jalo el código para hacer los cambios sugeridos. Encontré que con frecuencia olvido los puntos que tengo que atender si no lo hago de inmediato.

Referencias adicionales


Hay bastantes libros en el arte de crear código limpio. He leído menos de los que me gustaría (aunque estoy trabajando en cambiar eso). Estos son algunos de los que están en mi lista:


Son un gran fanático de las charlas, así que aquí algunas que relacionadas que considero útiles y que recordé mientras escribía ésta entrada:

  • All the Small Things por Sandy Metz: Cubre bien el tema, particularmente desde la perspectiva de escribir código limpio y reutilizable. (Charla en inglés.)
  • How to Design a Good API and Why it Matters de Joshua Bloch: Una API en el sentido y con el significado de ser la forma en que una aplicación es construida y cómo interactuamos con ella. Varios de los puntos del vídeo hablan de temas similares a los discutidos en éste documento. (Charla en inglés.)


Discusión en Hacker News.

20150318

Instalar Softcover en Ubuntu

Hace unos meses, siguiendo links dentro del muy recomendado Ruby on Rails Tutorial, me enteré que es publicado con Softcover, una interesante herramienta/plataforma para la auto-publicación y distribución de escritos que trabaja sobre Ruby.

En un esfuerzo por proveer el tutorial «Aprende a programar» de una forma más amigable, decidí probar ésta nueva herramienta, pero encontré que el proceso de instalación puede ser un tanto complicado debido a todas las dependencias que maneja, por lo que a continuación detallo el proceso.

Nota: Se uso la versión 1.0.5 de Softcover sobre Xubuntu 14.10.

Preparando el entorno

Hay que tomar en cuenta que al momento de escribir ésta entrada, EventMachine (una de las dependencias de Softcover cómo gema) no funciona en versiones de Ruby de la rama 2.2.x, por lo que hay que utilizar la versiones de 2.1.x.

Para ello recomiendo usar RVM, que nos permite jugar con varias versiones de Ruby en un mismo sistema, lo cual puede hacerse por medio de las siguientes instrucciones en la consola.
   $ gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
    $ \curl -sSL https://get.rvm.io | bash -s
    $ echo "source $HOME/.rvm/scripts/rvm" >> ~/.bash_profile
Al completarse sólo hay que cerrar la consola para abrirla de nuevo y poder ver que versión de Ruby seleccionaremos para trabajar, con el siguiente comando.
    $ rvm list known
Éste listará todas las versiones de Ruby disponibles para ser instaladas, pero la que nos interesa es la más reciente de la rama 2.1.x, que al momento de escribir la entrada es la 2.1.5. Sin más, procedemos a instalarla. (Está atento a los mensajes de la consola por si pide la contraseña de administrador para poder continuar).
    $ rvm install ruby-2.1.5
Una vez que se haya terminado, recomiendo crear un gemset exclusivo para éste proyecto y un alias para poder seleccionar el entorno rápidamente.
    $ rvm use ruby-2.1.5
    $ rvm gemset create softcover
    $ rvm alias create softcover ruby-2.1.5@softcover
Con ésto, podremos seleccionar la version de Ruby y el gemset para softcover simplemente escribiendo
    $ rvm use softcover
Ya con el entorno listo, podemos instalar la gema de softcover.
    $ gem install softcover --no-rdoc --no-ri

Instalación de dependencias

Ahora viene la parte de las dependencias... ¡sí, más dependencias! Pero son necesarias para poder transformar sencillos escritos en Markdown a HTML, Epub, Mobi y PDF.

`apt` simplifica el trabajo con la mayoría de ellas, por lo que sólo hay que ejecutar en la consola
    $ sudo apt-get install default-jre
para elegir una versión de Java (en caso de que no tengas instalada alguna), y
    $ sudo apt-get install imagemagick inkscape nodejs phantomjs calibre texlive-full texlive-xetex
para un pesado conjunto de paquetes. (Recomiendo ir por un café o un bocadillo mientras se instalan estos últimos.)

Ahora sólo resta instalar Kindlegen, descargando la versión para Linux de (http://www.amazon.com/gp/feature.html?ie=UTF8&docId=1000765211). Descomprímelo y coloca la carpeta en algún lugar donde no sufra el riesgo de ser borrada después. (Yo lo tengo dentro de `$HOME/Applications`.)

Así, sólo es necesario crear un enlace de esa ubicación dentro de alguna ruta revisada en el `PATH`, como `/usr/local/bin`.
    $ cd Applications/kindlegen_linux_2.6_i386_v2_9/kindlegen
    $ sudo ln -s kindlegen /usr/local/bin/kindlegen
Por ultimo, procedemos a hacer lo mismo con Epubcheck. Lo descargamos de (https://github.com/IDPF/epubcheck/releases/download/v3.0/epubcheck-3.0.zip), para después descomprimirlo, colocarlo en un lugar seguro (`$HOME/Applications` en mi caso) y crear un enlace simbólico a la carpeta.
    $ cd /Applications
    $ sudo ln -s epubcheck-3.0 /usr/local/bin/epubcheck-3.0
Si todo salio correctamente, al ejecutar `softcover check`, todas las dependencias estarán marcadas como encontradas.

Probando la instalación

Para corroborar que todo funciona, crearemos un proyecto de ejemplo. (Si has cerrado la consola en algún momento, recuerda ejecutar `rvm use softcover`.)
    $ softcover new example_book
    $ cd example_book
    $ softcover build:all
Al completarse, debes encontrar los archivos generados dentro de `/ebooks` en el directorio del proyecto.

Así concluye

Si quieres saber más sobre cómo se utiliza Softcover para crear y distribuir tus propias aplicaciones, recomiendo leer el manual. (¿Mencione que cuentan con una plataforma que te permite monetizar el contenido?) También puedes ver las excelente publicaciones que se han hecho con ésta herramienta en su catalogo.

20141004

Cuatro razones para mantener un diario de desarrollo

Usar 60 segundos al día para escribir algunas notas pueden producir impresionantes beneficios profesionales.

* Difícilmente olvidaras como arreglaste cierto error

¿Alguna vez has encontrado un error y pensado «Sé qué he visto esto antes pero, ¿cómo lo resolví?». Con un diario en el que puedas buscar, esa experiencia desaparecerá.

* Aprenderás cuáles patrones de diseño funcionan bien cuando el código cambia.

La verdadera prueba de un diseño no es cuando lo escribes por primera vez, sino cuando necesitas modificarlo tiempo después.

Si tomas nota de cuando tus elecciones de diseño funcionan particularmente bien o si funcionan de manera pobre, pronto construirás un catálogo de técnicas que puedes adoptar y otras que debes evitar. Después de que tu tercer intento por implementar el patrón Observador en la aplicación foo sigue confundiendo a nuevos desarrolladores que se unen al proyecto, aprenderás a meditar antes de usarlo en un futuro.

* Una lista de tus logros es bastante útil ante una revisión

Enviar a tu jefe un correo, una semana antes de una revisión, listando tus mayores logros en los pasados N meses, es una acción recomendable.

* Te darás cuenta de cuando necesitas cambiar de empleo

Como seres humanos, tendemos a tener algunos días buenos y algunos malos. Debido a esto, puede ser difícil detectar tendencias en tu estado de ánimo. Escribir con consistencia puede ayudarte a detectar cuando los días malos son más que los buenos. En ese caso, tal vez sea mejor comenzar a buscar.


Cómo construir el hábito de forma exitosa


Comenzar un diario de desarrollo no es difícil, pero mantener uno lo es. Lo principal para construir el hábito no es la excitación inicial, es la consistencia. El mayor enemigo de la consistencia es el olvido.

Si quieres intentar el construir éste hábito, sería bueno que configures un recordatorio diario durante las primeras semanas. Cuando apagues la alarma, lanza tu editor y escribe una entrada.

Otra opción es una app como Trailmix, que te envía correos cada día, preguntando en lo que has estado trabajando, a los cuales puedes responder directamente para crear automáticamente una entrada en un diario. Además, incluye una entrada anterior en el correo que recibes, ayudando a mantener fresco lo que has aprendido.

También puedes optar por usar la plataforma para blogs Jekyll en conjunto con GitHub Pages, pero requiere de más configuración.


Recursos adicionales



Ésta entrada es una traducción y adaptación de «Trailmix - 4 Reasons To Keep A Development Journal», recuperada el 4 de Octubre de 2014. El contenido se incluye en ésta bitácora con fines informativos y de divulgación.

20140810

Dev.f – Una aventura con hackers

Saludos, explorador de la red.

Ya que te encuentras aquí, permite que te relate un poco de las recientes aventuras en las que me vi envuelto durante el pasado mes de Julio, dentro del programa piloto de Dev.f. Pero antes debo advertirte que olvides aquellas imagenes sobre «hackers» a los que recurren las peliculas y la televisión, y que trates de pensar en el término hacking como la acción de salirse de la norma y esforzarse para llegar hasta donde nunca antes has estado (y posiblemente llegar hasta donde nunca nadie más ha estado).


Todo comenzó con un tweet que llamó mi atención dentro del TL. «Hackea tu verano aprendiendo a desarrollar aplicaciones. Aún hay becas disponibles. Aplica ya.» –o algo así rezaba la publicación. Ahora no logro recordar quién de las personas que sigo en Twitter fue responsable de darle RT, pero en mi interior le estoy agradecido por la secuencia de sucesos que precipitó al seguir el enlace que lo acompañaba.

La primera sorpresa llegó algunos días después de llenar el formato de aplicación para la beca, en la forma de un correo para agendar una entrevista por vídeo con Eme Morato, activo trotamundos e impulsor de eventos tecnológico-educativos en México y América Latina. En una charla de tono informal y relajado, me explico un poco sobre los requisitos y detalles del curso, entre los cuales figuraba trasladarse durante un mes a la ciudad de México.

Aunque requeriría de un considerable uso de recursos, el deseo de aprender y la interesante plantilla de senseis (Victor Borja, Enrique Diaz y Sandra Macias), me hicieron esperar con ansiedad la respuesta a la solicitud, que llegó de forma dramática después de las 11 p.m. del jueves, cuando daba por hecho que no había sido seleccionado. Tuve entonces que comenzar a llamar a familiares y amigos para obtener patrocinio y un lugar donde alojarme. Si bien el lapso de tiempo para organizarme fue corto (el curso comenzaría el lunes siguiente), con la ayuda de mis contactos pude ponerme en marcha rumbo al DF el domingo por la mañana.


II

Desde el primer día, el curso estuvo repleto de actividades. Al principio, enfocadas a relacionarnos y conocer las habilidades de nuestros compañeros. Después, orientadas a presentar ideas, formar grupos de trabajo multidisciplinarios y elegir las características que creímos útiles para ser implementadas en un proyecto de desarrollo (en relación con su complejidad vs valor para el usuario).

Las siguientes semanas, nos dedicamos a la labor de aprender-implementar: cada quien eligió aquello en lo que quería trabajar para aportar al proyecto, de acuerdo a las habilidades que deseaba obtener o aquellas que ya poseía y quería hacer más fuertes. Casi todos los días recibimos visitas de experimentados desarrolladores, emprendedores, grupos de start-ups y representantes de empresas que nos hablaron sobre las diferentes herramientas que podríamos utilizar, presentaron sus proyectos y algunos temas orientados a la administración, además de ofrecernos sus consejos para refinar nuestras aplicaciones.

La información sobre lo que deseábamos aprender la obtuvimos principalmente de la red, nuestros senseis (quienes siempre estuvieron al pendiente de nosotros, ofreciendo su ayuda) y... ¡nuestros mismo compañeros! El diverso grupo aportó conocimientos sobre back-end (Rails y Python), front-end (HTML, CSS, JavaScript), mobile apps (Android) y UI/UX. Al no contar con un programa de estudios rígido y no volver el desarrollo de proyecto una competencia, se logró promover la cooperación y libre flujo de conocimientos entre todos los participantes. ¡Aún nuestros experimentados senseis lograron llevarse cosas nuevas! Y es que de eso se trató todo: hackear nuestro propio aprendizaje.


III

La mañana del último sábado del curso, mientras esperábamos a que nos dieran entrada a las oficinas de Google México, pensaba en cómo era posible el que se hubieran consumido con tal rapidez los treinta días de intensa convivencia y aprendizaje. Un dejo de tristeza se asomaba al pensar que el próximo lunes, cerca de las 3 p.m., ya no saldría de la estación del metro Juanacatlan para dirigirme a Centraal, y tampoco subiría las escaleras ni atravesaría los pasillos que llevaban a encontrar y saludar a cada uno de mis compañeros en nuestra pequeña aula.

Al disfrutar de las charlas, las hamburguesas, las presentaciones de proyecto y un par cervezas, me di cuenta que además de llevarme nuevos conocimientos, también me iba con una importante red de contactos afines a la filosofía hacker de transformar el mundo, rompiendo sus paradigmas al trabajar y crear entorno a nuestros intereses, para devolver algo que pueda a su vez ser útil a otras personas. Después de todo, sí gracias a la ayuda de mis conocidos fue el que pude lanzarme a está aventura, quien sabe que oportunidades y retos puedan llegar de mano de mis nuevos amigos.

Dev.f – Hackeando la educación en México

- o -

Agradezco todos los que hicieron posible el asistir y el disfrutar de éste curso. En especial a los habitantes de Casa Gato (Beartaco, Iván, Oscar, Bolillo y Chilo) por otorgarme asilo y aguantar todas las molestias durante todo el mes. A Jubus por visitarme los fines de semana y acompañarme a explorar la ciudad de México, haciendo que casi no extrañara el no estar en el Bajío. Al core team de Dev.f, que se esforzaron en crear y promover éste tipo de actividades (¡sigan impulsando desarrolladores!). Al equipo del proyecto «Regalo Perfecto» (Fabian, Petter, Erik, Javier, ¡son la onda!) y a todos nuestros compañeros del curso «cinta blanca» por los conocimientos que nos compartieron. A Lobo de Papel, Paxxi y Eduardo, por ser tan buena onda e invitarme a salir de la rutina.

20140324

Aprende a programar: Respuestas a ejercicios

Creo que está será la última iteración para la traducción de «Learn to Program» que realizaré en un tiempo. Ya que el contenido está completo y se hizo una revisión de los apartados y el código, sólo me quedaba la inquietud de compartir posibles soluciones a los programas solicitados dentro de tutorial.

La finalidad de compartir soluciones es que los estudiantes del tutorial puedan aprender al observar el código de otras personas al comparar sus propias soluciones con las proporcionadas; con lo que espero, puedan ver diferentes alternativas para la solución de un problema y tal vez aprender algo nuevo dentro del código. También, quise brindar una pequeña ayuda a aquellos estudiantes que pudieran quedarse atorados y frustrados al tratar de construir algunos de los programas.

Claro, yo también resulte beneficiado con la practica, al poder constatar como ha evolucionado mi estilo de programación desde que conocí el tutorial hace años.

Como en anteriores ocasiones, aquí está en enlace para la traducción al tutorial. Por favor, compártelo con quien creas que podría estar interesado en aprender a programar usando un lenguaje sencillo y amigable como Ruby.




Mi pretensión era pasar el tutorial al formato DocBook o Markdown enseguida, para así poder distribuirlo por la red en otros formatos. Pero creo que se quedará en pausa por el momento. Debo poner mi atención en otros proyectos como cooperar con la traducción de «La guía de estilo de Ruby», los cursos que quiero completar en Treehouse y edX y el poder encontrar un empleo que me permita seguir preparándome para ser un buen desarrollador.

Gracias por leer y por compartir.

20140222

Aprender a programar: 10. Clases, bloques y procs

Parece que he pasado bastante tiempo inactivo en el blog, pero hoy vengo con buenas noticias: ¡están listas las ultimas partes de «Aprende a programar»!

  • El capítulo 10 muestra como se definen las clases en Ruby, algunos detalles útiles para trabajar con el tiempo por medio de la clase Time, y el funcionamiento de los diccionarios (hashes).
  • El capítulo 11 trata sobre una característica de Ruby que permite resolver problemas de formas muy interesantes: los bloques y procs, conjuntos de instrucciones que son tratados como objetos.

Al final del tutorial, Chris incluye tres grandes fuentes de referencia para resolver dudas sobre Ruby, las cuales he complementado con algunas fuentes en español para quienes así lo prefieran.

Puedes pasar directamente al tutorial con el siguiente enlace. (Y puedes descargar el tutorial desde el menú ArchivoDescargar como...).




Ahora que la traducción está prácticamente terminada, pienso en que me ha sido una grata experiencia en conjunto. Las horas empleadas en buscar como adecuar un termino o frase del inglés al español para que se escuche natural sin perder el sentido y agregando notas cuando fue necesario, el tedioso proceso de dar un buen formato tratando de cuidar la legibilidad a la vez que la estética, el repetitiva actividad de revisar ortografía y gramática, y la mentalmente agotadora tarea de adaptar los ejemplos para el habla hispana (en cierto punto terminé odiando a la RAE), todo ello culminando en un sentimiento de satisfacción por haber completado el proyecto.

Quedan unos pequeños detalles que pulir, pero corresponden principalmente al repositorio del proyecto (agregar enlaces, notas) y queda como posibilidad, para una futura versión, pasarlo a formato docbook o markdown, lo que facilitaría el ser portado por medio de alguna aplicación a otros formatos.

Si alguien gusta colaborar, puede hacerlo mediante el repositorio del proyecto.

Ya por último, si conocen a alguien interesado a aprender a programar y quieren evitar que sufra de entrada con la sintaxis de Java, C#, etc., compartan con esa persona el enlace al tutorial. Seguramente le será de utilidad.

20131005

Aprende a programar: 9. Como crear tus propios métodos

¡Él capítulo 9 está listo! «Escribiendo tus propios métodos» ha tomado más tiempo del que esperaba debido a la gran cantidad de edición y pruebas que se tuvieron que hacer código del programa que escribe números en su versión de texto en español (el programa original del tutorial los escribe en inglés, cuyas reglas para escribir números son mucho más sencillas y tiene menos casos especiales), además que los programas de ejemplo son bastante largos, pero al final he quedado satisfecho con el resultado.

Realizar las soluciones a los programas propuestos con las limitaciones de las técnicas vistas es un buen ejercicio, pero lo pospondré para seguir trabajando en la traducción de los últimos capítulos.

Espero que quien siga el tutorial disfrute con el contenido del capítulo, encuentre retadores los ejercicios que ahí se encuentran, y continúe con interés para adentrarse en el manejo de clases y bloques de los capítulos siguientes.

Como de costumbre, la versión más reciente la puedes encontrar en el siguiente enlace:


20130905

La terrible exclamación, o, resultados inesperados de métodos con ! en Ruby

Ésta es una traducción del artículo «The Big Bad Bang, or, The OTHER Gotcha with Ruby's Bang Methods», escrito originalmente por David Aronson en Attack of the Codosaurus!, y es publicado bajo su permiso.


     Algunas personas me han preguntado el por qué ciertos métodos de Ruby terminan con un signo de exclamación (!), comúnmente conocido como bang en los círculos de programación. Los ejemplos incluyen upcase! (para obtener una versión completamente en mayúsculas de una cadena de caracteres) y uniq! (para obtener los elementos únicos dentro de un arreglo). Para acortar la explicación, el bang significa que debes usar ese método con precaución.

     Esto es debido a que usualmente el método modifica el objeto que recibe y luego lo devuelve (proceso destructivo), en lugar de devolver sólo una copia modificada del objeto. (En Rails y otros frameworks similares, puede indicar que el método arrojará una excepción si algo sale mal. Pero, nos enfocaremos en los métodos básicos de Ruby.) Les mostraré otra razón en un momento, pero por ahora, vamos a examinar el comportamiento usual y esperado.

     Por ejemplo:


cadena = 'foo'
p cadena.upcase # > FOO
p cadena        # > foo

     Obtenemos FOO y después foo. Cuando upcase devolvió la versión en mayúsculas, no modificó la cadena.

     Por otro lado, si agregamos un bang, así:


cadena = 'foo'
p cadena.upcase! # > FOO
p cadena         # > FOO

     ¡Obtenemos FOO y otra vez FOO! En otras palabras, upcase! devolvió la versión en mayúsculas, justo como la versión sin bang, ¡pero también modifico la cadena!

     De forma similar, si usamos uniq:


arreglo = [1, 3, 3, 7]
p arreglo.uniq # > [1, 3, 7]
p arreglo      # > [1, 3, 3, 7]

     Obtenemos [1, 3, 7] y [1, 3, 3, 7], mostrando que la versión sin bang devolvió los valores únicos dentro del arreglo, pero no lo modificó, mientras que si agregamos un bang:


arreglo = [1, 3, 3, 7]
p arreglo.uniq! # > [1, 3, 7]
p arreglo       # > [1, 3, 7]

     Obtenemos [1, 3, 7] y [1, 3, 7] de nuevo, mostrando que el arreglo fue modificado ésta vez.

     Hasta ahora todo bien. ¡Pero espera! ¡Aún hay más! Hay un comportamiento inesperado aguardando ser encontrado...

No esperes que las versiones con bang de los métodos devuelvan el mismo valor que las versiones sin bang. (Aunque ese valor parezca ser la razón de ser de ambas funciones.)

     En los casos antes mencionados, ese es el punto. Pero observemos lo que pasa si la variable ya tiene el valor que necesitamos –en otras palabras, si la cadena ya está en mayúsculas, o el arreglo ya cuenta sólo con valores únicos.

     Si usamos:


cadena = 'FOO'
p cadena.upcase! # > nil
p cadena         # > FOO

     Como esperamos de la cadena, al ya contener el valor que necesitamos, no fue modificada. Pero observa el valor devuelto por cadena.upcase! –¡es nil!

     Veamos que pasa en el caso numérico:


arreglo = [1, 3, 7]
p arreglo.uniq! # > nil
p arreglo       # > [1, 3, 7]

     Justo como en el caso anterior, el arreglo no sufrió cambios, ¡pero el valor devuelto por arreglo.uniq! es nil! ¿Cómo es eso posible?

     De forma resumida, los métodos básicos en Ruby que incluyen el bang, con frecuencia devuelven nil si no se realizó ningún cambio. El problema es que esto no pasa de una forma consistente, por lo tanto, cuando utilices un método que incluye bang con el que no estés familiarizado, asegurate de leer el manual.

20130828

Aprende a programar: Capítulos 0 a 8 revisados

     ¡Uffff! Después de varios días de arduo trabajo (que incluyeron sus respectivos y merecidos descansos), he concluido la revisión del material traducido del tutorial «Learn to Program» hasta el momento.

     Además de corregir algunos errores gramaticales y ortográficos, se han hecho las siguientes mejoras:

  • Se agregaron enlaces a la mayoría de los códigos de ejemplo para ser probados directamente desde el navegador, sin la necesidad de instalar Ruby. (Gracias a repl.it).
  • Se proba el código de todos los programa de ejemplo para asegurar que todos ellos puedan ejecutarse.
  • Se incluyeron enlaces a código de ejemplos de soluciones a cada uno de los ejercicios propuestos. (Para quien pueda llegar a necesitar una guía).
  • Se reorganizo el proyecto en GitHub para que tenga una estructura coherente y facilite la colaboración.

Como siempre, el material más reciente se encuentra en el documento:


20130729

«Aprende a programar» ahora en GitHub

¡Saludos, lectores!

     El blog ha tenido poco movimiento debido al proceso de adaptación a mi nueva rutina de trabajo (tome un trabajo eventual como recepcionista-auditor nocturno) y de «adecuación física» (me encuentro a medio proceso de llegar a mi peso ideal a través de cambios en mi alimentación y ejercicio constante), pero he permanecido con el propósito de completar mi preparación en el área de desarrollo de software.

     Por supuesto, eso incluye el continuar con mis proyectos, entre los cuales se incluye la traducción de «Lear to Program». Aunque el proceso de traducción ha tenido poca actividad, he continuado haciendo pequeñas mejoras al revisar el texto con atención: corrigiendo errores, agregando notas, adecuando el estilo y cambiando palabras para hacer más claro el sentido donde me ha parecido adecuado.

     He tenido que iniciar una revisión general a causa de que al estar trabajando en la traducción del capítulo 7, encontré que no había probado los ejemplos de código que habían sido modificados en el proceso. Y en mi convicción de entregar un trabajo de calidad a las personas con la intención de aprender sobre Ruby, me he vuelto un poco sobre mis pasos. No espero que la revisión tome mucho tiempo, así que seguramente para Agosto ya la habré terminado. Y durante ese mismo mes, quiero terminar el proceso de traducción de los capítulos 7 y 8.

     Probablemente uno de los cambios más interesantes es que he movido el trabajo a la plataforma de Github, lo que permitirá que otras personas puedan participar en el proyecto con relativa facilidad por medio del sistema de control de versiones Git en el siguiente enlace:


20130316

Aprende a programar: 8. Arreglos e iteradores

     Es turno de aprender a manejar un nuevo tipo de objeto: ¡los arreglos! Aunque son sólo listas que guardan referencias a otros objetos, nos permiten manipular grandes cantidades de información relacionada y aplicar sobre ella tareas repetitivas de una forma sencilla.

     Aún más, los arreglos en Ruby cuentan con métodos especiales que nos permiten movernos entre sus elementos sin tener que estar al pendiente de la posición en donde nos encontramos (cómo lo haríamos en C o Java).

     Puedes continuar leyendo al respecto en...


20130217

Aprende a programar: 7. El control del flujo de un programa

     ¡Por fin está listo el sexto capítulo de Aprende a programar! Tomo un poco de tiempo debido al formato extra que lleva el código para ilustrar las palabras clave usadas en control del flujo de un programa. Ésta sección revisa los temas de operadores lógicos, ramificación e iteración. Con ellos es posible construir casi cualquier tipo de programa, así que es muy importante entenderlos. Al final, hay un par de ejercicios bastante divertidos.

     Interesante, ¿no es así? Invierte un poco de tiempo y continua en


20130128

Aprender a Programar: 6. Aritmética, números aleatorios y el objeto Math

     En está ocasión les comento que ya está disponible la traducción de la segunda parte del capítulo 5 del tutorial «Learn to Program». En ésta parte encontraran como hacer uso de algunos métodos matemáticos como los operadores de potencia y modulo, como generar números aleatorios, y el uso de constantes y métodos predefinidos en el objeto Math. Aunque son conceptos matemáticos un poco más avanzados, se darán cuenta que con Ruby son realmente fácil de manipular.

     Con estos conocimientos en conjunción con lo que viene a futuro en el tutorial, podrán construir programas muy interesantes. Recuerden estar al pendiente del nuevo contenido que se va añadiendo. :)


20130115

Aprende a programar: 5. Más sobre métodos y métodos de texto

     Después de un periodo algo ocupado, he continuado con la traducción de «Learn to Program». En ésta ocasión ya ésta disponible la primera parte del capítulo 5, el cual extiende un poco más la explicación sobre métodos y ofrece ejemplos utilizando algunos métodos nuevos para manipular texto.

     Además, iré relacionando los capítulos con otro material en español (como los vídeos de Código Facilito) disponible en la red para complementarlo y puedas aprender un poco más al revisarlo.

     Si estás siguiendo la serie para aprender a programar en Ruby, no te lo pierdas.

20130110

Propósitos 2013

     He mantenido algo descuidados la mayoría de los espacios donde comparto información, tanto aquello que me ocurre en la vida diaria, así como aquellos, como éste, donde comparto mis gustos e intereses. Esto es debido a que un montón de cursos y actividades de aprendizaje me han mantenido bastante ocupado (además de las actividades de esparcimiento de rigor, claro está). Sin embargo, es un esfuerzo por traer un poco más de organización a todos los aspectos de mi vida, he comenzado a usar herramientas como Producteev, Noom y Anki para fijarme metas y poder medir mi avance y me están funcionando bastante bien. :)

     Es por eso que, inspirado por la entrada «2013 Rubylutions» comparto una lista de propósitos de tipo personal-profesional que no sólo me beneficiaran a mí, si no también a aquellos interesados en aprender sobre Ruby y otras tecnologías relacionadas (espero).

Propósitos para éste año 2013
  • Terminar la traducción al español del tutorial original «Learn to Progran» escrito por Chris Pine. (Agregando unos pequeños extras como enlaces a vídeos y otros sitios de practica/ayuda).
  • Terminar la traducción y adaptación de la «Ruby Style Guide» escrita por Bozhidar Batsov. (Éste proyecto pensaba anunciarlo hasta que estuviera terminado, pero igual así me siento más comprometido a trabajar en él).
  • Publicar al menos la traducción de un articulo sobre Ruby o algún ejercicio complementario para aquellos que leen «Aprender a programar» tengan a su disposición más recursos. (Al tiempo de que yo refuerzo mis conocimientos).
  • Conseguir un empleo como trainee o desarrollador jr para Web/Ruby/Rails en una empresa dentro de México. (Ya ha habido algunas propuestas, pero aun no me sentía con la confianza. Sería genial poder trabajar en un lugar como Nearsoft, Crowd Interactive o tal vez SCIO Consulting).

     No será una tarea sencilla, ya que hay mucha información disponible, mucha información que es generada, y toda ella debe ser procesada, filtrada y adaptada para el beneficio de los hispanohablantes. Pero hay la intención, la disposición y, de momento, el tiempo.

20121129

No es fácil escribir programas que funcionen correctamente...

     Como pronto descubrirás, no es fácil escribir programas que funcionen correctamente. Programadores experimentados confirmarán que gastan una gran cantidad de tiempo leyendo programas en un intento de comprender porque se comportan como lo hacen. Es por lo tanto de una importancia critica el escribir programas en una forma en la que sean fáciles de leer.

20121107

Refuerza lo básico en Ruby con vídeo tutoriales en Español

     Los vídeo-tutoriales se han vuelto una excelente herramienta para poder aprender sobre un sin fin de cosas a través de la red de una forma bastante más atractiva visualmente. Simplemente con hacer una búsqueda en Youtube y servicios similares, puedes aprender tanto a preparar deliciosos platillos (enfrijoladas ), como limpiar el ventilador de tu ordenador portátil para evitar el sobrecalentamiento[2], hasta los pasos de baile para canciones de moda. Todo esto mientras ves cada paso al momento que lo realizan. Y bueno, gracias a Uriel Hernandez podemos hacer lo mismo con Ruby en español.

     Mediante su canal Código Facilito, se puede dar un repaso por todas las características básicas de Ruby: comentarios, variables, conversión de tipos, alcance de variables, operadores aritméticos, manejo de cadenas de texto, instrucciones de decisión e iteración, salida y entrada de datos, estructuras de arreglos y diccionarios, métodos, procedimientos y clases.

Ruby Facilito
Ruby Facilito en Youtube
     Los vídeos son bastante cortos y concretos (alrededor de 5 minutos cada uno), y están destinados a las personas que van adentrándose al lenguaje, por lo que si estás conociendo Ruby mediante el tutorial «Aprende a programar» o alguna otra herramienta, pueden ser un excelente complemento.

     Realmente me emociona ver este tipo de proyectos, ya que van haciendo disponible las tecnologías más recientes dentro de la comunidad de habla hispana. ☺

     Así es que ya sabes, date una vuelta por su playlist «Ruby Facilito» para seguir aprendiendo Ruby, y si además aprendes a preparar enfrijoladas, ¡me invitas!

20120927

Try Ruby: La elegancia y funcionalidad de Ruby en 15 minutos

     En estos días he estado revisando material en la búsqueda de enriquecer y complementar la experiencia de aquellas personas que se inicien en el aprendizaje de la programación con Ruby. Por lo mismo, recordé que en el sitio oficial del lenguaje había un enlace que te permitía probar el lenguaje directamente desde el navegador, sin tener que instalar algún interprete en tu computadora. Y me encontré con la grata sorpresa de que dicho enlace fue substituido por otro hacía un tutorial interactivo llamado Try Ruby.

     Éste es un sencillo tutorial introductorio facilitado por Code School que te lleva de la mano por los conceptos más básicos de Ruby (variables, métodos, arreglos, diccionarios, clases, archivos), para culminar su aplicación en un sencillo blog en tan sólo 15 minutos – aproximadamente.

     Tiene la particularidad de que presenta la información en un estilo similar al que solía utilizar _why, un importante programador, autor y promotor de Ruby, por lo que está lleno de divertidos comentarios e incoherentes ejemplos que hacen el material bastante entretenido. La parte triste, es que Try Ruby sólo se encuentra disponible en el idioma inglés. :( Sin embargo, para todos aquellos que tengan un conocimiento medio o avanzado del idioma gringo, les recomiendo que se gasten esos 15 minutos visitando el sitio. Y los que no, bueno, ¿qué esperan que no están practicando su inglés en Duolingo?

Try Ruby
Try Ruby (chunky bacon!)