Invitación & Iniciativa: Desarrollo con NicoPaez

El próximo lunes 15 de enero comenzaré esta nueva iniciativa. La idea es que voy a desarrollar una aplicación de forma iterativa e incremental, dedicando tan solo 15 minutos por día y aplicando las prácticas «modernas» desarrollo (BDD/TDD, CI, Test automation, etc) y gestión (slicing, estimación, planificación). En cierto modo voy a estar poniendo en práctica gran de los temas que vemos en MeMo2.

Estaré trabajando en Ruby casi puro, voy a intentar evitar utilizar complementos mágicos como Rails de forma que sea fácil seguirme y que incluso, quienes gusten, puedan trabajar a la par utilizando algún otro lenguaje.

Creo que mantener las sesiones acotadas a 15 minutos puede ser un gran desafío, pero en principio es la intención. Dicho esto, los interesados en participar me pueden mandar un mensaje aquí y los agrego a la cita para que les quede en el calendar y puedan acceder el meet.

¡Nos vemos el lunes 15 de enero a las 12:00 (hora Argentina, o sea: GMT-3)!

Actualización: comparto aquí el video de la primera sesión donde explico varios detalles de la iniciativa (alcance, grabación, etc)

Uso de RubyMine con Docker-compose

Hace un tiempo escribí como sobre usar RubyMine con Docker. En ocasiones, cuando trabajamos con aplicaciones web es habitual utilizar una configuración docker-compose que incluya un contenedor con el runtime Ruby y algunos otros contenedores por ejemplo con MySql, Redis, etc. Para usar RubyMine en estos escenarios debemos hacer lo siguiente.

Armamos la configuración docker-compose y la ponemos a correr asegurándonos de el contendedor que contiene el runtime Ruby quede levantado. Esto puede hacerse agregando las siguientes 3 líneas en la definición del contenedor:

    command: "/bin/bash"
    stdin_open: true # esto es equivalente a hacer docker run -i
    tty: true        # esto es equivalente a hacer docker run -t

Luego, abrimos el proyecto en RubyMine y ajustamos la configuración en «Ruby SDK and Gems». Agregamos una nueva configuración remota.

En la ventana emergente debemos seleccionar la opción «Docker Compose», en «Configuration Files» debemos apuntar al archivo que contiene nuestra configuración de docker-compose y finalmente en «Service» debemos seleccionar el contenedor que contiene el runtime Ruby. Dependiendo de como esté instalado el runtime Ruby en la imagen del contenedor puede que necesitemos ajustar el valor default de «Ruby or version manager path».

Una vez que damos «OK» a ambas ventanas de emergentes el RubyMine puede tardar unos minutos en completar la aplicación de la nueva configuración.

Un detalle más: si queremos utilizar el debugger de RubyMine debemos asegurarnos que nuestro proyecto incluya las gemas «ruby-debug-ide» y «debase» en el Gemfile.

Finalmente les comparto una configuración compose de ejemplo para que se entienda todo el contexto.

version: '3'
services:

  test_db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: example

  dev_db:
    image: postgres
    environment:
      POSTGRES_PASSWORD: example

  webapp:
    build: 
      context: .
      dockerfile: Dockerfile.dev
    command: "/bin/bash"
    stdin_open: true # docker run -i
    tty: true        # docker run -t
    ports:
      - "3000:3000"
    expose:
      - 3000
    volumes:
        - .:/app
    environment:
        RACK_ENV: "development"
        TEST_DB_URL: "postgres://postgres:example@test_db:5432/postgres"
        DEV_DB_URL: "postgres://postgres:example@dev_db:5432/postgres"
    depends_on:
      - test_db
      - dev_db

RubyMine con Docker

En la actualidad es cada vez más habitual utilizar Docker como ambiente de desarrollo, o sea: en lugar de instalar el runtime de desarrollo en nuestro host, armamos una imagen Docker con el runtime del proyecto conteniendo también todas dependencias/libs y en nuestro host instalamos tanto solo Docker Desktop y el IDE de nuestra elección.

Esta estrategia resulta especialmente útil en stacks como Ruby donde es habitual tener que utilizar distintas versiones Ruby. Sin embargo cuando pretendemos utilizar IDEs más potentes como RubyMine, que proveen algunas funcionalidades que dependen del runtime (como es el caso de algunos refactorings), es necesario hacer algunos ajustes de configuración en el IDE. Es por ello que grabe un video explicando estos ajustes. Espero les resulte útil.

Preparación para el taller exploratorio de tcr

Preparación para el taller exploratorio de tcr

El jueves próximo en el contexto de la semana de la agilidad voy a estar haciendo un taller exploratorio de la dinámica tcr (test && commit || revert). Para ejercitar esta dinámica resulta muy conveniente tener algún mecanismo de file watching que (cada vez que modificamos un archivo) se encargue de correr los test y hacer commit o revert dependiendo del resultado.

