Una de las cosas que más me impresionó de Ruby on Rails, más que el framework en sí o el lenguaje, fue el excelente soporte que había creado la comunidad. Hablo específicamente de como se enlazaba tu proyecto local con GitHub y GitHub con Heroku, con lo cual podías tener el proyecto en producción en cuestión de minutos. Esto es algo que lamentablemente no he visto en Java en los cinco años que llevo dedicado a estos menesteres, y menos con un alojamiento de la categoría de Heroku (otro día hablaré sobre ello y el PaaS, etc…). Pues bien, el pasado 25 de Agosto, Heroku añadió soporte para Java. Este paso me parece crucial. Desde mi punto de vista, la gran fortaleza de PHP, RoR, etc… viene de la comunidad, es un lenguaje “accesible” a cualquiera, basta con comparar los hostings existentes para PHP y los existentes para Java. Hay otras plataformas para Java, por ejemplo, Google App Engine, pero desde mi punto de vista son mucho más restrictivas que Heroku. Como de todas formas esto es solo una impresión, he decidido seguir el Heroku For Java Workbook a ver qué tal resulta :)

Si entro en el repositorio PruebaGit que cree en este artículo, GitHub es tan amable de avisarme de que no encuentra un archivo README. En primer lugar, ¿qué es un README? Un archivo README contiene información genérica sobre el proyecto, como instalar, como configurar, como usar, licencia, contacto con el autor, bugs, etc… Para más detalles esta el artículo de la wikipedia (en inglés, el artículo en español es bastante malo).

En general en mi trabajo soy fanático de la internacionalización (i18n) y la localización (L18n), aunque la aplicación que este en desarrollo ni siquiera vaya a ser traducida nunca a ningún otro idioma. El motivo es sencillo, si uso localización, cuando necesite poner un botón “Buscar” lo pondré en un archivo, por lo que al final todos los botones de “Buscar” de la aplicación apuntarán al mismo archivo (al mismo recurso). Ya se sabe que los clientes son caprichosos y es más que posible que pidan que ese “Buscar” se cambie por un “Encontrar”… y ahí es donde esta la potencia de la localización, basta con cambiar la palabra en el archivo adecuado. Se puede argüir que gracias a los IDEs modernos es sencillo hacer un search & replace all, pero creo que la opción de cambiar directamente lo que deseas en un archivo gana por goleada. Aparte, en lo personal, me dá mucha rabia que los informáticos en general tengan la duplicación de código por el anticristo (o así debiera ser) pero no tengan nada en contra de la duplicación sin medida de literales de textos.

Actualmente, la aplicación de bloc de notas deja mucho que desear, no solo con respecto al aspecto gráfico o usabilidad de la misma, sino que además no esta integrada en el ciclo de vida. Una Activity tiene un ciclo de vida determinado y el programador se tiene que ajustar a él. Por ejemplo, si se arranca la aplicación y se le da a crear o editar una nota y a continuación al botón de atrás, la Activity se cierra inesperadamente. Para evitar este tipo de cosas, el tutorial propone dos soluciones:

Introducción Este tutorial pretende reflejar un ciclo de trabajo básico con Git, EGit y GitHub, crear un nuevo repositorio, añadir y borrar archivos y subir ese repositorio a GitHub. Si quieres saber que es un sistema de control de versiones, las diferencias entre un sistema de control de versiones centralizado y uno distribuido o por qué Git y no Mercurial o Bazaar, te recomiendo que le eches un vistazo a alguna de las referencias.