Agustín Ventura
Ingeniería de Software
Por último y para acabar con el ciclo de vida, voy a ver el despliegue en Heroku. Primero te das de alta y te envían un mail de confirmación, con este email vas a una página en la que pones la contraseña y listo. Ahora hay que instalar el gem de Heroku
gem install heroku Una vez hecho esto, añado también mi clave pública a Heroku para poder comunicarlo con Git (increible esto… vaya ecosistema, me tiene alucinando).
Vale, una semana más tarde, siguiente capítulo, Git. En Subversion ya soy el experto de la empresa, así que mato dos pájaros de un tiro aprendo Git por el mismo precio :)
Ya lo tengo instalado siguiendo las instrucciones de Pro Git, así que seguimos para adelante, la sugerencia de usar co en vez de checkout ya que checkout es demasiado “verbose” me la voy a saltar también, me gusta lo verbose (soy de los que odian los splash screens de las distros de linux, me gusta ver el texto).
Cuando desarrollo aplicaciones web (y tengo tiempo) me gusta seguir una variante propia de TDD. Básicamente trato de ser exhaustivo con las pruebas y en este sentido JUnit es lo suyo, diseño el DAO y le hago pruebas unitarias, diseño la capa de servicios y le hago pruebas unitarias, es más, si tengo tiempo hago pruebas unitarias sobre las mismas entidades.
A las malas malas, JUnit me sirve para probar la funcionalidad de la aplicación antes de hacer la interfaz de usuario.
En mi trabajo, uno de los proyectos en los que ando metido es la estandarización de proyectos de desarrollo Java en entorno web, a todos los niveles.
A priori esto parece muy fácil y un trabajo bonito, pero el asunto se complica mucho cuando te das cuenta de la amplitud del trabajo:
Definición de herramientas a usar (IDE, gestor de versiones, herramienta de construcción...) Definición de framework de desarrollo (framework MVC, framework ORM, framework IoC...) Definición de estándares de código Formación del personal Con ésto no quiero decir que el desarrollo en Java sea demasiado complicado, más bien al revés, el entorno es tan flexible que puedes hacer auténticas maravillas y habitualmente encontrar múltiples soluciones al mismo problema, así que si no puedes aplicar una, te resultará muy sencillo aplicar la otra.
Para seguir el tutorial voy a usar mi viejo buen portátil (tiene ya 6 años), con una Ubuntu 10.04 y el siguiente stack de desarrollo (siguiendo lo recomendado en el tutorial):
Editor: gVim (y las extensiones de ruby de vim) Control de versiones: git (apt-get install git-core) Ruby versión 1.8.7 Y hasta aquí todo bien, no deja de ser todo apt-get install, ahora el tutorial recomienda instalar RVM (Ruby Version Management), un gestor de versiones de Ruby. El tema me suena, haciendo un símil con Java, yo puedo estar desarrollando con Java 1.6 pero querer compilar con Java 1.5 (por cuestión de compatibilidad o cualquier motivo), al parecer Ruby tiene una herramienta que gestiona este tipo de cosas… la verdad, tiene buena pinta, vamos a ver.