Este es sólo una parte del conjunto de actividades que tenemos planeadas para la mejora de competitividad de la empresa, en busca de mantener e incrementar nuestro crecimiento.

Rails Studio es un programa de entrenamiento, totalmente gratuito, que busca proveer a un Developer de todos los conocimientos necesarios para desenvolverse de manera productiva en un entorno de trabajo profesional basado en Ruby y en su framework más poderoso para desarrollo agil de aplicaciones web, Ruby on Rails.

Cuál será la modalidad de trabajo?

El programa propone una modalidad de Workshop en jornadas intensivas de 3 horas, dos veces por semanas (Lunes y Miecoles); con una duración de 4 semanas.

El dictado de cada jornada se hará en las instalaciones de INSIGNIA, empezando a horas 18, hasta horas 21.

Cada alumno aprende desde su laptop todos los conocimientos a través de ejercicios prácticos.

Cómo me inscribo?

Si bien el Rails Studio es total y completamente gratuito, su cupo es limitado y el éxito de su programa se encuentra íntimamente ligado al perfil y skills de sus alumnos.

Por esto es que los interesados deberán acreditar experiencia (comprobable) en desarrollo web y muchas ganas de aprender e investigar.

Para solicitar una entrevista, los interesados deberán enviar su CV a rails-studio@insignia4u.com. Los cupos no se revervan y serán otorgados a medida de que los interesados sean seleccionados.

Ruby on Rails a tu alcance, totalmente gratis. Te recomendamos que te apures. Largamos el 27 de Septiembre!

Te esperamos.

Alguna duda?

Mail: rails-studio@insignia4u.com
Teléfono: (0381) 420-7387

Git es un sistema de control de versiones open source, totalmente gratuito. Fue diseñado por Linus Torvalds con el objetivo de posibilitar la gestión eficiente y veloz de cualquier tipo de proyecto de software. Actualmente es utilizado para gestionar el código fuente de algunos de los proyectos open source más importantes entre los que se destacan: Linux Kernel, Debian, Gnome, Ruby on Rails, Android, entre otros.

En INSIGNIA adoptamos Git como sistema de control de versiones para todos nuestros proyectos porque en él encontramos una herramienta con un sin fin de funcionalidades que podían ser adaptadas y utilizadas sin ningún problema a nuestro workflow. Nos fascinó la facilidad con la que se pueden crear  branches, realizar merge de cambios de un branch a otro y mantener todo bien sincronizado.

Luego de 2 años de utilizarlo -y exprimirlo- para gestionar nuestros proyectos, hemos encontrado muchos detalles de esta herramienta que pueden afectar negativamente la productividad del equipo sino se aplican algunas buenas prácticas y costumbres para mantener la casa en orden.

A continuación, presentamos el workflow que aplicamos en nuestra activadad diaria para utilizar Git desde un enfoque ágil y productivo.

Primero repasemos cómo es el workflow básico propuesto para Git. Para esto clonaremos uno de nuestros proyectos open source, el primer comando que deberemos ejecutar es:

  # git clone git://github.com/insignia/administrate_me.git

Esto nos descargará la última versión del proyecto en el directorio administrate_me.

Si queremos ver cuáles fueron los últimos cambios que se introdujeron en el proyecto, podemos ejecutar:

  # git log

Y obtendremos un listado cronológico con todos los cambios que se efectuaron en el código del proyecto.

Ahora si modificamos un archivo (por ejemplo el README del proyecto), y ejecutamos:

  # git status

Podremos ver qué archivos se encuentran modificados. El resultado sería algo así:

El output del comando git status, nos aporta un dato muy importante: el branch donde estamos trabajando. Como mínimo, siempre tendremos el branch master.

Para agregar nuestros cambios, debemos hacer un commit de los mismos, eso se logra ejecutando:

  # git commit -a -m "Modifico el archivo README"

