Pedro del Gallego's Weblog

Main | Next page »

martes diciembre 28, 2004

IGod & IDevil
La gente se divierte jugando con este nuevo icono pop. Tendre que buscar una foto mia y pasarla por el Gimp.

IBody The PlayBboy magazine

( dic 28 2004, 03:53:46 PM CET ) Permalink

lunes noviembre 01, 2004

JUnit, NUnit y TestNG

EL problema :
Hoy he tenido una mañana de perros, uno de esos dias en lo que te pones a tirar lineas de código sin mucho esfuerzo, pero cuando llega la hora del crear los test, estos como por arte de mágia se niengan a funcionar.

El caso es que estaba yo haciendo mi pequeña práctica para ingenieria del software II, bastante sencilla, cuando decido crear unos test con JUnit ... de repente el código no funciona ... lo reviso y joder el código estoy seguro de que tiene que funcionar, el error esta en una clase de no mas de 50 lineas...vuelvo al test... vuelvo al código... otro test... vuelvo al código... otro test... vuelvo al código....otro test...vuelvo al código...SOCORRO GOOOOGLE!!

Despues de un buen rato dando vueltas por la página de JUnit.. decido probar suerte con los demas enlaces... y llego a este post del señor Flower, a traves del blog de Cedric (El cual no leia pero que veo que tiene un monton de post y proyectos interesantes, entre ellos TestNG)

La causa :
El problema no estaba en mi código (ufff me estaba volviendo loco), sino en como entendia yo que funcionaba JUnit. Resulta que JUnit hace una instancia de nuestra clase sobre por cada metodo que vayamos a probar. En el código que pone Flower queda muy clarito.

El efecto :
Esto me ha hecho curiosar con otros dos framework de pruebas

NUnit : Esta framework es un porte de JUnit a C#, sigue las mismas bases, pero con algunas diferencias, escribiendo mi clase en C# esta pasaba el test perfectamente :)

TestNG : Este si tiene bastantes diferencias con respecto a JUnit, viendo el tutorial lo pirmero que me llama la atencion es el hecho que podemos usar anotaciones (segun el JSR 175) para introducir informacion sobre las clases y metodos que vamos a testear.

Para experimentar un poco he decidido pasar mis practicas a C# asi que en un proximo post os dare mis impresiones sobre este. ¿Habeis probado alguno de estos frameworks en vuestros poryectos?

( nov 01 2004, 12:38:38 PM CET ) Permalink Comentarios [3]

lunes octubre 18, 2004

Slides monografico JDK 5.0 pues eso aqui dejo las Slides para obtener un poco de feedback

( oct 18 2004, 11:06:41 PM CEST ) Permalink Comentarios [2]

jueves octubre 14, 2004

Anotaciones.
Preparando el monografico de JDK 5.0 he descubierto una caracteristica que me ha llamado la atencion por encima de las demas: las anotaciones.

Con as anotaciones podemos incluir datos sobre nuestro código (meta-datos, para ser mas exactos, incluso meta-meta-datos o meta-meta-meta-...-metadatos, aunque esto lo dejo para proximos post.)

Estas anotaciones no son simples "code-generators" tipo XDoclet, sino que pueden contener informacion para el compilador para la máquina virtual sobre como manejar ese codigo. Tambien se pueden usar para indicar parametros a un contenedor,... y para que mas pueden servir las anotaciones, pues para un monton de ideas locas, pero en lo primero que pense (sobre todo leyendo algunos los ejemplos) es que pronto apareceran muchos proyectos OS que nos indicaran el estado de nuesto código basandose en anotaciones tipo TODO, INPROGRESS, DEPRECATED... Lo importante, es que podemos crear nuestras propias anotaciones (que enprincipio son solo un conjunto muy limitado). Esto inevitablemete nos llevara a que Apache o Sun, creen un JSAL (Java Standard Annotations Library ;)... yo por el momento estoy intentando desarrollar una pequeña libreria de pruebas. con las siguientes anaotaciones:

@NotNull : Una etiqueta que indique que un parametro no puede ser nulo, seria una buena forma de de empezar a tener mas en cuenta el "diseño basado en contrato", esta genial etiqueta no es nueva, y C# tiene algo parecido.
@pre : Contendria un conjunto regla de asserciones que se deben cumplir antes de ejecutar un metodo
@post : Contendria un conjunto regla de asserciones que se deben cumplir despues de ejecutar un metodo
@Validate : Una etiqueta que el parametro debe ser parametro debe ser validado por el metodo X.xxx()

