Dec 17

Por qué me está gustando IntelliJ IDEA

 Hace ya un porrón de años tuve que elegir un IDE para trabajar con Java. Miré Eclipse y Netbeans, de aquella no existía IntelliJ y me acabé decantando por eclipse. Y desde entonces, más de 10 años ya, trabajando con eclipse.

Sin embargo, algunos compañeros míos usan IntelliJ y están muy contentos con él. También encontré unas estadísticas en las que IntelliJ se estaba usando cada vez más mientras que Eclipse parece que cada vez menos, aunque actualmente andan muy a la par.

Así que me decidí a probar IntelliJ …. y de momento me está convenciendo.

Me está costando acostumbrarme a los atajos de teclado o encontrar los comandos del IDE que quiero hacer, pero sólo es por la costumbre y poco a poco me voy haciendo a los nuevos atajos. Aparte de esto ¿por qué me está gustando?

Lo primero es el auto-compilar. Eclipse auto-compila siempre. IntelliJ por defecto no lo  hace, pero es una opción que se puede poner. El autocompilado de eclipse a veces hace el trabajo lento o pesado. En eclipse me veía frecuentemente esperando por barras del progreso de cosas que el eclipse estaba haciendo por debajo. En IntelliJ de momento no me está pasando.

Soy fan del editor vi. IntelliJ lo lleva por defecto, pero se puede activar/desactivar. Siempre tengo el gvim instalado en windows para determinadas tareas, ahora parece que no me va a hacer falta.

IntelliJ lleva la ventana de comandos del sistema empotrada por defecto. Habitualmente me gusta ejecutar los comandos de gradle, maven, git y subversion desde línea de comandos, porque me da la impresión de tener más control de lo que estoy haciendo. Lo de tener la ventana de comandos integrada en el IDE me está ayudando mucho. Sí, eclipse tiene un plugin opcional para poner.

Otra ventaja que resulta más o menos interesante es que el autocompletar de IntelliJ es más inteligente. Incluso autocompleta el nombre de la variable que estamos declarando, ofreciéndonos sugerencias. Por ejemplo, si tengo una clase MiClase y despues de poner el tipo MiClase le digo a IntelliJ que me diga el posible nombre de variable, me pone miClase.

Pero todo esto no dejan de ser detalles (bueno, quizás lo de las esperas de eclipse no sea tan tonto). Una de las cosas que me ha convencido totalmente de IntelliJ es que IntelliJ entiende por separado los classpath de test y de main. Tanto en gradle como en maven, hay directorios src/main/java y src/test/java y hay dependencias de compilado y dependencias de test. Tanto gradle como maven no incluyen para nada las dependencias de test en compilado o runtime, salvo que se estén haciendo test. Pues bien, eclipse no hace esta distinción en absoluto. En tu código de src/main/java puedes usasr clase que sean de test o de dependencias de test. En eclipse va, pero al compilar luego fuera de eclipse con gradle o maven, da error. IntelliJ sin embargo sí tiene en cuenta esta separación. Tiene su "classpath" de "proyecto_main" y "proyecto_test".

En fin, llevo ya un par de semanas con IntelliJ y me está gustando más que eclipse. Es posible que tenga que volver a eclipse cuando quera utilizar alguna cosa que no venga en la edición gratuita de IntelliJ.

May 30

Autocompletar en los IDE

autocompletar en javascriptPara trabajar siempre me gustan más los lenguajes estáticamente tipados que los dinámicamente tipados y entre otras ventajas, una de ellas es la de autocompletar de los IDE. Pero siempre que digo esto, alguien me comenta que si el IDE está correctamente configurado, los dinámicamente tipados también tienen autocompletar.

Bien, esto es cierto, pero sólo parcialmente. Imagina el siguiente trozo de código en un lenguaje estáticamente tipado, como java

public void metodo ( UnaClase parametro) {
   parametro.???
}

Cuando empezamos a teclear en la zona de ???, el IDE sabe que parámetro es de tipo UnaClase, porque se ve claramente, así que es perfectamente capaz de darnos los métodos y atributos públicos de parámetro para que elijamos uno.

Sin embargo, en un lenguaje dinámicamente tipado, si tenemos el código equivalente

function unaFuncion (parametro) {
   parametro.???
}

