Me vuelvo a mudar

Me voy de los servidores de wordpress, para mi propio servidor(o mas o menos) el hecho es que de ahora en adelante me pueden encontrar aqui:

http://caente.com/blog

Thinking in java 4ed

Yo admiro a Bruce Eckel, no se si será un gran ingeniero o programador, pero definitivamente es un buen pedagogo, las ediciones de thinking in java que he visto(la 2ed y la 3ed) estan muy bien escritos y realemente ayudan a refrescar conocimientos que se tienen, a reaprender cosas que uno creía saber y a aprender otras nuevas.

El señor Eckel había tomado como filosofía(no se si para la edicion seguía así) regalar el libro electronico y venderlo en papel, eso al menos a mi me parecía muy inteligente, ya que este es del tipo de libros que uno quiere en un estante, pues es al mismo tiempo lectura corrida y referencia. Pero ahora decidió vender tambien la edición electrónica, no sé si el hecho de que ahora trabaje para Adobe influirá en algo sobre su visión de lo comercial o si estará e problemas financieros, o ya cree que eso de regalar conocimiento y trabajo es para imbéciles, bueno en fin, que cuando aununcio en su blog que ya estaba el libro disponible, allá fui corriendo, pero fue grande mi desilusión.

De cualquier forma él está en su derecho de vender lo que hace, pero igual, que pena.

He llegado

Hace tres días que estoy en Mexico, si todo sale bien estaré trabajando en un apasionante proyecto de alta disponibilidad, un proyecto que integra varios sistemas distintos, así que espero tener pronto cosas interesantes que contar.

Tómese este post como un grito de alegría

Actualización: Alguien de mexico podría orientarme sobre los proveedores de internet y TV?

WordPress Turquía

Via menéame, me he enterado de la existencia de este sitio, que al principio se creyó era un clon de wordpress hecho por unos hackers salvajes con ingentes cantidades de recursos, lo suficiente como para copiar TODOS los blogs de wordpress, así como las cuentas de usuarios y demás.

Según explican ellos, los de wordprexy, en realidad son como un proxy para que en Turquía se pueda ver wordpress, pues está bloqueado, a mi me parece genial lo que han hecho, quizás a algunos les moleste que pongan publicidad en los posts, a mi en realidad me da igual, y además han sabido ponerla no demasiado escandalosa.

Quiero creer en ellos, que son sinceros y que como dicen en su about, “Cuando wordpress entre en Turquía nosotros salimos”.

Simplicidad JEE5

A veces los programadores, y los managers por supuesto, tienden a subestimar la simplicidad. Si tienen un proyecto que es facilmente abordable con un tomcat y jpa, les parece que es están siendo simplistas, y en nombre de la escalabiliadad prefieren usar un servidor JEE completo, como glassfish o jboss.

Pienso que siempre hay que medir el alcance del proyecto, no está mal tener varias aplicaciones que realicen distintas tareas en un solo proyecto, si esas aplicaciones tienen cometidos completamente distintos, por ejemplo,el sistema del que hablo en mi post anterior también tiene una interfaz web para los usuarios, una interfaz que quizás si esté sobre glassfish u otro servidor de aplicaciones, pero la aplicación de reenvío está en tomcat, por supuesto un tomcat más o menos afinado, pero para la tarea que va a realizar se basta y se sobra. Quizás si en un futuro cercano decidamos meter ambas aplicaciones en un solo servidor y entonces no valdrá la pena tener a tomcar u glassfish(si se usa) conviviendo juntos, y lo mejor será pasarlo todo a tomcat o todo a glassfish.

Pero en definitiva, que resuelve tomcat? Es un contenedor de servlets, se puede usar JPA o hibernate(o cualquier otra cosa) para la persistencia, soporta JAAS y JMX; y en general es más que suficiente para la mayoría de las tareas comunes en las aplicaciones. Quizás si en tiempo de diseño se decide que es necesario usar cosas como Message Driven Beans o etc, pues ya se verá, por otra parte pasar una aplicación de tomcat a glassfish u otro no es particularmente doloroso.

Profilers

Cuantas veces hacemos una aplicación web sin siquiera pensar en la escalabilidad? Quizás en proyectos serios las pruebas de carga sean cosa normal, pero estoy seguro que en muchos lugares simplemente se hace una aplicación web y ya, quizás algunas pruebas unitarias para estar seguros de que da las respuestas debidas y que tiene las validaciones correspondientes. Pero por lo demás se confía en la buena voluntad del servidor.