class Example {

void insert(@NonNull List list, @validate(methodValidate="validate.email", exception = "org.akuma.exception.mailValidationException") String email) {
// code can assume list and o are each not null,
// because an exception will be thrown if they are null }

@NonNull(menssage="method can´t return null") String getSomething() { // code cannot return null, or exception and/or
// compile time error occurs } }

Ejemplo de etiqueta :

import java.lang.annotation.Target;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Documented;

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target ({ElementType.PARAMETER})
public @interface NonNull {

String exception() default "java.lang.Exception";
String menssage() default "Parameter can´t be null"; }

Por ahora no se muy bien como modificar el codigo en ejecucion, supongo que a lo bruto podría usar BCEL o algo asi... ya veremos, a ver si hacen los dias un poco mas largos, que no nos da tiempo a hacer todo lo que queremos

( oct 14 2004, 03:53:15 PM CEST ) Permalink Comentarios [1]

martes octubre 05, 2004

El club de la lucha

Pillow Figth Club. Ohhh yo quiero ir ... seguro que se lo pasan con como enanos.

( oct 05 2004, 06:36:04 PM CEST ) Permalink Comentarios [0]

Jugando con CSS
Bueno un cambio de look
( oct 05 2004, 02:54:16 PM CEST ) Permalink Comentarios [158]

jueves septiembre 30, 2004

regexp y Tiger
Bueno yo sigo con mi monologo del tigre (por ahora no me aburro del juguete nuevo)

He descubierto un ejemplo muy gracioso que combina las nuevas caracteristicas de la API java.util.regex junto con generics y el nuevo loop.

import java.util.regex.*;
import java.util.*;
public class FindAll { public static void main(String[] args) { Pattern pattern = Pattern.compile(args[0]);
String text = args[1];

List results = findAll(pattern, text);
for(MatchResult r : results) { System.out.printf("Found '%s' at (%d,%d)%n", r.group(), r.start(), r.end()); } }

public static List findAll(Pattern pattern, CharSequence text) { List results = new ArrayList();
Matcher m = pattern.matcher(text);
while(m.find()) results.add(m.toMatchResult()); return results; } }

PS : Ejemplo robado sin piedad ni misericordia al señor Flanagan, que seguro que no e queja de que mandemos gente a su blog y vean que tiene un libro sobre el tema.
( sep 30 2004, 06:22:32 PM CEST ) Permalink Comentarios [0]

lunes septiembre 27, 2004

Terminologia : Tipos de objetos
[nota]YA me canse de describir siempre lo mismo en multiples articulos, transparencias, etc, asi que a partir de ahora esta sera una de mis paginas para referenciar y no tener que escribir 10 veces lo mismo. Lo ideal es que esto fuera un wiki, que estuviese en jH y que fuese colaborativo. Pero estoy un poco vago, y como no quiero crear un proyecto y luego dejarlo a la mano de dios pues lo hago aqui, eso si si alguien se ve con ganas de hacerlo que cuente con mi apoyo. [/nota duracion="Esta nota se autodestruira en la proxima actualización"]

Object / Instance/ Class
Un objeto tal y como lo describe The Java Language Specification.
Un instancia tal y como lo describe The Java Language Specification.
Un clase tal y como lo describe The Java Language Specification.

POJO (Plain Old Java Object)
Es un objeto que no implementaa ningun tipo de especificacion de componentes, bean o cilco de vida.
Es un acronimo de Plain Old Java Object

Javabean / Bean
Un objeto es un java bean valido si esta bien formado con respecto a la especificacion JavaBean. Esto es si el objeto tienen constructor publico por defecto y soporta la modificación y/o la recuperacion totalmente o en parte de su estado mediante llamadas a metodos setter y getter (getXXX(), setXXX() o isXXX(), donde Xxx identifica un aspecto de su estado.) Pueden represnetar tanto datos como funcionalidades.

Data Object / Entity Bean / Data Bean / PODO
Objetos que solo representan datos y que no contienen ninguna lógica de negocio. En ocasiones se sobre escribiben los metodos equals() y hashCode() otras se hacen serializable o XmlSerializables. No crean hilos, no contienen referencias a objetos que no sean de datos.

Entity Beans?
Session Statefull Beans?
Session Stateless Beans?
Message-Driven Beans?
( sep 27 2004, 12:32:37 PM CEST ) Permalink Comentarios [0]

domingo septiembre 26, 2004

Antipatron : Concrete Class Dependency

O el "Antipatrón" mas sencillo del mundo.

Estaba yo revisando un código antiguo, es decir refactorizando modernamente ;), cuando vi la peculiar forma que tenia de hacer las cosas y es que, como todos, mi forma de tirar código va variando segun los conocimientos (y modas) pero sobre todo segun los trompazos que me vaya dadon contra mis propios ladrillos de código, una de las cosas que mas rápido se aprende en la POO, es que cuanto menos dependas de algo mejor (otra cosa, es que lo pongamos en práctica pronto)

Pues bueno a lo que voy, para desacoplar una clase que depende de otra debemos seguir la maxima Interface Implementation Separation (apartir de ahora IIS, ummm mejor no ;). Veamos esto en código.

Antipatron : Concrete Class Dependency


public class A {
    private final B b;


    public A(B b) {
        this.b = b;
    }
}


public class B {
}

Como vemos A depende de una instancia concreta de B, con lo facil que seria esto:

Solución


public interface B {
}



public class BImpl implements B {
}

Con Esto reduciremos el grado de acoplamiento que existen entre la clase A con respecto de la B. Espero que esto le sirva a alguien para que no tenga que esconder código debajo de la manta como yo :P .

PS I: Ejemp tomado de la página de picocontainer.
( sep 26 2004, 06:04:00 PM CEST ) Permalink Comentarios [2]

viernes septiembre 10, 2004

El trigre : Cosas que me gustan y cosas que no Preparando un monografico sobre Java 1.5, me he dado cuenta de que varias cosas de este caracteristicas del lenguaje no me agradan.

Generics : Esta novedad me encanta, sencillez, limpieza y chequeo en tiempo de compilacion un ejemplo simple :

static void expurgate(Collection *String* c) { for (Iterator *String* i = c.iterator(); i.hasNext(); ) if (i.next().length() == 4) i.remove(); }
Donde aparecen los asteriscos deberian ir los signos de mayor y menor
Enhanced for Loop : Esta caracteristica me produce una sensacion ambigua, me gustan los nuevos bucles son mas limpios, mas cortos, mas compresibles, pero reelamente no añaden nada extra al lenguaje
for(Object word : wordlist) { System.out.print((String)word + " "); }
Autoboxing/Unboxing : Esta no me gusta mucho, para que me sirve esto, para ahorrarme una serie de castings. Creo que el marcar expicitamente el casting se autodocumentaba mas el codigo y no era algo demasiado tedioso.
Typesafe Enums : Esto simplemente es algo que llevavamos echando de menos hace bastante tiempo. Ya era hora !! :-@
Static Import : Otra de esas cosas que no se muy bien para que lo meten. Puede que evite en cierto modo "constant interface" dicese de esto (yo tampoco sabia que tenia este nombre :P
public interface Physics { public static final double AVOGADROS_NUMBER = 6.02214199e23;
public static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
public static final double ELECTRON_MASS = 9.10938188e-31; }
Pero tampoco me parece una gran solucion. no se tendre que echarle un ojo mas detenidamente. Aver si trealmente soluciona algo.
Metadata : Este es una gran caracteristica, pero esta demasiado verde. Va a conseguir que por ejemplo la documentacion sea mucho mas legible y util.
varags : Esta es otra caracteristica un tanto indiferente, o por lo menos menor, aunque en cierto modo bastante util podemo pasarle multiples parametros a un metodo, y este los almacenara dentro de un array de objetos.
public static void myprintf(String seperator, Object[] args...) { String sep = "";
for (Object o : args) { System.out.print(sep);
System.out.print(o);
sep = seperator; }
System.out.println(); }

Bueno un pequeño repaso antes de meternos mas a fondo con el. Hay mas novedades, como la que comente en el ultimo post Overriden Return Type. Como decian en la tele...Mañana mas.
( sep 10 2004, 02:17:39 PM CEST ) Permalink Comentarios [0]

lunes septiembre 06, 2004

Tigre : Overriding Return Types
No solo Rugi va a hablarnos del tigre, los demas tambien somos un poco zoologo

. Una de las nuevas caracteristicas que incorpora el tigre ;), es la capacidad de sobreescirbir el valor de retorno de un metodo al extender una clase. Esto al principio suena un poco raro, y al final a mi me sigue sonando igual de raro. Para que me sirve a mi esto. Bueno tomare un ejeplo prestado del ultimo libro de O`really sobre el tema "Java 1.5 Tiger: A Developer's Notebook"



class Point2D {
  protected int x, y; 
  
  public Point2D( ) {....}
  
  public Point2D(int x, int y) {.....  }
}



class Point3D extends Point2D {
  protected int z;

  public Point3D(int x, int y) {....}
  
  public Point3D(int x, int y, int z) {....}
}



class Position2D {
  Point2D location;
  
  public Position2D(int x, int y) {...}


  public Point2D getLocation( ) {
    return location;
  }
}

class Position3D extends Position2D {
  Point3D location;

  
  public Position3D(int x, int y, int z) {...}
 
  
  public Point3D getLocation( ) {
    return location;
  }
}

Pero claro, como siempre algo huele mal en dinamarca, donde esta la trampa, por que no se a los demas a mi crear un objeto padre con una interfaz definida, para luego heredar de el y modificar esa interfaz no me parece el mejor método de mantener la "insolation" (lo siento no me sale la palabra en español). Ojo una cosa diferente es sobrecargar un metodo con lo cual no variamos la interfaz, sino que la ampliamos creando un nuevo metodo y otra modificar la interfaz de un metodo que ya existe.

EMHO, que no es nada comparada con la de David Flanagan, Brett McLaughlin que no son dos desconocidos, este es un mal ejemplo, seguramente por que esta no es una buena caracteristica (si alguien ve algun caso en el que lo fuera podria indicarla?)



interface Point {}



class Point2D extend Point{...
}



class Point3D extends Point2D {....
}



class Position2D {
  Point2D location;
  
  public Position2D(int x, int y) {...}


  public Point getLocation( ) {
    return location;
  }
}

class Position3D extends Position2D {
  Point3D location;
  
  public Position3D(int x, int y, int z) {...}
  
  public Point getLocation( ) {
    return location;
  }
}

Esto seria solo un ejemplo de mejora, por que se podria afinar muchisimo mas ahora ..... ¿es solo un mal ejemplo o es una mala caracteristica del lenguaje?
( sep 06 2004, 07:43:12 PM CEST ) Permalink Comentarios [1]

jueves agosto 19, 2004

Fenomenos para-normales
Es curioso que cada cierto tiempo periodico, una euforia extraña se apodera de mi, me obliga a sentarme delante de la tele y contemplar imagenes que en un estado normal jamas veria. Pero esto en si no es lo mas raro, sino lo realmente espectacular es que le ocurre a millones de personas a lo largo y ancho de este planeta, ya sean de Alabama, San Petersburgo, Sidney o Pekin. Incluso tu que estas aqui leyendo seas, quizas, uno de los afectados por este sindrome. La gente lo llama normalmente "La Olimpiada"

Por que a ver si no es por este efecto olimpico, desde cuando que un tio sea el cuarto que alcanza mas distancia lanzando pelotas o que una señora sea la segunda que mas "platos voladores" rompe a cañonazo limpio es meritorio de portadas en periodicos y telediarios.

Bromas a parte me encanta las olimpiadas, porque yo soy de los que no paso de ver el futbol (aunque voy a hacer "footing" casi todos los dias, casi todos los dias vuelvo diciendo ya no voy mas). Pero es que disfruto viendo como la gente se lo curra. Por que por ejemplo, como co**nes hacen las niñas de gimnasia ritmica para dar tantas pirutas encima de una barra de 10 cm de ancho, por que a mi me puedes dar un pabellon entero y lo mas que hare sera hacer la voltereta. Y el salto de trampolin sincronizado, que me decis de eso, por que eso si que es parallel programming.

Otro curioso efecto olimpico es que llegan paises "inferiores" van y te la juegan. Por que que gane Estados Unidos o China vale, uno dice es que son muchos, pero es que viene Rumania y nos da una paliza al resto del planeta. Entonces es cuando uno se queda con cara de tonto y dices al colega del bar tio "Rumania que esta alli escondido detras del mar negro viene a ganarnos y encima querran entrar en la Union Europea despues de este feo que nos han hecho, con la ilusion que nos hacia la medalla de oro". Por que si señores, al final, como todo en la vida, como Mr Aznar o Super Bono, esto tambien consiste en hacer lo que sea para que te den una medalla.

Voy a seguir viendo la prueba de hoy, slalon en kayack por rio artificial (lo peor es que me estan dando unas ganas locas de aprender, por que parece divertidisimo) (y para los geek perdidos de la manos de Dios como yo , no Bruce Tate no esta en el equipo de USA :-P )
( ago 19 2004, 12:45:25 PM CEST ) Permalink Comentarios [3]

miércoles agosto 18, 2004

Esas malditas custom tags !!!!
Hay ocasiones en que me desespero, hace no mucho me encontre realizando un "refactoring" completo de una aplicación para un cliente, la aplicación en si era bastante sencilla, y en principio yo solo tenia que agregar un nuevo tipo de servicio, pero en una de las pocas ocasiones en que el cliente pide consejo y no solo "quiero que", ya que habia consultado antes con otras "consultoras" y le habian dicho que era mejor hacer una aplicacion nueva. Yo me ofreci a hacerle un "buen precio" (demasiado bueno diria yo). Bueno a lo que voy.

No hay nada que me desepere mas que ver como alguien que se salta por la cara las mas basicas tecnicas de diseño, en este caso toda lógica de acceso a datos estaba embebida en unas custom tags que llamaba desde las propias JSP.

Pues en estas andaba yo mosqueado cuando derrepente me vuelvo a encontrar con esto, pero en plan OS, y por duplicado en dos proyectos diferentes y uno es nada menos que JSTL con sus etiquetas con para el manejo de SQL y el otro es un proyecto de etiquetas para hibernate a lo que yo me pregunto. ¿El mundo se ha vuelto loco? ¿se me esta derritiendo el cerebro, me estoy volviendo tonto y esto es lo correcto? ¿ES la sucion mas comoda, la solucion correcta?.

Tengo que hacerme un hombre y seguir el koan de Aitor ¿Librerias?. Are you kidding?. I'm a fucking bloody XSL powered man!.
( ago 18 2004, 11:58:05 PM CEST ) Permalink Comentarios [5]

miércoles agosto 11, 2004

Cursos, cursos y mas cursos....
Sin lugar a dudas este verano, sin lugar a dudas va a ser el de que se me quite el miedo escenico, ya que he imparrtido varios cursos de distintatematica, unos con mas exito, otros con poco y otros aun por dar.

Lo primero que aprendes cuando das un curso es que puede haber gente de todo tipo, desde el reaky-guru que sabe mas que el resto junto, hasta el que te pregunta que es eso de un "if".
Otra cosa que aprendes es que si llegas con resaca al curso, jamas, JAMAS lograras que los ordenadores de tus alumnos hagan lo que tienen que hacer. Por mucho empeño que pongas (que tampoco lo pondras, por que te dolera la cabeza). Gracias a Dios la mayoria estara en peor condicion que tu asi que tampoco les importara mucho.
La tercera es que si vas a impartir un curso a la gente le pone cachonda ver código que tire, como empieces con tonterias de UML te quedas mas solo que la una
La cuarta es que si el curso lo impartes a un grupo de universitarios en periodo vacacional y en una escuela/residencia donde el "four rouses/cola" vale 2 no pagaras ni una copa. (Esto inevitablemente te llevara al segundo punto y al quinto)
Si tu alumnos te ven en un estado similar al suyo, te tomaran por un colega, no por su profesor
Los alumnos se enfadan si no les enseñas a picar teclas. JAMAS intentes DAR UNA VISION DEL CONJUNTO. El alumno contento es aquel que hace funcionar una aplicación sencilla, sin muchas lineas de código.

EMHO (En Mi Humilde Opinion, para los neofitos en listas de correo y otras frikadas), en un curso de 20 horas no se deverian tirar lineas de código, eso solo sirve para que pierdas el tiempo aprendiendo a manejar una API que se olvidara en 3 dias, mejor HABLAR sobre arquitectura, sobre como funciona una aplicacion web o sobre cualquier cosa que no te haga perder el tiempo. Por que mnuales de referencia y documentacion de API existen a patadas. Da igual que recibas un curso de 20 horas sobre RMI o sobre JDBC, tres dias despues deveras mirar el manual de referencia para acordarte de como se hacia para instancar el driver (DriverManager.yoQuesequeMetodo(conNosequeParametro)) pero una vez aprendes que debes usar un DAO para mantener todo el codigo de acceso en un solo objeto eso tardaras mas en olvidarlo (a no ser que esa noche te pimples 15 "four roses/cola", con lo que probablemente se te olvide hasta tu nombre). Y con esto no quiero decir que mis alumnos aprendieran que es un DAO, o un Front Controller (que ojalá lo hicieran). Sino que hay formas diferentes de ver que es lo que se debe enseñar. y para mi :

Los principios de diseño de la orentacion a objetos estan por encima de cualquier implementación de una tecnología, de cualquier API y por encima de Java, si no sabes buenas tecnicas de POO jamas haras buenas aplicaciones J2EE, aunque te sepas la API en hebreo cabalistico

Enseñar a alguien las API´s es enseñar a ser un "picateclas" (con todos mis respetos, por que por hemos empezado todos). Con esto no quiero decir que yo sea un buen o mal profesor. Eso dependera de cada curos, de cada momento y de muchas otras cosas.

PS I: A la gente que defendio mi manera de dar los cursos en Mollina gracias.
PS II: A la gente de Mollina a ver si mandis las fotos por aqui, y enseñamos en un proximo post lo que es el "espiritu Ceulaj" ;)

( ago 11 2004, 06:20:54 PM CEST ) Permalink Comentarios [4]

martes julio 27, 2004

Toolkit.
Con la llegada del verano aumenta las gaas del aire libre, y anoche tomando una cervecita con gente del gremio estuvimos hablando de que herramientas usa cada uno. Asi que he decidido hacer limpieza dentro de mi caja de herramientas

Entorno de desarrollo : Eclipse+Lomboz+ant, estoy muy contento con el, por ahora me resuelve todas mis necesidades, excepto cuando tengo que hacer algo en Swing (aunque ha decir verdad, las pequeñas aplicaciones standalone, las desarrollo en VB...no por velocidad sino por tiempo de desarrollo). Tengo que probar el pack que lanzo IBM hace unos dias a ver que tal, pero tampoco es urgente. Echo de menosa mi querido JEdit, pero se queda muy atras en prestaciones aunque cuando me pongo nostalgico lo uso :)
Contenedor de Servlet : Tomcat, sin competencia por documentacion, tambien me gusto hace tiempo resin, pero no es lo mismo.
O/R mapping : Hibernate. pero no me termina de agradar estar atado a una solucion no estandar, preferiria un motor JDO 2.0 pero habra que esperar, no suelo usar EJB, aunque despues de echarle un vistazo a la especificacion 3.0 estoy a la espera de un contenedor que lo implemente para experimentar
MVC : Struts, rodillo apache... no me gusta, y he intentado buscar otras propuesta como tapestry y webwork, pero no. Tengo ganas de darle una oportunidad a JSF, pero esperare a que este mas maduro.
Test unitario : JUnit, gracias Junit, tengo que escribir un tutorial sobre est para devolverle algo a este producto, quien se anima conmigo, un monton de mock objects, sacados de la red, aunque estoy por crear un proyecto OS, no se, tampoco creo que sea de mucha utilidad , ya veremos si me animo.
Loggings : Libreria propietaria, mia y solo mia, no merece la pena publicarla como OS por que existen muchas y mejores que la mia.
Librerias de apoyo en la capa de presentacion : He usado varias, pero ahora solo uso JSTL, cada vez me convence menos, quizas lo que me convezca menos sea JSP, no se. tendre que probar los motores de plantillas, aunque lo que de verdad me gustaria es no volver a tocar la capa de presentacion nunca mas :)
Bases de datos : MySql, Oracle. Me gusta Oracle, me gusta mucho, mas que DB2
Contenedor J2EE : JBoss/Weblogic, este si que quiero cambiarlo, veremos que pasa con Geronimo, pero si tengo tiempo quiero ponerme conj Jonas, Alguna experiencia en produccion ??
Code Generation : Xdoclet, anque creo que este proyecto tendera a desaparecer para crear una forma estandar de metadatos, o eso espero.
Otros :
- Jakarta commons es un básico para todos.
- JGoodies : look & Feel
- ArgoUML : modelado, pero esta verde, a veces no saca bien el código y me gustaria que e pudiese crear ejecutables a traves de MDA, como en tipo androMDA
Experimentando :
- Spring : para despliegue de JavaBeans, integracion con hibernate y AOP
- AspectJ : AOP, pero el tema lo veo muy verde
- picocontainer : no me ha gustado, que le vamosa hacer.

Pues esa son mis herramientas, algunas etan ya viejas y otras nuevecitas, que marca de alicates usais vosotros? ( jul 27 2004, 11:19:33 PM CEST ) Permalink Comentarios [2]