aquí el IDE no tiene ni idea de qué tipo es parámetro y de hecho, no puede saberlo, porque parámetro puede ser de cualquier tipo cuando el código se esté ejecutando, se puede llamar a unaFuncion() pasándole un entero, una cadena de texto, un objeto propio que hayamos creado o cualquier otro tipo que se nos ocurra. Así que el IDE aquí es totalmente incapaz de ofrecernos opciones, salvo que el lenguaje tenga algo común en todos sus tipos.

¿Cómo se apaña entonces para autocompletar?. Bien, un caso como el que acabamos de mostrar es imposible, pero los IDEs tienen sus trucos para ofrecernos opciones de autocompletar cuando es posible. Por ejemplo, en el caso anterior, si tenemos

function unaFuncion (parametro) {
   parametro.funcion1();
   parametro.funcion2();
   var a = parametro.atributo1;
   parametro.???
}

aquí el IDE ve qué cosas usamos de parámetro, así que cuando lleguemos a los ??? nos ofrecerá las funciones y atributos que ya hemos usado (funcion1, funcion2, atributo1), sean o no correctos y de hecho, pueden no ser correctos porque nos hemos equivocado al teclear o simplemente porque en tiempo de ejecución alguien nos pasa como parámetro algo que no tenga esas funciones ni atributos.

Otro truco usado por los IDE es el siguiente

function unaFuncion () {
   var b = new UnaClase()
   b.???
}

en este caso, se ve claramente qué contiene la variable b, aunque no tenga tipo definido, ya que estamos haciendo un new de una clase concreta y metiéndola en la variable. Si el IDE es capaz de encontrar en nuestro código la definición de UnaClase, será capaz de ofrecernos sus métodos/funciones y atributos … es justo el caso de la imagen.

Así que sí, los IDE pueden autocompletar en lenguajes dinámicamente tipados, pero con ciertas limitaciones.

Nov 23

Herramientas frikis vs amigables

friki sheldom big bang theoryCuando busco herramientas para trabajar o aplicaciones para instalar, gratuitas, me he encontrado con frecuencia que hay dos herramientas con éxito, pero que difieren entre sí en un detalle, su facilidad de instalación/administración y sus posibilidades de extensión. Una de las herramientas es lo que yo llamo "para frikis", suele ser una herramienta muy potente y configurable, pero que requiere muchos conocimientos para administrarla. La otra es la herramienta "amigable", que un administrador sin profundos conocimientos informáticos puede instalar y poner en marcha sin demasiados problemas, pero que hace lo que hace y no es tan fácilmente salirse de eso. Veamos algunos ejemplos

Eclipse vs Netbeans . Ambas muy aceptadas en el mundo de desarrollo java. Eclipse es la herramienta de frikis. Puedes bajarte un eclipse "pelado" que apenas hace nada y luego liarte a instalarle plugins según el tipo de desarrollo que vayas a hacer (C++, java escritorio, java ee, plugins, etc, etc). Netbeans, por el contrario, es una herramienta más monolítica. Sí, también tiene plugins que puedes instalar/desinstalar, pero basta compara la página de descarga de eclipse y la de netbeans, para ver que eclipse requiere más conocimientos para saber qué quieres bajar. De hecho, hay más entornos de programación basados en eclipse, como el de Android o el de Spring, o el Aptana, que sobre netbeans. Suele ser normal también encontrarse que se usa eclipse en los entornos de desarrolladores profesionales, mientras que usan más netbeans los programadores que están empezando.

drupal vs joomla . Ambos para la construcción de sitios web. Drupal es la herramienta de frikis, aunque tiene una administración bastante intuitiva, es más espartana, muchos plugins desarrollados y posibilidades realmenten sorprendentes. Joomla, sin embargo, tiene una administración más vistosa (aunque a mi me resulta menos intuitiva) y tiene bastantes y más vistosos temas que drupal. De alguna forma, drupal es adecuada para administradores con conocimientos que en un momento dado requiran instalar o desarrollar plugins que hagan cosas que se salgan de lo normal en un sitio web, mientras que joomla es adecuado para obtener rápidamente un sitio web vistoso. Basta mirar el número de plugins de drupal (más de 14000) y el de joomla (más de 7000).