Finalmente, debemos subir esos cambios al repo central (conocido técnicamente como origin), pero antes tendremos que revisar que nuestro código se encuentre actualizado con este repo, para esto:

  # git pull
  # git push

Y este sería el workflow más simple que se podría dar en Git.

La práctica más recomendada para trabajar en Git indica que todo nuestro trabajo debería ser realizado en un branch temporal y cuando estos cambios están listos, hacer un merge de esos cambios en master y su posterior push.

Para crear un branch, simplemente ejecutamos los siguientes comandos:

  # git branch mi-nuevo-branch
  # git checkout mi-nuevo-branch

O podemos ejecutar todo en único comando con:

  # git checkout -b mi-nuevo-branch

Luego, una vez que nuestros cambios están listos, los pasamos al branch master ejecutando:

  # git checkout master
  # git merge mi-nuevo-branch

O si necesitamos subir un cambio en particular, podemos pasar un commit específico de un branch a otro, ejecutando:

  # git checkout master
  # git cherry-pick 9c108bfab98afe92b03fa15edb926bc3374ce8f5

Donde 9c108bfab98afe92b03fa15edb926bc3374ce8f5 es el hash que identifica a un commit en particular.

Esta manera de utilizar Git sigue siendo simple y ofrece muchísimas bondades. El mayor beneficio es el poder crear un branch que contenga la versión estable del proyecto (nosotros normalmente nombramos a este branch como production), y en él se van agregando todos los cambios aprobados por medio de la técnica de cherry-picking.

De ser necesario, Git nos proporciona las herramientas para identificar qué commits todavía no fueron incluídos en un branch determinado (por ejemplo: en production). Para esto, tenemos que ejecutar el siguiente comando:

  # git checkout production
  # git log --reverse --cherry-pick master...

Utilizamos la bandera –reverse para saber qué commit debería ser incluído primero y con la bandera –cherry-pick master… indicamos que solamente queremos ver aquellos que se encuentren en el branch master que todavía no se encuentren en production.

Utilizando este enfoque durante un tiempo, nos encontramos con que el listado de cambios pendientes que nos retornaba Git no era del todo preciso. Al investigar las posibles causas, encontramos que Git falla al determinar los commits pendientes en aquellos casos donde se hace complicado establecer qué commit precede a otro.

En este caso podemos ver que los commits no se encuentran alineados cronológicamente sino que en algunos casos, algunos commits son precedidos por dos o mas commits. Es en estos casos donde la técnica del cherry-picking nos puede arrojar resultados o comportamientos extraños.

Este es un problema que se hace demasiado notorio cuando los proyectos donde intervienen grandes equipos. De nuestra experiencia en el desarrollo de la nueva versión de Burdastyle.com (donde en el proyecto participaban equipos distribuidos entre Tucumán, Manchester y New York), encontramos que a menos que todos los miembros del equipo apliquen una política para el manejo de Git dentro del proyecto.

Luego de examinar un poco las distintas experiencias con Git de otros equipos, encontramos que el principal problema para este comportamiento incorrecto de Git era causado por la técnica utilizada para sincronizar los branches. Básicamente la técnica de pull/merge no tiene en cuenta el orden cronológico de los commits al mover commits de un branch a otro. Para solucionar esto, encontramos que también se podía sincronizar los branches por medio de la técnica fetch/rebase, de esta manera nuestros commits son pasados de un branch a otro pero teniendo en cuenta el orden cronológico de los mismos.

Utilizando esta técnica para realizar el paso de commits de un branch temporal a master, deberíamos ejecutar:

  # git checkout mi-nuevo-branch
  # git rebase master
  # git checkout master
  # git merge mi-nuevo-branch

Y si necesitaramos sincronizar nuestro branch master con origin, podríamos hacerlo de la siguiente manera:

  # git fetch
  # git rebase origin/master

De esta manera logramos preservar el orden cronológico de todos los commits.

Con todo esto, el workflow ideal para trabajar con Git estaría conformado por los siguientes pasos:

