Posts Tagged eclipse

Eclipse en colores

Por si queréis probar con los colores en Eclipse. El leer mejor (más fácil) nuestro código nos puede ayudar a escribirlo mejor. :-)

Yo he cambiado el color de fondo y he resaltado algunos elementos sintácticos:

El color de fondo:
Window > Preferences > General > Editors > Text Editors > Appearance color options:

  • Background color = color personalizado R:217, G:217, B: 236 (un gris clarito para distinguir la ventana de edición del resto pero suficientemente clara para no tener que hacer muchos cambios en el resto de colores)

Colores “sintácticos”:
Window > Preferences > Java > Editor > Syntax Coloring > Java:

  • Inherited Method Invocations : Pink (R: 255, G: 0, B: 255). Esto hace que las llamadas a métodos heredados destaquen pero no demasiado.
  • Method Declarations: Orange (R: 255, G: 128, B: 0) y negrita. Esto hace que el inicio de un método destaque sobre el resto del código.
  • Methods: Dark green (R: 0, G: 128, B: 0) y negrita. Esto hace que los verbos destaquen frente a los sustantivos.

En fin, espero que os resulte útil. :-)

Tags: ,

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: , ,

Jetty como proyecto Eclipse

Jetty significa malecón en españolAcabo de leer la propuesta que hay sobre la mesa para llevar Jetty a eclipse.org e incluso formar parte de Eclipse 3.5 (Galileo) para este verano. Es interesante sobre todo porque los planes a largo plazo son involucrarse en mejorar el HttpService de Equinox (y supongo que la especificación OSGi del mismo).

Tags: , ,

Métodos estáticos y pruebas unitarias

El año pasado :-) he comenzado el desarrollo de un plug-in para Concordion sin pruebas unitarias. “¡Vaya tío chungo!”, estaréis pensando ahora mismo. Bueno, en cierto modo tenéis razón. Pero tengo una buena excusa. :-)

El caso es que he copipegado código del ejemplo de editor multipáginas que viene con Eclipse y también del WicketBench (un plugin para trabajar con Wicket del que pretendo plagiar más de una idea). Y resulta que este código “heredado” hace un uso bastante prolijo de métodos estáticos para obtener información de contexto y, sobre todo, de la plataforma. Y me viene al pelo el reciente artículo de Misko Hevery donde explica por qué los métodos estáticos son tan malos para las pruebas y delatan diseños deficientes.

