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.