1. Realizar todo el trabajo en un brach temporal.
2. Antes de pasar los cambios a master, ejecutar un rebase de dicho branch con master.
3. Hacer merge de los cambios en master.
4. Sincronizar nuestro master con origin/master utilizando fetch/rebase.
5. Subir nuestros cambios.
6. Si tenemos cambios que pasar a un branch estable, hacerlo con el comando cherry-pick.

Para profundizar sobre Git y sus buenas prácticas, algunos links interesantes para leer son:

• Pagina Oficial Git
• GitReady.com
• A git workflow for agile teams

El resto es práctica y mucha predisposición para solucionar de la mejor manera cualquier inconveniente con el que nos encontremos.

Tucumán Valley es un emprendimiento que se suma al espíritu de las “agrupaciones valley”, una modalidad que se ha extendido por todo el mundo y que tiene como principal objetivo fomentar e impulsar los proyectos web y tecnológicos de la región. Para ello reúne y promueve el contacto entre los profesionales y empresas dedicados a esta actividad, a través de la organización de eventos y encuentros periódicos.

La formación del Tucumán Valley surgió de una idea de Romina Soria, compartida desde su Twitter, de la que nos hicimos eco y desde INSIGNIA decidimos impulsar.

En la primera reunión se logró juntar a diferentes entidades y empresas relacionadas con la Tecnología Informática y el resultado de dicha reunión fue muy positivo y bastante auspicioso. Realmente, fue muy grato encontrar a tanta gentre dispuesta a compartir y promover objetivos comunes para fomentar de esta forma un mundo que nos apasiona a todos: Internet. También a lo largo de esta primera reunión, tuvimos la posibilidad de establecer la misión y visión del Tucumán Valley:

Tucuman Valley debería ser un emprendimiento sin fines de lucro que constituya un punto de reunión desde dónde se pueda fomentar e impulsar emprendimientos web en la región a través de la organización de eventos periódicos.

Tucuman Valley debería también posibilitar y promover las relaciones entre organizaciones y los individuos relacionados con la industria de internet, obteniendo valor a través de las conexiones espontáneas que podrían producirse tanto en el plano profesional, como también  comercial o personal.

Si bien Tucuman Valley no lucrará con la organización de los eventos; dependerá de sponsors y voluntarios para desarrollar sus actividades.

Tucuman Valley formará parte de una gran familia de valleys de Argentina, es por esto, que su visión, misión, y objetivos deberán estar en sintonía con el resto de los valleys.

Asimismo, compartimos qué no debería ser el Tucumán Valley:

Definitivamente Tucuman Valley no debería promover ni formar parte de ninguna accion que atente contra sus objetivos o los de los demás valleys.

Tucuman Valley debería promover la colaboración de personas unidos bajo un mismo objetivo, logrando así el beneficio de muchos. Por esto, se debería tratar de evitar totalmente involucrar a Tucuman Valley en actividades mezquinas que busquen beneficios personales, que pudieran manchar la buena fe de este emprendimiento.

Todos los participantes encontramos muy positivo el hecho de haber establecido estos objetivos para fijar claramente cuál es el camino que el proyecto debe seguir.

Es importante destacar que el Tucumán Valley es un proyecto colaborativo abierto donde cualquiera que lo desee puede sumarse y participar. Para todos aquellos que quieran sumarse, pueden seguir el proyecto de Tucumán Valley desde Twitter y Facebook, y si están dispuestos a involucrarse más con el proyecto pueden registrarse en el siguiente formulario de inscripción. Además por cualquier otra consulta pueden escribir a info@tucumanvalley.com.

La acción arranca el 9 de Septiembre con la gente de Clamp Consultora, y cerramos el día con nuestra presentación -que titulamos “Diseño Web for Export”. Mientras que el 10 de Septiembre, la jornada estará a cargo de la gente de Diloog y 100% Diseño. Además de las charlas, los asistente podrán disfrutar de una exposición de diseño.