Durante el taller yo voy a trabajar con Ruby pero el taller se puede seguir perfectamente con cualquier lenguaje, solo es necesario tener Git y un algún framework de automatización de tests (algo de la familia xUnit es suficiente).

Para quienes quieran trabajar con Ruby, armé un setup con una configuración Guard para correr el flujo trc. Está disponible GitHub.

From Heroku to Rackspace

It is the third time I am involved in the moving an application from Heroku to a cloud server. The time the server is running Ubuntu and it is hosted on Rackspace. It was not my decision, I was contacted once the the decision was already made, but in this particular case I think it is a good idea.

The requirement was simple: move the application to a Cloud Server running Ubuntu 14. The application should continue using the same infrastructure services it was using on Heroku, that is: Puma, PostgreSQL and Memcached.

Just like the previous cases I was involved, the setup of the infrastructure is really easy, you can do almost everything with apt-get command.

The «not-so-easy» part is when you have to replace some of the services provided by Heroku. No matter how simple your application is, for sure you will have to deal with application deployment and database backups.

In the next days I will post detailed articles to explain how to implemented this concerns.

ChiliProject, my favourite project management tool

About 2 years ago I started working with Tipit guys. My first task was to migrate their project management tool. At that time they were using a tool called Bugnet that was build with C# and they wanted to move to ChiliProject that was built with Ruby. I had experience with both technologies so I was a good candidate to do the job. The migration was successful and after that, we continued working together.

For almost two years I have worked in several Tipit projects and in all of them we have used ChiliProject. In all this time we have also added several new features to ChiliProject and the good news is that all these features are open source and anyone can get them from GitHub.

What I like about ChiliProject is that it provides several features beyond issue tracking, here is a brief list of the most interesting features in my opinion:

  • Ability to define different kind of issues with different fields and workflows
  • Ability to create/update issues by email
  • Ability to connect to source code repository and link commits with issues
  • Discussion Forums
  • Project roadmap definition support
  • Project calendar
  • Wikis
  • File sharing

Beyond these features, ChiliProject is a open source tool, built on Ruby on Rails and very extensible.

Impresiones de la RubyConfAR 2013

La semana pasada participé por primera vez de la RubyConf. Los comentarios que recibí de algunos colegas sobre las ediciones anteriores me entusiasmaron mucho y por ello decidí anotarme.

Para quienes nunca han asistido comienzo describiendo el formato de la conferencia. La conferencia en sí son 2 días a los que se le suma un preludio denominado «Ruby Fun Day» en el que se dictan charlas/talleres introductorios a Ruby. Lamentablemente no pude asistir al fun day, pero de todas formas no creo que me hubiera aportado mucho, ya que tengo bastante experiencia trabajando con Ruby. Adicionalmente también suele haber alguna actividad social fuera del horario de la conferencia.

La conferencia en sí es un track único con sesiones de 30 minutos organizadas en bloques, donde cada bloque es: sesión 1 + sesión 2 + coffee break. Al mismo tiempo las sesiones suelen ser en forma de exposición, a diferencia de los eventos de agile, donde hay sesiones tipo workshop o tipo debate. Creo que justamente por estar acostumbrado a las conferencias agile, este formato me resultó  un poco pesado.

Respecto de las sesiones, me llamó la atención que más de una se enfocó en otros lenguajes (recuerdo una sesión sobre Go y otra sobre Erlang). Entre las sesiones que me resultaron más interesantes estuvieron:

  • La de @abecciu de Restorando sobre cómo resolvieron ciertas cuestiones de recolección de datos
  • La @runixo sobre IPython Notebook
  • La de @cristianrasch sobre Rack
  • La de @xymbol sobre Ruby & Unix
  • La de @kurko sobre orientación a objetos

Más allá de esto, hubo otras dos sesiones que más que interesantes yo las calificaría como muy entretenidas, en gran parte por el carisma de sus oradores. Esas sesiones fueron las de @ajlopez sobre su implementación de Ruby con C# y la de @janogonzalez sobre la bipolaridad de los programadores.

Tutorial de aplicaciones Padrino: parte 1

En esta primera parte veremos la configuración inicial de nuestra aplicación y algunas de las herramientas que utilizaremos a lo largo del tutorial. La idea trabajar con un entorno como el descripto en el post inicial de esta serie, partiendo de esta solución y siguiendo los videos explicativos.

  • Creación del repo git y primer commit, ver.
  • Creación de la aplicación base con Padrino, ver.
  • Configuración de Travis (build server), ver.
  • Ajustes de configuración en la aplicación base que genera Padrino, ver.
  • Generación de un objeto de negocio (model) con Padrino, ver.