En ocasiones anteriores he sido obligado a trabajar de esa manera, hasta hace poco, que tuve la oportunidad de realizar pruebas de carga, bueno las estoy realizando, la aplicación en realidad es un puente entre varios elementos, un cliente remoto(no un navegador) que realiza una petición por http y espera la respuesta, en tanto la aplicación debe entrar a una base de datos(mysql) y modificar una fila, tras lo cual, luego de cierto procesamiento a la petición del cliente remoto, debe enviar esa petición procesada a otro sistema remoto, quién a su vez debe reenviar el mensaje a otro sistema remoto, esperar respuesta, agregar una fila a la base de datos y reenviar la respuesta a la aplicación web, quien a su vez la procesa y se la envía debidamente formateada al cliente. Y sí, todo ese enredo es inevitable…

Nuestro sistema(cliente remoto, aplicación web, y sistema remoto 1) debe soportar, para la primera etapa, 8000 conexiones concurrentes; pues bien por el momento solo tengo una laptop a 2GHz con 1 Gb de RAM, con Ubuntu 7.04 como SO; Al principio de las pruebas apenas lograba las 2000 peticiones, entre las 1000 y 2000 peticiones ya tenía time-outs, que son manejables, pero que preferiría no existieran.

Pero gracias al profiler de Netbeans, he logrado ir a los puntos comprometidos de la aplicación web, la más complicada, y tras algunos cambios pude ver la diferencia del uso de memoria de la pila, si antes llegaba rápidamente a los 300 megas, y montones de time outs ahora por fin llego a las 3000 peticiones con picos en la pila de 170 megas, y tiempos de respuesta aceptables.

Desgraciadamente el profiler de netbeans consume gran cantidad de recursos, por lo que falsea el resultado, por otra parte sería genial un profiler que supiera auditar varias jvm y además monitorear el rendimiento del sistema operativo en general. Más o menos esto puede lograrse con el profiler de netbeans y una herramienta como AppManager, pero aun es insuficiente.

Susto con groovy

Esta tarde me dado un susto terrible cuando me encontré este post, para que tengan una idea, el mismo algortimo, en la misma PC:
Results
ray.java 12.89s
ray.scala 11.224s
ray.groovy 2h 31m 42s

Sinceramente espero que este problema sea, como dicen en los comentarios, cuestión de que groovy realiza operaciones con BigDecimal, espero que sea arreglado… pues yo pienso continuar estudiando groovy.

El artículo está en inglés.

Sobrecarga de operadores

Como es presumible de mi artículo anterior, estoy dedicándole tiempo a los lenguajes dinámicos, más específicamente a Groovy, sobre todo por aquello de funcionar sobre la plataforma java, con la que llevo años trabajando, pues bien bajé el libro “Groovy in Action”(perdí el link) y más o menos me iba gustando el lenguaje hasta que tropecé con una muy agradable sorpresa, Groovy tiene sobrecarga de operadores…

Los de Groovy hicieron una movida interesante, asignaron cada operador a un método de las clases, es decir:

metodo	operador
plus	+
minus	-
div	/
etc	etc

Aqui está le ejemplo del libro, con algunas modificaciones, pues en el libro cada operador devolvía un nuevo objeto:

Estas son las pruebas:

Y esta la salida:

PD: Siempre me ha molestado que pongan imágenes en vez de codigo, pero simplemente resulta muy difícil lograr que le código se vea decente en wordpress

Tipado dinámico

De un tiempo a esta parte hay como una explosión de lenguajes de tipado dinámico, ruby, pyhthon(ya un poco veterano pero igual), groovy, etc. En los foros de java y C++ los desarrolladores tienden a despreciar o rechazar este tipo de tipado, para ellos (y durante un tiempo para mi también) hacer esto:

int x =1

era mejor que esto:

x=1

Pues da la impresión de seguridad, de saber lo que se está haciendo.

Inicialmente creía que la razón de los lenguajes de tipado estático era a causa de que en los 70’s y 80’s las computadoras no eran lo suficientemente veloces, y de alguna manera todos los lenguajes debían reservar memoria para cada variable, y saber el tipo es algo imprescindible para esto, pero luego me enteré que Smalltalk ya lo implementaba desde el principio, por lo que deduzco, y esto es una presunción mía, que el “gran culpable” de los prejuicios actuales sobre el tipado es C/C++, quien por su características de lenguaje de medio/bajo nivel sí implementa esta característica, así como el infierno de los punteros, y cero gestión de la memoria. Me imagino también que cuando surgió java habrán habido reticencias para aceptar que todos los objetos se pasen como refenrencias, pues incluso creo que el gnusmalltalk usa punteros (!).