Están todos invitados. Nos vemos!

CYMK 09

Con eso en mente, algunas de las features que nos propusimos fueron: “debería ser fácil de usar”, “debería estar integrado con google analytics”, “su instalación debería ser simple”, “debería poder publicar novedades”, “debería tener una galeria de imagenes”, “debería contemplar la posibilidad de tener temas o paletas de colores” y “debería poder ser integrado con google maps”. Todo esto solucionado a través de en un diseño one-page.

El nombre que recibió este proyecto fue “MicroSitios“, y si bien inicialmente fue un nombre temporal, terminó quedando como nombre oficial del producto.

A la tercera semana de desarrollo, la versión alpha de MicroSitios permitía a un usuario administrar todo el contenido de su sitio y permitía elegir entre dos posibles diagramaciones para su contenido. A partir de ahí, le dedicamos las siguientes semanas, a explorar/implementar las funcionalidades relacionados al look de cada sitio.

En la ultima semana agregamos las últimas diagramaciones que quedaban disponibles en la hielera: Diagramación de Blog, RSS feed para las novedades y Posibilidad de que un usuario agregue una imagen de fondo.

Con todo esto, MicroSitios se encuentra listo para salir a la cancha con un servicio que posibilita tener un sitio operativo en 48 horas, que cuenta con un panel de administración que permite actualizar y personalizar toda la información publicada en el sitio, posibilitando la elección de 18 alternativas distintas para su presentación.

Si bien el lanzamiento oficial de MicroSitios será este próximo 18 de Agosto, todos los interesados/curiosos pueden visitar su sitio oficial (que por cierto es un micrositio).

Es muy importante resaltar que nuestro entorno de trabajo se encuentra basado en Linux (prometemos en breve dedicar un post completo a las razones/motivos que nos llevaron a inclinarnos por Linux como plataforma de trabajo). La distribución que elegimos es Ubuntu en su versión 9.04, básicamente por su popularidad y crecimiento.

El primer tema que tenemos que encarar al empezar el setup de nuestro entorno de trabajo es la instalación de Ruby. La forma tradicional de instalar esto en linux sería con el siguiente comando:

  sudo apt-get install ruby

Esto funciona pero nos acarrea un problema serio debido a que apt-get (debido a los repositorios de Ubuntu) nos instalará la versión 1.8.7 de Ruby. Versión que ha resultado ser bastante conflictiva en lo que respecta a compatibilidad con las gemas más utilizadas.

La solución a este problema es ir por el camino más seguro y compilar directamente la versión 1.8.6 de Ruby. Para ello, estos son los pasos a seguir:

  sudo apt-get -y install build-essential libssl-dev libreadline5-dev zlib1g-dev
  wget http://rubyforge.org/frs/download.php/45875/ruby-1.8.6-p287.tar.gz
  tar xzf ruby-1.8.6-p287.tar.gz && cd ruby-1.8.6-p287
  ./configure --prefix=/usr/local --with-openssl-dir=/usr --with-readline-dir=/usr --with-zlib-dir=/usr
  make
  sudo make install

Existen patch levels más nuevos (el 369 para ser exactos) pero hemos tenido serios problemas de compatibilidad con capistrano, una gema cuyo funcionamiento es indispensable.

Una vez completada la instalación de Ruby, el paso a seguir es instalar rubygems. Para esto tendremos que seguir los siguientes pasos:

  wget http://rubyforge.org/frs/download.php/60718/rubygems-1.3.5.tgz
  tar xvzf rubygems-1.3.5.tgz && cd rubygems-1.3.5
  sudo ruby setup.rb

En este punto, podemos instalar las gemas básicas para trabajar con una aplicación Rails. Para esto, simplemente corremos:

  sudo gem install rails mongrel capistrano

A continuación tenemos que seguir por la instalación de los motores de base de datos y sus repectivos adapters para Ruby. Nosotros manejamos dos motores: MySQL y SQLite3.

