La coctelera se pasa a J2EE
Por ahora la mejor inocentada que he oido hoy.
Es la leche – y más para los que venimos pegandonos desde hace muchos años con J2EE – que la referencia a esta tecnología empiece a ser utilizada en inocentadas. A uno le da que pensar…
Cuarto aniversario de finis coronat opus a.k.a. fco 3
Hace 4 años, el 23 de Diciembre de 2002, oí leí por primera vez el termino weblog y aquel mismo día me hice uno. Por aquel entonces un alma caritativa llamada Anthony Eden, proporcionaba a través de una instalación de Roller alojamiento gratuito de blogs: freeroller.net. Y esta fue la primera y humilde casa de FCO.
Anthony, como era de esperar, se acabó cansando de pagarle el ancho de banda a gente como yo y la iniciativa, con el apadrinamiento de JavaLobby, paso a llamarse JRoller.com. Allí se encuentran aún (por pereza sobre todo) mi primer post, artículos referenciados por bloggers ‘A’ (en aquella época era ostensiblemente más fácil), anuncios sobre las nuevas maquinas de complejidad de Sun, articulos que me trajeron durante un tiempo varios cientos de visitas diarias, mi primera experiencia con Ruby (¡Febrero 2003!) y algunos de los recuerdos más bonitos de mi vida.
Por aquellos fechas empezaba a hablar más a menudo con mi primo, y en la primera reunión de jBilbo decidimos poner en marcha una plataforma de blogs para javahispano, y como era lógico me trasladé.
Montamos una versión no muy estable de jroller, y empezamos a funcionar. Incluso con los problemas técnicos derivados del estado de roller en aquella época fueron días de actividad febril en los blogs de la gente que pululábamos por allí (casi todos afectos al regimen): al, rugi, emillan, nacho, mondelo, vitxo, ...Cada día había 3 o 4 entradas interesantes en la portada de los blogs y me consta que fue a través de los blogs como muchas personas conocieron a la gente que estaba detrás de jH. Por desgracia la actividad de los miembros fue decayendo hasta el ritmo y la popularidad que tienen hoy (desgraciadamente baja).
Por varias razones, yo (y algunos otros) me fui alejando de jH, y al final acabo pasando lo que tenia que pasar… me mudé de nuevo. Y en este tercer y hasta ahora ultimo éxodo fui a dar a con mis huesos digitales a textdrive, eso si, con un nuevo y flamante dominio: finiscoronatopus.com.
Y aquí sigo. FCO ha pasado por momentos buenos, momentos malos, momentos intrascendentes, momentos históricos , idas y venidas tecnológicas, y en fin todo tipo de situaciones y recuerdos que forman parte ya de mi vida gracias a – ¡quien lo iba a decir!- ese extraño juguete que llamamos blog.
No sé a vosotros, pero a mi realizar este repaso me ha traído muchos recuerdos. ¡Larga vida a fco!
Como estan los tiempos 2
Visto como sponsored link en mi cuenta de gmail:
Java Development – www.mirchevideas.com – Outsource to Bulgaria Java development for 20 EUR / hour
Ainnssssssssss…......
JRuby on rails
Parece ser que la gente se esta haciendo eco del avance de JRuby, un interprete ruby escrito 100% en java. Lo ultimo es que han conseguido ha sido ejecutar una aplicacion sencilla escrita en Rails via JRuby (sobre Tomcat por lo que parece en el screenshot). Por lo visto incluso se ha realizado una implementacion de ActiveRecord (el ORM de Rails) sobre JDBC lo cual abriria las puertas al uso de practicamente cualquier SGBD como soporte de la aplicación.
De cualquier manera los mas ilusionante al menos para mi no son estos detalles tecnicos de ultima hora sino la posibilidad de convergencia entre las dos plataformas. Aunque pensandolo bien quizas lo más complicado para esta union de fuerzas no sea el aspecto tecnico, sino el publi-politico …. ummm….¿que tal llevaria SUN la separación del hasta vinculo indisoluble entre lenguaje y VM? ... ¿ y si esa separacion tuviera su origen en un framework como una creciente comunidad detras y una filosofia bastante distinta?....no sé…no sé….
Una imagen vale más... 1
Via Jason
Seam 1
Unos cuantos sitios (¿no javahispano ?) estan hablando ya de la ultima creacion de Jboss : Seam que viene directita de la mano de Gavin King, el hombre detras de Hibernate.
Basado en estandares (EJB3 y JSF) pretende simplificar el proceso de creacion de aplicaciones web, algo que desde que RoR llego al gran publico parece una autentica fiebre en el mundo java (una fiebre que me hubiera gustado que hubieramos pasado hace +-6 años). La revisión de los 30 segundos que acabo de hacer parece traer buenas noticias al mundo java. Buena muestra de ello es el ejemplo de registro de la documentacion y la anotaciones que usan tanto en el modelo:@Entity
@Name("user")
@Scope(SESSION)
@Table(name="users")
public class User implements Serializable ...
@NotNull @Length(min=5, max=15)
public String getPassword()
{
return password;
}@Stateless
@Scope(EVENT)
@Name("register")
@Interceptor(SeamInterceptor.class)
public class RegisterAction implements Register ...Aun asi buen punto para la gente de Jboss en general y para Gavin King en particular. Un proyecto interesante al que seguir la pista y al que le auguro una de las posibilidades más altas de erigirse vencedor entre la nueva generación de frameworks ala RoR que estamos viendo en los ultimos tiempos.
Unos tanto y otros tan poco
Joel Spolsky hablaba ya hace unos meses de la gran brecha técnica y capacitativa que existe entre unos desarrolladores y otros.
No podría gritar lo suficientemente alto lo acertado de sus palabras. En ese proyecto con codigo fuente legado que lleva meses atormentándome, hoy encontré algo que me hizo sonreír. En el barrio de al lado (léase otro paquete del aplicativo) de todas esas mezquindades que citaba , habia codigo que no recordaba y que implementaba algo parecido al API de filtros de los Servlets, cargaba clases de manera dinámica y utilizaba un enfoque basado en interfaces a la Spring.
Y todo ello data, al igual que la ponzoña, del año 1999-2000 cuando habia gente todavía escupiendo HTML desde los servlets. Un hálito de orgullo nos ha embargado por un momento.
Lastima de vuelta a la puta realidad del otro 80% del codigo.
El principio CAN 2
Asi de sencillo. Esta mañana estoy perdiendo más tiempo del recomendable leyendo sobre el tema:Components Aren’t Necessary.
'99 echoes: Eso del encoding no va conmigo... 5
Acabo de terminar de arreglar uno de los bugs que más tiempo me han consumido ultimamente y que de más de mala hostia me han puesto (los errores ncompresibles aunque obvios siempre son los más irritantes).
Por causas ajenas a la dirección de la pelicula que mejor no recordar mirar el post de los disparos me encontraba en una incomoda situación.
Cientos de las paginas de la aplicación que estoy migrando tenian el bonito detalle de contener instrucciones de javascript como la siguiente:
var usuario = "Iñigo cön más acentos y simbolos rarös que el copón"
Variables que venian directitas de una BD que no esta configurada como UTF-8.
Despues de una épica migración de [jdk 1.1, Xalan&Xerces ‘99, JRun 2.2, .class] a [jre 1.4.1, Xalan&Xerces 2.7.0, JRun 4.0, .war] – que daría por si misma para otro post – me encontre con la agradable/desagradable sorpresa de la introduccion de manera automatica en la nuevas versiones de xalan de la etiqueta en el html resultante del parseo. El problema surgia al no haber especificado encoding en el parser hasta ahora (sooooooo ‘99) ya que el charset que indicaba en la etiqueta meta era UTF-8 (el default).
Algunos navegadores de verdad conseguian tragarse el html y seguir funcionando, pero otros – el bloody fucking standard en mi client e- no.
Bueno no pasa nada, me dije. Una pequeña instrucción al parser y arreglado:
transformer.setOutputProperty(OutputKeys.ENCODING, "ISO-8859-1");Señor IT Manager :¿Y esto?Pobre Developer/Product Manager: Un error en (Mente del IT manager)bla, bla, bla, bla, bla, bla, bla, bla,(Mente del IT manager) y no lo cambia.
SITM:¿Y cuanto tiempo te va a llevar cambiarlo?
PDPM:Pues…(Mente del Pobre Developer/Product Manager)ni puta idea(Mente del Pobre Developer/Product Manager) un par de horas.
SITM. Estamos yendo muy lentos…y bla, bla …..
Despues de un buen rato en internet encuentro una solución sencilla y lenta (recordar que hablamos de cientos de XSLs), que no se muy bien por qué si funciona:
<xsl:output method="html" encoding="ISO-8859-1"/>
Como no estoy dispuesto, primero a tener que tocar todas las xsls, segundo a confiar en que todas las personas (aficionadísimas al copy&paste de codigo fuente prehistorico) se encarguen de especificar el output en las nuevas xsls que creen, y por ultimo a romper el principio DRY que intento seguir, decido seguir escarbando.
Me bajo el codigo fuente de Xalan, lo traceo, lo compilo, etc… y encuentro el ¿bug? ¿issue? ¿feature?. Necesito especificar el metodo de salida del parseo :
serializer.setOutputProperty(OutputKeys.METHOD, "html");
Una sola linea de codigo y todo el aplicativo empieza a escupir ISO-8859-1. Despues del cumplido mail a la lista de desarrollo de xalan-dev, abro el editor y empiezo a escribir este post como copia de seguridad de mi cerebro mientras pienso como cojones voy a justificar el tiempo empleado en toda esta mierda.
Y la respuesta es muy sencilla. No voy a poder. Punto.
PS: Interesados en un post “No puedes justificar lo invisible” poned +1 en los comentarios.