Continuará…

Curso de Extreme Programming y tutorial de desarrollo de aplicaciones con Padrino

Desde hace un tiempo vengo trabajando con mi colegas de Kleer en la preparación de un curso de desarrollo de aplicaciones con prácticas ágiles. En cierto modo es un curso intermedio/avanzado de Extreme Programming. Durante el curso se verán temas como SCM, BDD, TDD, Mocking, Continuous Delivery, Pair programming, Design Patterns, SOLID, etc.

La idea del curso es ver estos conceptos y poner manos a la obra programando una aplicación empresarial utilizando Github, Travis, Ruby, Padrino y Heroku, entre otros. Dado que la idea es trabajar sobre los conceptos previamente mencionados, nosotros proveeremos una aplicación base sobre la cual se desarrollará el curso y sobre la que los alumnos deberán implementar nuevas funcionalidades poniendo en práctica los conceptos/prácticas en estudio.

Aprovechando el desarrollo de esta aplicación, he decido ir generando una serie de artículos y videos a modo de tutorial, para mostrar cómo encarar el desarrollo de una aplicación utilizando las mencionadas prácticas y herramientas.

Para facilitar las cuestiones de setup, estoy utilizando una máquina virtual con Linux Mint 14. Pueden descargarse la imagen base en forma totalmente gratuita desde virtualboxes.org. Esta imagen se puede ejecutar en diversas plataformas utilizando Virtual Box.

Una vez que tengan la imagen funcionando, es necesario instalar algunas cosillas, cuyo detalle pueden ver aquí.

En los próximos días comenzaré a publicar videos de 5 minutos mostrando como desarrollar la solución utilizando las mencionadas herramientas.

Sobre C# y Ruby

Esta es la continuación del post que publiqué ayer, pero que en realidad es más bien una precuela.

Resulta que la semana pasada estaba hablando con unos colegas de Algo3 sobre tecnologia y comenté mi amistosa incursión en Ruby. Ante esto, uno de mis colegas me tildó de panquequearme, pues la mayor parte de mi carrera he argumentando a favor de C# y la plataforma .NET en general.  Hoy por hoy y para una gran cantidad de aplicaciones prefiero inclinarme hacia Ruby, no porque me parezca más apropiado sino porque me siento más cómodo (incluso a pesar de conocer mucho menos). Pero esto no me convierte en panquete, pues mi cambio de opinion no fue ni reiterado ni en corto plazo de tiempo.

Recuerdo que la primera vez que me acerqué a Ruby fue durante 2006, cuando trabajando en Snoop me tocó participar en un proyecto en el cual el cliente nos pedia definir su plataforma y nos había pedido explícitamente evaluar .NET, Java y Ruby. Al cabo de 3 semanas de trabajo nuestra recomendación fue .NET. Pero bastante han cambio estas tecnologias desde aquel 2006 hasta la actualidad (¡pasaron 6 años!).

Ahora hablando un poco sobre el título de este post, creo si bien ambos lenguajes a simple vista parecen bastante distintos, tienen varias cosas en comun en cuanto a la caraterísticas que soportan. Sin duda la diferencia más distintiva es el hecho de que C# es de tipado estático y Ruby de tipado dinámico. Esto implica que en el caso de C# es necesario realizar una compilación explícita antes de pedirle a la maquina virtual que ejecute nuestro programa. Por otro lado, Ruby incorpora varias cosas de Smalltalk (metaclases, bloques, etc) lo cual me resulta muy feliz.

Más allá de las bondades del lenguaje, debo admitir que me he sorprendido a mi mismo, pues nunca crei que pudiera programar con un editor de texto (gedit) luego de haber trabajado por tanto tiempo con Visual Studio y Eclipse. Cuando trabajo en ruby codeo con gedit y tengo dos terminales abiertas, una para hacer el build y otra con irb (el interprete interactivo de ruby) para probar cosas del lenguje, pues aun no estoy suficientemente familiarizado. Cuando esporáricamente tengo que levantar Visual Studio o Eclipse, me deprimo mal, ambos entornos tardan una eternidad en levantar (a pesar de que tengo 4 GB de memoria). Y ni hablar cuando quiero compilar una solucion y correr las pruebas con visual studio.

Más allá de mi opinion (totalmente subjetivas) y de los gustos particulares de cada uno, creo que es importante que todo estudiante/profesional de sistemas haga una experiencia en ambos mundos: el corporativo (C#/Java) y el open source (ruby/python/smalltalk).

Por lo dicho en el post anterior, esa calificación no me aplica pues mi cambio de opinion

hace algunos años habiaal encarar un proyecto había tenido que elegir entre .Net y Ruby y en aquel momento habia elegido C# practicamente sin dudarlo (pero ojo, había investigado Ruby)