Nos hemos plenateado, en repetidas ocasiones, cómo hacer para optimizar nuestros métodos. Simplificar las tareas y reducir los tiempos muertos. Esto es lo que hacemos:

• Hemos comenzado a familiarizarnos con CMS, en particular CMS Made Simple que parece ajustarse bastante bien a nuestras propias necesidades.
• Usamos herramientas de seguimiento de tickets, en particular el trac por ser: simple, bueno, claro, consiso.
• Hacemos control de cambio y versiones con el Subversion. Excelente herramienta, ayudado además por el Subclipse y el TortoiseSVN.
• Aprovechamos las capacidades de Debug del phpeclipse.
• Lo interesante es un nuevo link que hemos encontrador por la Web. Ahí pueden apreciarse 15 herramientas para conseguir más de la web. Es una muy buena lista, bien compilada, clara.

Esperemos que esto les sirva. Si quieren que profundicemos sobre alguna tecnología o técnica… solo tienen que decirlo .

Lo primero que hacemos luego de armar la estructura básica de directorios es, si es un proyecto que fue comenzado por otras personas, hacer un import de todos los datos originales.

Por lo general no hay problema, pero de vez en cuando nos aparece un error como el siguiente:

svn: Valid UTF-8 datasvn: Valid UTF-8 data
(hex: 72)
followed by invalid UTF-8 sequence
(hex: e9 75 6e 69)

¿Qué significa este error? Por lo general quiere decir que algún nombre de archivo tiene un carácter inválido. Por ejemplo un acento o ñ que nos está trayendo problemas.

Realmente el problema no es culpa Subversion, éste trabaja muy bien con utf-8, el problema es el sistema de archivos. En este caso en particular los archivos fueron pasados por el cliente y nosotros simplemente los copiamos, lo que no sabíamos es que los nombres tenían una página de código diferente a la nuestra y todos los tildes, ñ y demás caracteres “extendidos” estaban mal representados y svn simplemente no sabía que hacer con ellos.

Moraleja, cuando se produce este error, se debe tener mucha paciencia y revisar los nombres de los archivos, uno por uno, para ver si tienen caracteres raros. Si lo tienen hay que renombrarlo, usando el carácter correcto y finalmente insertarlo en el repositorio como siempre.

Obviamente, lo mejor es directamente no usar estos caracteres en los nombre de los archivos, ni tampoco en su contenido ya que son fuente de miles de dolores de cabeza con páginas de código y lenguajes con problemas para entenderlos, pero a veces no hay opción.

Una aclaración, en mi caso, cuando me refiero a caracteres raros, lo que sucedía era que el nombre del archivo se veía con un signo de pregunta en el medio, el cual obviamente no era intencional. Renombrando el archivo y poniéndole una letra acentuada o lo que sea correcta soluciona el problema sin romper (en teoría) nada.

En adelante les mostraré algunos trucos (tips, hints, ideas) para simplificar la tarea diaria de uso de Eclipse y permitir, al mismo tiempo, reducir los altos costos de aprendizaje que implican. En adelante cómo manejar un buen workspace y cómo hacer para que el compilador interno del Eclipse no nos genere conflictos con svn. El ejemplo está ilustrado con Eclipse 3.3, otras versiones deberían tener funciones similares pero quedan fuera de esta explicación.

¿Cómo preparar un buen workspace?

Al arrancar por primera vez un Eclipse, nos pasa que nos pregunta dónde vamos a querer tener nuestro workspace. Para el inexperto, eso podría significar solamente dónde va a poner Eclipse los proyectos Java. Como todo en Java, eso no es tan así. Lo que pasa es que Eclipse requiere guardar información temporaría, llamada metadata, y otros parámetros de configuración que solo dependerán de ese workspace.

En un comienzo podríamos pensar que es algo malísimo, porque tenemos un directorio muerto dentro de nuestra máquina con información que no entendemos. Pero no es así, ese directorio guarda información referente a los proyectos asociados, y es una genial alternativa para cuando uno trabaja con diferentes tecnologías o conjuntos de proyectos (imaginen que necesitan usar Java 6 para una aplicación, otra con Java 5 y otra con Java 1.4… ahora imaginen que cada una tiene diferentes configuraciones de variables y cuestiones directamente relacionadas con la configuración del Eclipse… esta información está toda guardada dentro del .metadata del directorio correspondiente al workspace). Podemos aprovechar esto para simplificarnos la vida.

1. Creamos 2 directorios directorio, ejemplo:
   c:\blog3f\src - dónde pondremos nuestros proyectos (o haremos un download de svn/cvs)
   c:\blog3f\ws - dónde apuntaremos el Eclipse
2. Configuramos un acceso directo a Eclipse, y dentro de las propiedades le agregamos a la linea de comando: “-data c:\blog3f\ws” sin las comillas.
3. Arrancamos el Eclipse, no preguntará dónde está el workspace, justamente, porque en el punto anterior le dijimos con el parámetro -data.
4. Configuramos ese workspace cómo nos guste.
5. Si queremos crear proyectos, recordar que la idea es que queden en c:\blog3f\src, entonces si queremos crear el proyecto Post1, en el asistente debemos ingresar tanto el nombre del proyecto (Post1) como el directorio dónde iría a dejarse (c:\blog3f\src\Post1)
6. Si queremos importar un proyecto (que sería el caso de algo que bajamos de svn/cvs) hacemos File->Import->Existing project into Workspace e indicamos el directorio (c:\blog3f\src). Nos dará la opción de seleccionar los poyectos existentes en ese directorio src.

Nota: recordar que si no hay un .project o un .classpath dentro del directorio del proyecto el paso 6, no encontrará el proyecto y habrá que simular un paso 5 apuntando al directorio que tiene faltantes el .project .classpath

¿Cómo evitar que los directorios .svn nos hagan un embrollo?

Si están acostumbrados a usar svn, les gusta el tortoise y entienden cómo funciona. Sabrán que un directorio .svn en cada directorio. El problema con esto es que Eclipse automáticamente los copia adentro del directorio compilado.

Si tenemos un directorio de compilación diferente a dónde tenemos el código fuente, terminará, el Eclipse, diciendole al svn que nuestro directorio compilado equivale a la rama de svn de nuestro código fuente. Dando diferente tipo de errores cuando queramos hacer un commit.

La alternativa es fácil, tienen que cambiar la configuración del workspace. Dentro de windows->preferences->java->compiler->building, miren la imagen,

En la próxima clase, cómo configurar un jboss con myeclipse, después @EJB 3 con cliente Swing remoto, después @EJB 3 persistencia (JPA)… sintonicen.