Fuera de reservar espacio en la memoria, la otra razón para los tipos es la misma de los conjuntos matemáticos, es decir, un conjunto es un grupo de elementos que comparte propiedades, los cuales responden de la misma manera a ciertos eventos, etc. Bien, pero en la programación esto lo hace el compilador o intérprete, a nosotros como personas nos basta decir que:

x=2

y = x* 4

y==8

algunos podrían objetar que a la hora de la legibilidad este codigo es deficiente, pero si lo que se quiere es decir que x es un entero:

//x es Integer

x=1

… y ya, y de paso podríamos poner alguna otra información.

En definitiva no creo que el tipado dinámico implique lenguaje de juguete o lenguaje de protipado, pues como dije más arriba smalltalk lo tiene, y no creo que nadie se atreva a decir que es un lenguaje de juguete, solo un desafortunado, otro que usa el tipado dinámico es Haskell, aunque no es lo mismo, pues haskell es programación funcional, pero en definitiva la mayoría de los lenguajes modernos buscan precisamente acercarse a la programación funcional.

Por otra parte esto es algo que no se puede hacer con tipado estático, aunque quizás se pueda simular :

funcion decir(a){
    print a
}

funcion hacer(b,c){
    b(c)
}

hacer(a,”hola”)

Obviamente es un caso bastante inútil, pero estoy seguro que se capta la idea, en definitiva la funcion decir(a) puede ser cualquier cosa que acepte un argumento, sí, se pueden pasar funciones como argumentos, pues la mayoria de estos lenguajes, todo es un objeto, incluso las funciones, y fue esta características(y haber estudiado un poco de haskell) lo que me convenció de que los nuevos que llegan(o que llegaron ya) no son unos juguetes, sino que traen nuevas características que los viejos no tenía, ni podrán tener, no es casual que groovy se haya hecho el segundo lenguaje oficial de la plataforma java.

Simplicidad en java

Desde hace tiempo, con el surgimiento y ploriferación de lenguajes como python y ruby, java se ha ido ganando el estigma que una vez tuvo/tiene C++: es demasiado complejo. Pues bien, pienso que la complejidad de java es un mito alimentado por los sonoros y entresijados frameworks como Struts 1.2 o Swing. Que conste que no hago una critica abierta del tipo: “Estos frameworks son una chapucería, yo lo hubiera hecho mejor, pero no tengo tiempo”; no, lo que digo es que en muchos de estos framworks adolecen de una excesiva complejidad, por ejemplo Swing fue construido encima de AWT, y debían mantener la compatibilidad, cuando quizás lo mejor hubiera sido un inicio nuevo con ideas nuevas, pero por supuesto, esto a veces, y en este caso, no vale el costo, recordemos que Swing es desarrollado por Sun.

En el caso de Struts es más claro, ellos se dieron cuenta de que estaban haciendo algo demasiado complejo decidieron cortar por lo sano, o quizás no tanto, y lanzar Struts 2, el cual se basa en POJOS, y dejaron atrás herencias innecesarias.

Pues bien, esta perorata es a causa de mi nueva experiencia con JPOS, un framework para la implementación de la ISO 8583, para transferencias bancarias. Los desarrolladores de este framework sabían que su codigo estaría destinado a empresas con aplicaciones de una fuerte demanda, millones de transacciones al día, y aplicaciones que deben trabajar, como ellos dicen, 24/7; pero además estas aplicaciones deben soportar cambios a su código sin detenerlas nunca, y sin que se afecten los usuarios, que por lo general son bancos.

Obviamente una aplicación de estas características no puede ser excesivamente compleja, pues dejaría de ser mantenible al nivel que se exige, cambios en caliente. Por otra parte debe ser sencillo de implementar el complejo flujo de mensajes que están normados en la ISO. Y debo decir que todo esto se logra magníficamente, al principio es dificil asimilar JPOS, como siempre es difícil asimilar cosas sencillas que gestionan mecanismos complejos, pero una vez asimilado JPOS, se convierte en una herramienta muy poderosa, tanto, que ya he considerado sacarla de su ámbito financiero, a ver que tal me va.