En resumen: no tengo pruebas unitarias de mi código porque no puedo sustituir las llamadas a métodos estáticos por ningún tipo de doble. Cualquier colaborador puedo sustituirlo más o menos fácilmente con un doble (p.ej. un mock), pero un método estático está pegado “a fuego” a una clase, y no puedo sustituir una clase por otra… :-(

Claro está que estoy cambiando el código para encapsular las llamadas a métodos estáticos en clases de colaboración que pueda sustituir en mis pruebas. Así acoto el problema, tal y como Eric Evans aconseja al explicar el “anticorruption layer” (capa anticorrupción), y mejoro la facilidad para escribir pruebas para mi diseño y, por tanto, mejoro también mi diseño.

Tags: , ,

Editor para Concordion

Papá Noel me ha traído esta Nochebuena un plugin Eclipse para facilitar el trabajo con Concordion. Si abro una especificación (un fichero html) con el editor Concordion, se abre una ventana de edición con dos pestañas: una con la especificación y otra con la fixture (el fichero java asociado). De la misma manera, si abro la fixture (un fichero java) con este editor, se abre una ventana de edición con las mismas dos pestañas y los mismos contenidos. Las fixtures se editan con el editor Java estándar y las especificaciones html con el editor web, que a su vez tiene dos pestañas: una con la vista de diseño y otra con la de previsualización. Además, la vista de diseño web está dividida y muestra arriba la página web para editar en formato WYSIWYG y abajo en puro HTML.

He basado el desarrollo en el ejemplo de editor multipágina que viene con Eclipse y en el WicketBench, un editor para Wicket que hace muchas más cosas y del que he tomado prestadas algunas ideas también para el futuro. Sin embargo, aún tengo que trabajar mucho este plugin porque es la primera vez que hago algo útil con Eclipse RCP y tengo mucho que aprender. De momento, los siguientes pasos serán:

  1. hacer pruebas unitarias (para poder refactorizar)
  2. refactorizar (es mejor no mirar al código ahora mismo)
  3. crear automáticamente el desplegable en forma de site (ahora es un jar que construyo manualmente)

Podéis descargar el jar y simplemente dejarlo en la carpeta “plugins” de vuestra instalación de Eclipse.

Felices Fiestas a todos, por cierto.

Tags: , ,

Introducción a m2eclipse

Por fin he conseguido terminar la traducción del artículo “Introduction to m2eclipse” que comenté hace unas semanas. Espero que os sea de ayuda. Me gustaría también complementarlo con otro material en español que he encontrado en la red:

Para los que queráis ahondar en el tema (en inglés) os recomiendo el wiki del proyecto m2eclipse.

Tags: , ,

¿Maven + Eclipse = m2eclipse?

Bueno, parece que últimamente me estoy especializando en traducciones del inglés al español porque estoy traduciendo (con permiso de los autores) un artículo sobre el plugin m2eclipse que apareció este verano en TheServerSide. Espero que nadie que sea experto en traducciones lea las mías porque podrá sacarme los colores fácilmente.

Por cierto, el artículo lo estoy traduciendo a ratitos y surgió como consecuencia de una pregunta que hice en la lista “ecosistemas-software” (que aprovecho para recomendar) en la que encuestaba sobre las alternativas para usar Maven en Eclipse: m2eclipse y Q4E.

Cuando tenga terminada toda la traducción os lo haré saber.

Editado:
He cambiado la dirección donde he publicado la traducción. Espero que si hay errores en la traducción me lo hagáis saber para corregirlos, gracias.

Tags: , ,

Eclipse 3.5 será Galileo

El nombre clave de la versión simultanea de la plataforma Eclipse 3.5 será Galileo. Aquí tenéis los planes separados por proyecto y el resumen a modo de tablero de mandos. Me encanta ver el enfoque agilista de la planificación separando los “Must Do” (DEBE HACER) de los “Should Do” (ESTARÍA BIEN QUE HICIERA).

Tags:

Eclipse DemoCamps

No sé bien cómo he llegado hasta una lista de eventos llamados Eclipse DemoCamps pero, una vez más, he constatado que no hay ninguno organizado en España. ¿Alguien se anima? (La Fundación Eclipse ayuda, entre otras cosas, con 20 dólares por cabeza para la comida)

Tags:

Refactoring en Español (3)

Seguimos con el ejemplo de refactor del ejemplo del “videoclub”.

En esta entrega vamos a hacer un cambio parecido al de la entrega anterior (donde transformamos el método Customer.amountFor a Rental.getCharge), pero en este caso moveremos crearemos el método Customer.getFrequentRenterPoints y luego lo moveremos a Rental.

Extracting Frequent Renter Points

Decíamos al final de la entrega anterior que Fowler proponía un último refactor, pero que lo posponíamos. Ahora sí lo hacemos porque veréis que, en mi modesta opinión, es más afín a los siguientes cambios.

1. En Customer.statement sustituimos las ocurrencias de thisAmount por each.getRental(). (En Eclipse, si hacemos doble-click sobre thisAmount veremos que se iluminan todos los puntos donde se usa la variable).
2. Eliminamos la declaración de thisAmount

El código queda como:

        while (rentals.hasMoreElements()) {
            Rental each = (Rental) rentals.nextElement();
            // add frequent renter points
            frequentRenterPoints++;
            // add bonus for a two day new release rental
            if ((each.getMovie().getPriceCode() == Movie.NEW_RELEASE)
                    && each.getDaysRented() > 1)
                frequentRenterPoints++;
            // show figures for this rental
            result += "\t" + each.getMovie().getTitle() + "\t"
                    + String.valueOf(each.getCharge()) + "\n";
            totalAmount += each.getCharge();
        }

Hemos hecho este cambio para así eliminar el uso de thisAmount y ver más claro
el uso que se está haciendo de las demás variables locales. ¡No olvidemos pasar los tests!

Ahora nos fijamos en frequentRenterPoints.

Extraemos el método getFrequentRenterPoints (marcando desde el comentario “add frequent renter points” hasta el comentario “show figures for this rental” y haciendo Alt+Shift+M), pero nos quedará “un poco raro” porque estaremos incrementando la variable y luego asignando su valor en Customer.statement. Así que seguiremos refactorizando hasta tener en Customer.statement la siguiente linea:

            frequentRenterPoints += getFrequentRenterPoints(each);

Obsérvese que:
a) quitamos el parámetro frequentRenterPoints de la firma del método getFrequentRenterPoints que nos ha generado Eclipse. Hay que cambiarlo a mano, ahí ya no nos puede ayudar Eclipse. :-)
b) acumulamos el valor fuera del método (de ahí el “+=”); hay que cambiar el código del método para mantener la integridad semántica. Customer.getFrequentRenterPoints devuelve los valores 1 o 2 (dependiendo de si le corresponde bonus o no a la película que se está alquilando).
c) dado que, no sólo creamos un nuevo método sino que además cambiamos la semántica de las líneas de código originales, es muy importante que pongamos atención al javadoc del método

    /**
     * Returns the renter points corresponding to each rental. A two day new
     * release rental comes with a bonus.
     *
     *  each
     *       */
    private int getFrequentRenterPoints(Rental each) {
        // add bonus for a two day new release rental
        if ((each.getMovie().getPriceCode() == Movie.NEW_RELEASE)
                && each.getDaysRented() > 1) {
            return 2;
        }
        return 1;
    }

TESTS

Después de este cambio, vemos que Customer.getFrequentRenterPoints no tiene nada
que ver con Customer, por lo que hacemos lo mismo que hicimos con Rental.getCharge
y nos llevamos este método a Rental.

Para ello usamos Alt+Shift+V (pero esta vez desmarcamos la opción de crear el método
delegado), con lo que directamente Eclipse nos cambia la linea anterior a:

            frequentRenterPoints += each.getFrequentRenterPoints();

El resultado final de Rental.getFrequentRenterPoints es:

    /**
     * Returns the renter points corresponding to the rental.
     * A two day new release rental comes with a bonus.
     *
     *  frequentRenterPoints
     *       */
    int getFrequentRenterPoints() {
        if ((getMovie().getPriceCode() == Movie.NEW_RELEASE)
                && getDaysRented() > 1) {
            return 2;
        } else {
            return 1;
        }
    }

Observad el matiz del cambio en el javadoc.

TESTS y listo.

Tags: ,