Cuando hablo de instalación de Ruby, no estoy hablando de la instalación base de ruby para hacer un “Hola  mundo”, sino una instalación como para crear una aplicación “de verdad” (básicamente aplicación web, con conexión a internet, manejo de xml, pruebas y build automatizado).

Habiendo seteado el contexto paso a describir los pasos comunes que logré identificar en todas las instalación que realicé y que voy a seguir la próxima vez que tenga que preparar un ambiente.

Vamos a comenzar por instalar Ruby usando apt-get, no importa si luego queremos utilizar otra versión, yo me inclino por comenzar instalando ruby con apt-get pues eso se encargará de hacer varios seteos. Entonces abrimos una terminal y ejecutamos

sudo apt-get install ruby

Luego vamos a instalar Ruby Version Manager (rvm). Esta herramienta nos va permitir instalar y administrar distintas versiones de Ruby en una misma máquina. Pero para instalar RVM primero tendremos que instalar git y curl, entonces:

sudo apt-get install git curl
bash <<(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer )

Cuando finalice la instalación de estos componentes cerramos la terminal.

Ahora instalaremos ruby 1.9.2 usando RVM, para ello abrimos una nueva terminal y ejecutamos

rvm install 1.9.2

El siguiente paso es installar RubyGem, un administrador de paquetes (que en ruby se llaman gemas). La instalación de esta herramienta consisten en descargar el paquete desde http://rubygems.org/pages/download , descomprimirlo y ejecutar setup.rb (ruby setup.rb). Con esto ya estamos en condiciones de comenzar a installar gemas, pero resulta que algunas gemas en su proceso de instalación incluyen un proceso de compilación de código C, el cual puede requerir de la existencia de ciertas librerías nativas en nuestro ambiente. Por suerte las mismas pueden instalarse fácilmente utilizando apt-get.

sudo apt-get install libmysqlclient-dev libpq-dev libsqlite3-dev zlib1g-dev libreadline5-dev libssl-dev libxml2-dev libopenssl-ruby libxslt1-dev

Ahora  si, podemos proceder a la instalación de dos gemas fundamentales: rake (ruby make) y bundler (un administrador de dependencias en un punto similar a Maven).

gem install rake
gem install bundler

Con esto estamos listos para comenzar, cuando creemos nuestras aplicaciones tendremos un archivo llamado Gemfile en el cual especificaremos las dependencias de nuestra aplicación (las gemas) y con solo ejecutar bundle install, bundler se encargará de instalar las gemas especificadas.

Espero que esto les resulte útil.

Si bien aún soy un principiante en el mundo Ruby, puedo afirmar que hacer el setup de todo lo mencionado arriba en un proyecto Ruby, me ha resultado mucho más simple que hacerlo para un proyecto C#, a pesar de la experiencia mucho más extensa que tengo con este último.

Más allá de lo chistoso (o lo triste) del título, este post es una continuación  de otro que escribí hace un par de dias sobre esta misma temática. En dicho post compartí algo de teoría junto con algunos links interesantes (el de artículo de Marrick es excelente) y en los cuales he encontrado justificación para algunas de las ideas que compartiré a continuación. Durante las últimas semanas he estado dedicando la mitad de mi tiempo en entrenar gente y la otra mitad al desarrollo de una aplicación y en ambos casos he puesto bastante foco en el tema de la cobertura de código lo cual me ha llevado a una reflexión profunda sobre el tema.

Si desarrollamos nuestra aplicación siguiendo un enfoque TDD extremo, siempre mantendremos un alto grado de cobertura, pues solo agregaremos código cuando haya una prueba que lo ejercite.

Si procuramos seguir las buenas prácticas de diseño la relación entre nuestros componentes será por medio de interfaces, lo cual nos permitirá utilizar mocking y asi superar la infantil excusa “No lo puedo testear porque tiene dependencias”.

Si nuestros métodos son cohesivos y hacen usa sola cosa, entonces será más simple testearlos.

Si hechamos mano del polimorfirmo, seguramente podamos evitar algunos “if” en nuestro código lo cual también ayudará con la cobertura.