Geoserver vs mapserver Ambos servidores web de mapas. Mapserver es el de frikis, ejecutable nativo, mucho más eficiente sirviendo mapas, pero sin una interfaz web de administración (salvo instalando plugins) y un horror para configurar los mapas, a base de editar ficheros con sintaxis específicas. Geoserver, sin embargo, hecho en java, algo más lento sirviendo mapas, tiene una interfaz web de administración muy intuitiva y sin muchos conocimientos de geoserver, en pocos minutos se puede tener funcionando y sirviendo mapas. Mapserver es adecuado para un servidor de mapas que no vaya a tocarse mucho y que se requiera que sea eficiente, se configura una vez y listo. Geoserver más adecuado si se va a andar cambiando con frecuencia los mapas servidos o va a tener que administrarlo alguien sin muchos conocimientos.

redmine vs trac. Ambos gestores de tareas/incidencias. Redmine es el amigable, con una interfaz web de administración muy intuitiva, mientras que trac venía sin interfaz web de administración cuando lo estuve mirando, aunque ahora ya la lleva. La administración se hace por línea de comandos con un comando "trac-admin". Eso sí, al menos cuando los instalé, ninguno de los dos es fácil de instalar, aunque redmine me dio bastante menos guerra.

Git vs Mercurial. Ambos sistemas de control de versiones distribuidos. Git, diseñado por linus torvalds, cuenta aparentemente con más comandos avanzados y de bajo nivel, dándonos más posibilidades de hacer más cosas. Mercurial, sin embargo, tiene los comandos necesarios para hacer lo que se necesita en este tipo de herramientas. Sus características avanzadas están deshabilitadas por defecto. Git gusta a los frikis, Mercurial tiende a ser más la herramienta de los que necesitan un control de versiones distribuidos y no quieren pelearse con ella, sino dedicarse a desarrollar su propio proyecto. Es curiosa la comparativa en que se dice que Git es como Wesley Snipes y Mercurial como Denzel Washington. Denzel Washington es todo un actor, pero tiene una vida real normal, nada interesante. Mientras que Wesley Snipes, quizás no siendo tan buen actor, es mucho más divertido por tener una vida real más agitada. Por cierto, en el artículo dicen que Subversion sería Morgan Freeman.

Aunque una de ellas no es gratuita, por supuesto, Windows vs Linux. No hay mucho que comentar, creo que todos conocemos las virtudes y defectos de ambos sistemas operativos. Todos sabemos cual es el amigable y cual el de frikis. Y de la misma forma, Android vs iOS, que creo que tampoco es necesario comentar

Y seguramente hay más, aunque en este momento, con mi mujer al lado dándole a la ruidosa aspiradora, no se me ocurren más.

Mar 26

Jugando con los IDEs para Grails

 Cuando me puse a jugar con Grails, cogí el IDE al que estoy acostumbrado, eclipse, y me puse con él. Enseguida empecé a echar de menos los autocompletar, la sintaxis coloreada y demás comodidades a las que nos acostumbran los IDEs, así que tocaba buscar plugins adecuados.

Los plugins que encontré para groovy y para grails me resultaban más bien escasos o incluso no se dejaban instalar. Al final conseguí una sintaxis coloreada de groovy, con el compilado automático deshabilitado y sin ningún tipo de integración con Grails. No se puede arrancar la aplicación Grails ni, por supuesto, depurarla.

Siguiendo con google, por las páginas de grails y asociadas, acabas llegando a que hay un IDE basado en eclipse y con muy buena integración con groovy/grails. Este IDE es STS (SpringSource Tool Suite). Pero yendo a la página correspondiente, resulta que para bajarlo me piden el nombre, el apellido, el teléfono, la empresa, mi puesto en la empresa, el sueldo, el tercer apellido de mis abuelos (de todos) y la partida de nacimiento, así que pasé totalmente de bajarlo.

También vi por internet que Netbeans soporta bien groovy y grails sin necesidad de plugins, viene ya integrado. Me lo bajé y lo probé. Mi primera impresión fue muy buena. Hace años, cuando usaba/probé netbeans, recuerdo que tenía un arranque muy lento y pesado. La nueva versión parece que arranca en un tiempo prudente. La integración con grails bien, se pueden arrancar las aplicaciones grails (no he probado a depurar, pero supongo que sí). Me bastó con abrir el proyecto grails ya creado con grails create-app para ponerme en marcha. Sin embargo, sigo acostumbrado a eclipse y hay cosas de netbeans que no me gustan, más por gusto personal que por defectos del IDE.

Así que me armé de valor, fuí a la página de STS, puse el nombre de mi compañero de mesa en el curro, su dirección, su teléfono, su tarjeta de crédito, le engañé para que me pasara su certificado de penales que también piden y me bajé el STS. Luego, Aitortxu en twitter me comenta de una página en la que se puede uno bajar STS sin descubrirle a nadie sus intimidades.

