Archive for July, 2010

Separando configuraciones en Eclipse

Últimamente no hago más que probar IDEs. Sí, seguramente es que me aburro mucho. Bueno, el caso es que mi IDE preferido es Eclipse. He probado muchos y no es que sean peores (me ha gustado mucho IntelliJ su versión de pago por su colección estupenda de plugins y por el estupendo soporte para Grails), pero es que llevo muchos (quizás demasiados) años usando Eclipse y me da pereza cambiar. He probado también NetBeans, pero sigo sin conseguir ver que sea suficientemente mejor como para justificar el cambio. También he probado el Aptana para Rails y tiene buena pinta, pero creo que aún no tengo criterio suficiente para decidirme sobre un IDE en este entorno.

Bueno, el caso es que probando, probando… me ha vuelto a surgir la necesidad de tener varias configuraciones de Eclipse. Llevo mucho tiempo sufriendo la degradación de mi IDE cuando pruebo plugins que no están del todo bien, o cuando va pasando el tiempo y pruebo a desarrollar con Android, y con Grails, y con …. y al final la configuración del IDE es tan grande que empieza a degradarse todo. Y recordé que hace mucho estuvimos buscando, en una empresa donde trabajé, una manera de tener las instalaciones de Eclipse distribuidas remotamente para que todos pudieramos sentarnos en cualquier puesto de trabajo de la oficina, sin tener que depender de instalaciones locales.

Podría optar por tener varias instalaciones completamente separadas, pero me parece un poco excesivo. Es una solución sencilla, rápida y funciona, pero me parece excesivo. Así que decidí complicarme la vida y buscar en la web de Eclipse sobre las opciones de arranque (recordaba algo, así que no fue difícil).

Mi última instalación está en C:\eclipse-java-helios-win32\eclipse (sí, mi portátil tiene Windows, ¿qué pasa? :-( ) Como veis, no me complico mucho la vida. Despliego el zip directamente en C: con el nombre del propio zip. Así que la estructura que tengo para esta configuración por defecto es:

  • configuration/
  • dropins/
  • features/
  • p2/
  • plugins/
  • readme/
  • .eclipseproduct
  • artifacts.xml
  • eclipse.exe
  • eclipse.ini
  • eclipsec.exe
  • epl-v10.html
  • notice.html

Así que decidí crear un acceso directo con el que llamar a eclipse.exe con el parámetro -configuration C:\eclipse-java-helios-win32\eclipse\configuration-alternativa

Arranqué y todo parecía ir bien porque cambié el workspace de inicio y, según la configuración que usara me proponía uno distinto para arrancar. Pero arranqué con la configuración alternativa, instalé “Google Plugin for Eclipse” desde el nuevo “Eclipse Marketplace” y al arrancar con la vieja configuración me encontré con que también se veía ahí el nuevo plugin. Claramente no había tenido éxito.

Así que eliminé el plugin para dejar la configuración como antes (creo que hay una opción para volver atrás, pero nunca he sabido cómo es y no me apetecía desenfocarme) y moví la carpeta configuration-alternativa a C:\Users\jmbeas\eclipseConfigurations\alternativa\configuration. Modifiqué el acceso directo para ejecutar Eclipse con esta configuración alternativa y vi cómo, al arrancar, se creaba un fichero artifacts.xml y varias carpetas justo en el mismo nivel que la carpeta configuration.

  • configuration/
  • features/
  • p2/
  • plugins/
  • artifacts.xml

Y ahora tengo mi configuración para empezar a jugar con el Google App Engine completamente separada de la que tengo para jugar con Java o de las que tendré para jugar con Android u otras cosillas que quiera ir poniendo.

Espero que os resulte útil.

Tags: , ,

Consejos para un programador pragmático (2 de 70)

Nuevo intento de revitalizar este blog y mantener un poco de ritmo de publicación. Ahora mismo estoy por una parte ocupado en mi, de momento, infructuosa búsqueda de empleo, y por otra estoy sacando ratitos (pocos de calidad, la verdad) para hacer un pequeño proyecto personal con el que ponerme al día en los asuntos prácticos del cloud computing, las bases de datos no relacionales y lenguajes dinámicos. La Conferencia Agile-Spain 2010 tampoco ha resultado para mi como yo esperaba. Y llevo semanas dándole vueltas a cómo transformar agilismo.es es una comunidad de artesanos del software. Demasiadas cosas en la cabeza. Ya lo sé. Mucho ruido y pocas nueces. Ya lo sé. Quizás porque no he conseguido instalarme en costumbres sanas como “un ritmo sostenible”, lo cuál indudablemente ayuda mucho a obtener resultados (mejores o peores, pero todo es mejorable, ¿verdad?) y a tener tiempo para pensar y, consiguientemente, mejorar. De alguna manera, de eso va el consejo número 2.

CONSEJO #2

¡Piensa! En tu trabajo.

[Think! About Your Work]

Este consejo en el contexto del libro quizás no parezca más que un gancho para que el lector se sienta un poco “obligado” a seguir leyendo. Pero en la explicación que dan los autores está la idem. Pensar en tu trabajo, en lo que representa para ti, en lo que estás dispuesto a hacer para mejorar en él, es en sí misma una actividad difícil y que, para hacerla bien, nos exige mucha transparencia con nosotros mismos. Eso no todos estamos dispuestos a hacerlo. Al menos no siempre. Los autores nos piden que, además de hacer este esfuerzo, nos comprometamos a hacerlo de manera constante. Visto así, mejor me voy a ver a la tele (que con un poco de suerte el dichoso pulpo dice que la selección española gana el Mundial de fútbol). :( ¡Meeec! ¡Error! Bueno, al menos si quieres ser bueno en tu trabajo, tenemos malas noticias para ti. La fama cuesta, y aquí vais a empezar a pagar, con sudor.

Tags: , ,