Para cerrar este post, les comparto una situación que viví hace unos dias. Resulta que una de las personas que estuve capacitando durante la semana pasada hizo una demo de la aplicación que desarrolló como parte de la capacitación. La demo venia bien y en un momento le pedimos que mostrara una funcionalidad particular que no habia sido mostrada. Resulta que cuando la va a mostrar, la aplicación ¡pincha!, ja!  a lo que le pregunto: ¿y los tests? adivinen….no había tests para esa funcionalidad. Y cuando pregunto por el porcentaje de cobertura de la aplicación, resulta que no superaba el 40%. ¡Que mejor forma de ilustrar la importancia de estas cuestiones! Espero que este colega haya aprendido la lección.

Por último quiero agradecer a David Frassoni quien la semana pasada me dió la idea de escribir este post.

El siguiente post de esta serie lo dedicaré a analizar las implicancias/consecuencias de tener una alta cobertura y de definir un shipping criteria en base al mismo.

Continuará…

¿Qué es la cobertura de código?

La cobertura código es la cantidad de código (medida porcentualmente) que está siento cubierto por las pruebas. O sea, ejecuto las pruebas de mi aplicación y si hay alguna línea de mi código que nunca fue ejecutada en el contexto de las pruebas, entonces dicha línea no está cubierta. Si mi código consta te 100 líneas y solo 50 líneas están siendo ejecutadas al correr las pruebas, entonces mi cobertura es del 50%. La pregunta que viene a continuación es:

¿Qué beneficio tiene medir la cobertura? y más específicamente ¿que beneficios tiene tener una alta cobertura?.

Una respuesta genérica podría ser que aumenta la calidad de mi aplicación. Siendo más concreto podría decir que si tengo una alta cobertura, significa que gran parte me mi código está siendo probado y por consiguiente podria tener cierta certeza sobre el correcto funcionamiento de mi aplicación. Al mismo tiempo medir la cobertura podria ayudarme a detectar código innecesario en mi aplicación, ya que no se ejecuta.

La pregunta que surge a continuación es:

¿Qué porcentaje de cobertura es suficiente?

La respuesta no es única, existen distintos criterios y pueden resultar bastante polémicos por eso voy a tratarlos en otro post. Pero por ahora solo diré que para SimpleCov, lo idea es de al menos 90% y en Southworks soliamos perseguir el 80%.

¿Una cobertura del 100% asegura que mi código no tiene bugs?

De ninguna manera, una cobertura del 100% solo nos dice que todo nuestro código está siendo cubierto por pruebas, pero puede que las pruebas no esten contemplando algunas situaciones, o sea, me falta pruebas.

¿Qué necesito para poder medir la cobertura?

En primer lugar  es necesario escribir pruebas y en segundo lugar contar con alguna herramienta que permita medir la cobertura.En la actualidad los lenguajes más populares cuentan con herramientas para medir la cobertura. Si trabajamos con C# y escribimos nuestras pruebas con MSTest, entonces el Visual Studio nos ofrece la posibilidad de habilitar la medición de cobertura de código. Si en cambio trabajamos con Ruby, podríamos utilizar RSpec para escribir nuestras pruebas y SimpleCov para medir la cobertura.

Esto es todo por ahora, les algunos links interesantes sobre el tema:

• How to Misuse Code Coverage por Brian Marrick, lindo artículo sobre el tema escrito por uno de los firmantes del manifiesto ágil.
• Code Coverage Analysis, por Steve Cornett, artículo bastante completo, con bastante teoría sobre el tema
• Testivus on Test Coverage, del blog de Google Test, cuentito muy ilustrativo los criterios de Code Coverage

En el siguiente post voy hacer algunos comentarios sobre estos artículos.

Haciendo un poco de memoria, creo que mi primer acercamiento a este tema fue con Code Complete, el clásico de Steve McConnell. Pero no estoy seguro, tal haya sido cuando cursé la materia Calidad con Alejando Oliveros en Fiuba.

Comencemos por el principio. El términos generales podemos decir que el peer review es una técnica de revisión del trabajo producido por una persona, realizada por sus pares. El fin de este tipo de actividad suele variar levelmente dependiendo del campo de aplicación, pero usualmente tiene que ver con el aseguramiento del cumplimiento de normas/estándares, la detección de oportunidades de mejora y la validación (esto último es muy común en el campo académico, previo de la publicación de trabajos de investigación).