Empecemos por el mas liviano… Para instalar SQLite3, tenemos que seguir estos pasos:

  sudo apt-get install sqlite3 libsqlite3-dev
  sudo gem install sqlite3-ruby

Los pasos para instalar MySQL son muy parecidos (aunque es necesario instalar más paquetes):

  sudo aptitude install mysql-server mysql-client libmysql-ruby1.8 libmysqlclient-dev
  sudo gem install mysql

Hasta aquí, estaríamos en condiciones de realizar la siguiente prueba:

  rails prueba && cd prueba
  ruby script/generate scaffold Persona nombre:string apellido:string
  rake db:migrate
  ruby script/server

Luego intentamos ingresar con un browser a http://localhost:3000/personas. Debería funcionar.

Aunque en este punto nuestro entorno de trabajo posee un corazón que late bien fuerte; nos falta una pieza sumamente importante: un framework para testing. En (in)signia estamos muy familiarizados con el Behavior Driven Development, por lo que en nuestros proyectos utilizamos Rspec y Cucumber. Para instalarlos necesitamos los siguientes pasos:

  sudo apt-get install libxml2 libxml2-dev libxslt1-dev
  sudo gem install rspec rspec-rails cucumber webrat nokogiri

Las dependencias que instalamos son requeridas por la gema nokogiri.

Resta instalar un buen sistema de control de versiones, actualmente el código fuente de todos nuestros proyectos se encuentra administrado con Git. Su instalación es relativamente sencilla, basta con ejecutar:

  sudo apt-get install git-core gitk

Con esto instalamos todos los comandos de  Git, su aplicación GUI (muy util cuando las papas queman) y el autocompletion para la consola.

Sin embargo, en (in)signia procuramos trabajar con las últimas versiones disponibles del software que utilizamos diariamente. Por lo que, luego de la instalación básica, normalmente hacemos:

  wget http://kernel.org/pub/software/scm/git/git-1.6.4.tar.gz
  tar xzvf git-1.6.4.tar.gz && cd git-1.6.4
  ./configure
  make
  sudo make install

A esto le agregamos un buen .gitconfig, como este:

[alias]
  up = pull --rebase origin
  br = branch
  st = status
  ci = commit
  co = checkout
  ql = log --abbrev-commit --pretty=oneline
  qlr = log --reverse --abbrev-commit --pretty=oneline
  pending = log --reverse --abbrev-commit --pretty=oneline master --cherry-pick master...
  undo = reset --soft HEAD^
  pick = cherry-pick

[push]
	default = matching

Y mejoramos nuestro prompt, agregando las siguientes lineas en nuestro .bashrc:

function parse_git_dirty {
  [[ $(git status 2> /dev/null | tail -n1) != "nothing to commit (working directory clean)" ]] && echo "*"
}
function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e "s/* \(.*\)/[\1$(parse_git_dirty)]/"
}
export PS1='\u@\h \[\033[1;33m\]\w\[\033[0m\]$(parse_git_branch)$ '

alias ack='ack-grep'

Y listo! Ya tenemos un entorno de trabajo bien sólido para encarar las exigencias de nuestro trabajo de la mejor manera.

Una de las metas que nos propusimos encarar, para este segundo semestre, es la reapertura de nuestro blog. Para lo que decidimos empezar por el principio -dicen que es un muy buen lugar para empezar- y fue así como encaramos el rediseño del blog.

Optamos por buscar un template que sea simple, creativo y que nos permita, mediante un poco de CSS, adaptarlo a nuestra imagen. El ganador fue el tema cleanr, desarrollado por Chandra Maharzan. (nuestros agradecimientos por este exquisito aporte!).

Luego de un hacking furioso al CSS del tema obtuvimos un template acorde a nuestros gustos. El resultado es este:

Rediseño de nuestro blog

Tal como dijo Lao Tse: “Un camino de mil leguas empieza por un paso”.  Esto es el comienzo de una nueva etapa.