El STS una maravilla. Es un eclipse, por lo que ya estoy acostumbrado a él, y viene "tuneado" para hacer aplicaciones web, aspectj, una cosa que se llama roo (una especie de grails, pero puramente java), jpa, etc, etc. Grails y Groovy no vienen por defecto, pero hay una pestaña llamada "dashboard" en la que con un par de clicks nos baja los plugins correspondientes y funciona todo bien.

La sintaxis coloreada, ejecución, autocompletar y demás todo bien. Viene todo lo necesario para trabajar a gusto, aunque tanto plugin hacen el arranque y la instalación un poco pesados. El autocompletar como todo autocompletar en lenguajes no tipados: si sabemos de qué tipo es la variable, bien, si no lo sabemos, imposible. Así que me quedo definitivamente con STS. Aparte, me he puesto a jugar un poco con los proyectos JPA (viene con EclipseLink) y aun a pesar de no tener ni idea, lo que he intentado me ha salido a la primera o casi, lo que quiere decir que es más o menos intuitivo y robusto ante torpes como yo.

Feb 01

Acciones adicionales al salvar un fichero con Eclipse

 

Un compañero me mostró una característica interesante de eclipse. Es posible configurarlo para que cada vez que demos "salvar" a uno de nuestros ficheros java, realice en él algunas acciones que le indiquemos: arreglar los imports, darle formato al código, poner las llaves en todos los bloques if, while, for aunque no sean necesarios, eliminar variables locales o privadas que no se usan, etc, etc.

A todo esto se accede desde "window" -> "preferences" -> "java" -> "editor" -> "save actions" (en eclipse versión 3.4.1). Ahí nos muestra una ventana con un montón de acciones que se pueden hacer, junto con un ejemplo de texto java para que veamos cómo afecta.

Hace poco, comenté que he instalado Sonar y viendo algunas de las métricas que tiene en cuenta, veo que muchas pueden cumplirse sin dificultad símplemente configurando eclipse con estas opciones. Por ejemplo, Sonar considera incorrecto (warning) no poner llaves en un if, else o bucle que sólo tenga una línea. Poniendo esta opcion, no solo nuestros nuevos ficheros cumplirán esta métrica, sino que los viejos, según los vayams tocando para lo que sea, se iran arreglando solos.

Un pequeño detalle, ojo con lo de eliminar automáticamente los atributos privados y variable locales no usadas. Yo lo he puesto y según voy escribiendo código, tengo la costumbre de salvar con cierta frecuencia. Si escribo una variable local que voy a usar más adelante, pero todavía no la he usado y le doy a salvar, me la borra, por lo que tengo que volver a escribirla o darle al Ctrl-Z.

Más detalles en Accion adicionales al salvar un fichero con eclipse.

Jan 31

Debugger remoto en java con Eclipse

Bueno, es un tema muy sabido, yo también sabía que existía hace tiempo y mucha gente lo usa para depurar la parte del servidor en sus aplicaciones web. Yo, como desarrollo aplicaciones de escritorio, nunca me había preocupado por el tema.

Sin embargo, sí me ha salido la necesidad. Nuestras aplicaciones de escritorio como tales son realmente sólo interface de usuario, mucho java Swing sobre PCs con Windows. Pero esa, aunque es la parte más labiorosa y la que más líneas de código lleva y la que es más difícil de hacer bien, es lo que la mayoría de la gente considera la parte "tonta" de la aplicación. La parte "de verdad" de la aplicación es una ejecutable java que hace de servidor, que corre en una estación de trabajo Sun que ni siquiera tiene monitor ni teclado. El código de ese ejecutable se desarrolla y prueba por supuesto, en PCs con pantalla y teclado y eclipse. El software se instala y arranca en esas estaciones sun a base de "telnet" desde los PCs. Y por ello es muy difícil de depurar en el "entorno de producción".

Normalmente no es necesaria esa depuración. El ejecutable java que hace de servidor suele salir lo bastante bien del PC como para tener cierta garantía de que funciona bien. Y si hay algún problema, no suele haber problemas en arrancar el servidor con eclipse en el PC y depurarlo ahí de una forma normal. Pero no siempre es posible y, de hecho, tenemos un problema últimamente que requiere depuración en el entorno real, así que me he metido con lo de la depuración remota con eclipse.