Bajando a concreto y hablando especificamente del ámbito de desarrollo del software, un peer review es una revisión de un artecfacto (código, especifición, etc) realizada por su autor y un conjunto de pares con el fin de evaluar su contenido técnico y/0 calidad.  La técnicas existentes para realizar este tipo de revisiones varian considerablemente en su nivel de formalidad. En un extremo podriamos encontrar el collective ownership de los métodos ágiles y en otro las inspecciones formales propuestas por el IEEE. En medio hay unas cuantas alternativas. ¿cual de todas es la más apropiada? Dependerá del fin concreto de la revisión y de la cultura de la organización donde pretenda implementarse.

Volviendo a la pregunta de mi colega que motivo estas lineas, asumo en primer lugar que su inquietud apunta a implementar la práctica de peer review en una organización y no a simplemente realizar UN peer review. Al mismo tiempo asumo que estamos habland de review en el sentido de revisión de artefactos y no de evaluar el desempeño general de una persona. Dicho esto, los principales puntos a considerar son a mi enteder:

1. El objetivo del peer review
2. La cultura organizacional
3. La conformación del equipo
4. El proceso

Si bien los items estan enumerados, dichos números no representan necesariamente su orden de importancia. Más allá de eso, tanto (1) como (2) son fundamentales para determinar la técnica concreta a utilizar y ello sin duda tiene impacto en (3) y (4).

En cuanto a (1), si el objetivo es la implementación de alguna práctica de mejora certificada como la propuestas por modelos como CMMi, entonces tal vez las inspecciones formales propuestas por Michael Fagan resulten muy convenientes.

En lo referente a (2), hay que tener mucho cuidado puessi en la orgnaización hay gente de gran antiguedad que puede sentirse amenaza por este tipo de prácticas. En casos así, la implementación puede llegar a resultar verdaderamente muy dificil y de no hacerlo con la debida precaución podría llegar a resultar contraproducente.

Respecto a (3) creo que el equipo debiera estar conformado por gente con cierto reconocimiento de sus pares, gente que ha demostrado sus habilidades técnicas y que es reconocida por sus pares independiente del título que ostenta dentro de la organización.

Finalmente respecto a (4)  resulta importante mirar el proceso completo, pues solo hacer revisiones y registrar los resultados, no va a llevar por si solo a la mejora. Es necesario definir que hacer a partir de los hallazgos de la revisión.

Algunas recomendación claves a la hora realizar revisiones:

• El foco es la detección, no la corrección
• El management no participa de la revisiones (a excepción de lo que se esté revisando sea algún artefacto de gestión como un plan)
• Lo que está bajo revisión es el artefacto, no la persona que lo produjo
• Entrenar a los revisores
• Preparar checklist para realizar las revisiones

Para los interesados en profundizar puedo recomendar algunos materiales que acabo de chequear en mi biblioteca:

• Capítulo 21: Collaborative Construction, de Code Complete (Steve McConnell)
• Sección 26.4: Formal Technical Reviews, de Software Engineering: A Practitioner’s Approach (Roger Pressman)
• Capítulo 11: Clean Code, de Agile Coaching (Rachel Davies)

Otro titulo importante en esta temática (pero al que no he tenido accesso) es Peer Reviews in Software, de Karl Wiegers.

Por último, les dejo algunos link interesantes sobre el tema:

• Experience with Fagan’s inspection method
• Goodies for peer reviews
• A history of software inspections

Espero este ayude a resolver las dudas de mi colega.

¡Nos leemos!

El primero es AgenCon, organizado por la sección argentina de IEEE. El mismo se desarrollará del 9 al 13 de Junio  en Córdoba. La fecha límite para el envío de trabajos es el 15 de Marzo.

El segundo evento es la edición 41 de las JAIIO, este año organizadas en conjunto con la UNLP entre el 27 y 31 de Agosto. La convocatoria de trabajos trabajos esta abierta hasta el 30 de Abril.

Finalmente el tercer evento que tengo en el radar es Foro Mundial de Educación en Ingenieria (WEEF: World Engineering Education Forum). Sinceramente nunca había nunca había escuchado hablar de este evento (tal vez porque no siempre se realiza en Argentina). El mismo será organizado por UTN y se desarrollará en Buenos Aires del 15 al 18 de Octubre.La fecha límite para el envio de trabajo es el 2 de Marzo.