Ahora si! Nuestro blog esta oficialmente reabierto! Pasen y vean!

Está inspirada en el popular Twitter y en la aparición de “bots” de chat, que son pequeños programitas que podemos agregar como contactos en nuestros programas de chat, e interactuar con ellos.

Followr está implementado como uno de esos bots, y es muy similar a Twitter, la gran diferencia, es que followr está pensando para Grupos de Trabajo, que trabajan con Proyectos.

Como usarlo? Muy simple. Es cuestión de realizar 4 pasos:

1. Agregar a followr@gmail.com a tu programa de chat (sólo Google Talk y clientes de Jabber están soportados por el momento).
   Followr te saludará con un mensaje de bienvenida diciéndote que ya estás registrado como usuario.

   

2. Crear un grupo o unirte a uno existente.
   Supongamos que tu grupo se llame INSIGNIA, para crear el grupo debes “decirle” a Follorw lo siguiente:

   CREATE GROUP insignia

   o bien, si el grupo ya existiera:

   JOIN insignia 

   (en ningun caso las mayúsculas y minúsculas son relevantes, solo se hace la diferencia para mayor claridad)

3. Crear un proyecto. Lo podés crear diciéndole a Followr lo siguiente:

   CREATE PROJECT insignia/mi_proyecto

   Si el proyecto ya existiera, no hace falta que lo crees, vas a ser partícipe de todos los proyectos de Insignia apenas te unas al grupo.

4. Ahora podés mandar mensajes. Todo mensaje está siempre asociado a un proyecto, registra generalmente un hito, un suceso o una novedad en el mismo. Para enviarlo, tenés que decirle a followr lo siguiente:

   insignia/mi_proyecto Acabo de comenzar a usar followr!

   Entonces tu mensaje “Acabo de comenzar a usar followr!”, será enviado automáticamente por chat a todos los usuarios que formen parte del grupo insignia.

Si quieres acceder a revisar todos los mensajes enviados, solo tenés que enviar el comando “web“, y Followr te responderá con un link, que al clickearlo, te autenticará en la aplicación y te mostrará todo el detalle.
El comando “help“, te proporcionará ayuda en cualquier momento (en breve publicaremos una cheat sheet, u hoja de ayuda, para el uso básico de Followr.

Nuestra respuesta inmediata a esta consulta fue: “el código de nuestros productos se encuentra testeados a través de procesos automáticos que garantizan su correcto funcionamiento”

Si bien no nos reconocemos abanderados del Behavior Driven Development o del Test Driven Developement, una de nuestras mayores preocupaciones ha sido la calidad y estabilidad de nuestros productos. Sabemos que al minimizar los ciclos de correcciones de fallas, ya sea durante el desarrollo de un proyecto o en fase de post-instalación, minimizamos también tiempos de desarrollo al igual que costos internos. Y para el cliente, la estabilidad y confiabilidad del producto que recibe le otorga una tranquilidad más importante que cualquier inversión: la seguridad de que cuenta con una herramienta confiable que hace lo que debe hacer, ni más ni menos.

En ese sentido Ruby on Rails, nos brinda un gran punto de partido, ya que se trata de un framework donde cada uno de sus componentes se encuentra testeado meticulosamente y no admite nuevos cambios sin que éstos verifiquen todos esos tests. Además adoptamos la sana postura de darle la mayor cobertura posible a nuestro código. Para esto, luego de probar varias alternativas, incluimos RSpec en nuestra “caja de herramientas”, un framework para testing (basado en Behavior Driven Development) de código escrito en Ruby, que puede ser integrado muy fácilmente a Rails.

Con todo esto, podemos transmitir la tranquilidad al cliente de que obtiene un producto que hace lo que debe, no porque podemos recitarle de memoria interminables capítulos de libros que hablan sobre la calidad del software, sino porque podemos entregar un informe que especifica el porcentaje de código fuente de su producto que se encuentra testeado, y si esos tests fallan o no.