El tema es bastante sencillo. Por un lado, basta con arrancar el programa que queremos probar con las siguientes opciones:

-Xdebug -Xrunjdwp:transport=dt_socket,address=1044,server=y,suspend=n

donde básicamente le estamos indicando con -Xdebug que debe admitir una conexión remota para debug y con -Xrunjdwp:transport los parámetros para esa conexión, así como que no debe esperar la conexión del debugger (suspend=n).

Luego, en eclipse, con el proyecto y los fuentes del programa a depurar montados, basta abrir la configuración de debugger (Run -> Debug Configuration) y crear una configuración de Remote Java Application para ese proyecto indicando los parámetros de conexión y el ordenador en que corre el ejecutable.

Por supuesto, aunque es una tontería, en la Chuwiki he puesto los detalles de la depuración remota con eclipse. Y hasta he puesto fotos, yo, que soy vago para capturar pantallas.

Sep 07

Jugando con el móvil y J2ME

Este verano me han regalado un móvil. No es que me hagan especial ilusión, de hecho el que tenía  lo usaba como hucha y me explico: es de tarjeta prepago, cada seis meses le echo dinero para que no caduque, pero habitualmente dejo el móvil apagado y en casa, por lo que el saldo se va incrementando, como una hucha.

Sin embargo, el móvil que me han regalado sí tiene una cosa que me ha hecho ilusión: Java.

Así que me he decidido a hacer un primer "Hola Mundo" para el móvil y así enterarme de qué va todo esto de J2ME.

Primero a la página de sun, a bajarme el J2ME. Ya empezamos con cosas raras (para el que no tiene ni idea, como yo). Lo que hay que bajar es el "Sun java wireless Toolkit 2.5.2 for CLDC". Bueno, yo esperaba algo así como un JDK o un JRE y no un nombrecito tan extraño. Urgando un poco en google vi que era eso lo que había que bajarse para hacer programitas para el móvil.

La instalación es sencilla. Primero te pide el directorio de tu SDK de J2SE (tienes que tenerlo instalado previamente) para añadirle la parte de J2ME. Luego te pregunta por un directorio donde instalar el Wireless Toolkit. Ahí mete un pequeño entorno de desarrollo y un par (cuatro) emuladores de móviles estándar, para poder hacer pruebas antes de meter el código en el móvil.

Luego, como soy muy bruto, pensé en hacer el programa a pelo, es decir, con el gvim y compilando en línea de comandos. Es la mejor forma de enterarse qué estás haciendo. Sin embargo, mirando tutoriales, no encontré nada que me convenciera, además, soy un "caga-prisas" incapaz de pasarme dos días buscando y leyendo manuales antes de ponerme a codificar. Así que me decidí por Eclipse y su plugin para J2ME, el EclipseME, que por lo que he visto en google, debe ser el más aceptado.

Una vez instalado el plugin, se le da a nuevo proyecto J2ME y te crea un proyecto para J2ME con todos las dependencias ya puestas y un ficherito jda por defecto. Ese ficherito jda por lo visto en algo parecido al fichero de manifiesto de java estándar, pero para móviles y es obligatorio tenerlo. Ahí se indica el nombre de la aplicación, el icono que tiene que tener y la clase principal de la aplicación (la del main(), pero que aquí no tiene main(), sino que hereda de MIDlet, al igual que los applets no tienen main y heredan de Applet).

Luego, mirando por google y copiando trozillos de código de un lado y otro, hice el "Hola Mundo". Un programita que saca en la pantalla del móvil el texto "Hola Mundo". Ahora queda arrancarlo en eclipse a ver si funciona.

Hay que configurar el plugin EclipseME indicándole dónde están los emuladores de móviles. Para ello se le indica el directorio del Wireless Toolkit de Sun, donde están esos cuatro emuladores que comenté antes, y el plugin los busca y encuentra. Una vez hecho esto y elegido qué emulador quieres (el de móvil estándar con pantalla en color en mi caso), ya se puede ejecutar el programa.

Sale una ventana con el dibujo de un móvil en la pantalla. Allí se ejecuta el programa que hemos hecho y vemos en la pantalla del móvil el "Hola Mundo". Con el ratón podemos pulsar las teclas del móvil.

Ahora sólo me queda lo más importante, generar el .jar y meterlo en el móvil de verdad, a ver si funciona. La pega es que de momento no tengo ni bluetooth, ni cable de datos, así que hasta que vaya de compras no veré el resultado final.