Volviendo a los trabajos que tengo en mente, el primero es sobre el enfoque que estoy utilizando en UNQ para dictar ingeniería de software. El otro es sobre algunas ideas que he venido madurando para la enseñanza de la programación en los cursos introductorios de programación.

A continuación les dejo algunos de los links que se compartieron durante la discusión.

• http://management.iprofesional.com/notas/106590-Cuales-son-los-perfiles-IT-mas-buscados-y-que-salarios-se-pagan-hoy-en-el-mercado
• http://www.cessi.org.ar/documentacion/OPSSI_RRHH_dic2010.pdf
• http://www.encuestasit.com/Sueldo.aspx#

• Un giro en mi carrera profesional enfocándome en cuestiones de capacitación/entrenamiento. En este punto debo agreder a Southworks (la empresa donde trabajo desde 2009) y en particular a un conjunto de colegas que han colaborado en que pueda realizar este giro: MartinS, MatiasW, ArielS y EzequielJ.
• Mi vuelta al estudio.  Comencé a cursar la Maestria en Tecnologia Informática Aplicada en Educación en la UNLP.
• Mi incorporación como docente a la Universidad Nacional de Quilmes y particularmente mi cargo como docente responsable de la materia Elementos de Ingenieria de Software.
• La consolidación de mi proyecto musical.
• Una serie de cuestiones de caracter personal que no vienen al caso en este contexto.

Respecto de eventos fui orador en Codecamp y en Smalltalks,  participé activamente en el Agiles2011 y en el AO Tour y dicté un workshop en el contexto de ASSE/JAIIO.

Otro punto que quiero destacar es que he mantenido mi constancia en este blog. Durante 2011 escribí 88 post superando las 66 que había escrito durante 2010. Este incremento de casi 30% también se correlaciona con la cantidad de visitas que paso de casi 7.000 en 2010 a casi 11.000 durante 2011. Intentar superar estos números durante 2012 será sin duda una gran desafío.

Bueno, es todo, chau 2011. Me despido no sin antes agradecer a los lectores de este blog deseándoles un gran 2012 y esperando poder seguir aportandoles mis 2 centavos durante este nuevo año.

¡Salud!

Resulta que por estos dias, me encuentro entrenando a un grupo de programadores en C#. Fue en este contexto que me encontré hablando de las diferencias y relaciones entre interfaces, clases, estructuras (structs) y enumerados, ¡recorcholis! 4 artefactos del lenguaje que NO son objetos. ¡Y aún no expliqué eventos, delegados, tipos primitivos y atributos (anotaciones)!. ¡Cuantas cosas que explicar!

¡Cuanto más fácil seria explicar Smalltalk!

Entro a mi cuenta de Mercado Libre a ver los detalles de la compra. En mi lista de compras figura el item comprado junto con su precio (digamos $100). Hago click en el item para ver el detalle de la compra y me lleva a la publicación. Pero…. ¡rechorlis! la publicación ha sido actualizada, el precio ya no es $100, sino $80 y la especificación a cambiado.

Llamo al vendedor, explico la situación. El flaco comprende el problema y admite que hubo una actualización en la publicación. Me indica que me acerque al local asi arreglamos la situación. Parece que no va a haber problemas, mañana les cuento.

Si el flaco no tenia buena onda, yo estaba al horno, pues al parecer Mercado Libre no guarda “una foto” de la publicación al realizar la compra. Hablando tecnicamente, parece que la entidad compra, no tiene los detalles de la compra sino simplemente una referencia a la entidad publicación. Puede que esto sea asi explícitamente por diseño, pero desde el punto de vista del negocio, yo creo que es un Bug, pues yo como comprador quiero poder tener el detalle exacto de lo que compré independientemente de que la publicación sea actualizada.

Por otro lado miro mi lista de compras y veo que solo figuran las más recientes, las compras que realicé hace 11 meses no figuran en el listado. Mmmm esto tampoco me gusta, pues tampoco veo ningún link del estilo “Ver compras anteriores”.

Nota: si bien el post está escrito en primera persona, esta situación no me sucedió a mi sino mi hermano, pero yo la seguí de cerca e incluso la reproduje.