Media Net Software KIT Blog

Como sabeis, cada año se celebra en Amberes el Devoxx (antes conocido como JavaPolis). Como Medianet no se pierde una, este año me ha tocado a mí representarnos en este evento que ,sin duda, es el más importante en Europa relacionado con el mundo java. devoxx.com

Los días se repartían en dos bloques, los University days (lunes y martes) y los Conference days (resto de la semana).

En el primero de ellos, las charlas eran de tres horas de duración y estaban orientadas al aprendizaje, al estilo de clases magistrales impartidas por algún experto.

Algunas de las mejores charlas a las que asistí tuvieron que ver con Java EE 6 y SOA. En la primera de ellas, Antonio Goncalves se marcó una serie de demos para presentarnos las novedades de Java EE 6, os pongo algunas de las características que más me llamaron la atención:

- Servlets 3.0: Presentó las nuevas anotaciones @Servlet que, por ejemplo, eliminan la necesidad de declarar y configurar el servlet en el web.xml. Además, ahora, los servlets tienen soporte para peticiones asincronas.

- EJB 3.1: La principal novedad residía en lo que han llamado EJB Lite, que permite empaquetar un EJB dentro de un WAR. con ciertas limitaciones. También se ha simplificado el tema de las interfaces, ya que si no se usan no es necesario crearlas. Otro punto a favor es que ahora los EJBs de sesión pueden tener métodos asincronos simplemente usando la anotación @Asynchronous sin necesidad de hacer nada más. Por último han creado un nuevo servicio que llaman “Time Service” que usando la nueva anotación @schedule permite programar ,como si de un video se tratara, el EJB para lanzar sus métodos en un momento determinado, al estilo del comando cron de Unix.

- JPA 2.0: Se ha enriquecido JPQL para dar soporte a joins en subqueries con la clausula FROM. También se ha incluido un nuevo nivel de cacheo que se puede usar con la anotación @cacheable. Se han incluido nuevas posibilidades para realizar los bloqueos (Lock, Read and Lock, Lock and Read…)

- JSF 2.0: Ahora JSF 2.0 está integrado en Java EE 6.

- BeanValidation 1.0 : Este nuevo paquete presenta funcionalidad para validar beans usando notaciones del estilo @NotNull, @size, @valid…. Se integra con JPA 2.0 y JSF 2.0

- JAX-RS 1.1: Ahora soporta RESTFul services. Añade notaciones para especificar diferentes tipos MIME (@Produces(”image/jpeg”), @Produces(”text/plain”)…)

Si quereis ver una lista completa y detallada de todas estas novedades podeis hacerlo en http://java.sun.com/javaee/technologies/javaee6.jsp

Ahora mismo, el único servidor que soportará el 100% de la nuevas características de Java EE 6 es Glassfish (implementación de referencia) que estará disponible en versión v3 el 10 de Diciembre. Ya podeís estar atentos. https://glassfish.dev.java.net/

Como he comentado más arriba, otra clase magistral que me gustó especialmente por su claridad y por el enfoque, fue la impartida por Sang Shin evangelista de SUN.

Estuvo presentando, con multitud de ejemplos, los fundamentos de SOA. Desde lo que era un WSDL hasta las tecnologías que permitian orquestar e integrar los distintos servicios BPEL y JBI. Usando para ello Glassfish ESB y NetBeans 6.7.1, este entorno proporciona unos muy buenos editores para hacer el trabajo con estas tecnologías algo más sencillo. Incluso, al final le dió tiempo a montarse un Single Sign On federado usando OpenSSO.

Si quereis seguir esta charla y aprender más sobre un montón de temas relacionados con el mundo java podeis hacer sus estupendos tutoriales en javapassion.com

Desde hace un tiempo venimos usando FindBugs en el proyecto en el que estoy. Para el que no lo conozca, aunque por el nombre es fácil de adivinar, se trata de una herramienta para la detección automática de posibles bugs en nuestro código.

Antes de nada decir que esta aplicación sirve para analizar código Java y que requiere una versión de la JRE (o JDK) igual o superior a la 1.5.0. No obstante, esta “limitación” es solo para correr la herramienta, ya que es capaz de detectar posibles bugs en código compilado para cualquier versión de Java.

Aunque existe una versión stand-alone de la aplicación nosotros utilizamos un plugin para Eclipse que funciona a partir de la versión 3.3. Este plugin integra las funcionalidades de FindBugs en el entorno de desarrollo, creando menús contextuales para las acciones principales y aportando una página de preferencias donde personalizar el comportamiento de la herramienta.

Lo que hace FindBugs es simple: aplicar una serie de patrones para identificar código susceptible de ser un bug. El número de estos patrones es bastante elevado y de diferente severidad. Aquí la lista completa.

Las principales categorías en qué dividen los bugs y algunos ejemplos son:

- Correctness

Código que tiene pinta de ser erroneo debido a una equivocación del programador.

Ejemplos:

* Hacer un cast imposible, que siempre va a lanzar una ClassCastException
* Aparentes bucles infinitos
* Método que define una variable que se llama igual que un atributo de la clase o superclase
* Una variable que se sabe que es null y se utiliza en un instanceof (siempre va a devolver false)

- Bad Practice

Cuando nos hemos saltado alguna de las buenas prácticas recomendadas.

Ejemplos:

* Comparar Strings utilizando == o != en vez de .equals()
* Comprobaciones en clases que definen alguno de los métodos equals() o hashCode()
* Uso de identificadores que son palabras reservadas en versiones superiores de Java
* Método suscetible de dejar abierto un Stream ante una excepción

- Dodgy

Código confuso, anómalo o escrito de forma un tanto ofuscada.

Ejemplos:
* Un método que utiliza el mismo código para dos ramas distintas de un if. Puede ser un copy/paste mal hecho.
* Código con una referencia “hardcodeada” a una ruta absoluta
* Procurar devolver un array de longitud cero antes que null.
* Implementar un interfaz que ya está siendo implementado por una superclase.
* Algún case de una sentencia switch no acaba con break y ejecutará el código del siguiente case.

Aparte de estos ejemplos mas o menos simples hay otros bastantes mas complejos (sobre todo a la hora de detectarlos en ejecución) como pueden ser:

* Un método sobrescribe a otro que se encuentra en una clase Adapter que implementa un listener de java.awt.event o javax.swing.event. Esta situación haría que el método no se llamase al ocurrir el evento.
* Una clase que extiende Servlet y utiliza atributos de clase. Como sólo se crea una instancia de cada Servlet y luego se usa en múltiples hilos de ejecución, es muy probable que esta situación de algún problema. Se recomienda usar únicamente variables locales a los métodos.

En fin, como ya os decía hay una gran cantidad de posibles errores que es capaz de detectar.

En cualquier momento podemos decirle a FindBugs que no nos avise de determinados bugs que no consideremos realmente importantes, como puede ser alguna de las buenas prácticas que sea demasiado estricta o que no nos afecte directamente ya que no estamos desarrollando código referente a alguno de esos temas.

En cuanto a cómo usarlo, o mas bien cuándo usarlo, depende de cada uno, pero mi recomendación es intentar hacer una pasada siempre que se vaya a subir código a CVS (o al sistema de control de versiones utilizado). Por ejemplo, en nuestro caso tenemos el código repartido en diferentes plugins de eclipse y, cada vez que tocamos código en uno de ellos o creamos uno nuevo, pasamos un análisis a todo el plugin para identificar posibles puntos conflictivos.

Y si aun no os he convencido del todo, un último pensamiento: ¿cuántas horas habéis perdido intentando solucionar un error para al final daros cuenta de que es que “faltaba un punto y coma aquí”?

Aprovecho una mañana de sábado de insomnio para comentaros sobre el proyecto SunSpot. Ayer mientras escuchaba el podcast de enero de Javahispano (descargable aquí) escuché sobre la existencia de este proyecto.

SunSpot es un proyecto experimental de Sun cuyos objetivos quedan descritos en el siguiente párrafo:

Sun está presente en la actualidad en 6 billones (N. del T: billones americanos) de dispositivos en todo el mundo. Más de un billón (N. del T: idem) de dispositivos móviles ejecutan java. En Sun Labs estamos interesados en lo que viene a continuación. Para asegurar que la siguiente generación de dispositivos móviles está basada en tecnología Sun hemos desarrollado Sun Small Programable Object Technology (S.P.O.T). Hemos creado una plataforma experimental para inspirar la creatividad de los desarrolladores a la hora de crear el siguiente juguete, sensor, dispositivo, … quien sabe; empleando para ello tecnología Sun.

Al final un SunSpot es un dispositivo móvil (Procesador 180MHz 32-bit ARM920T con 512K RAM y 4M Flash), wireless (Antena y radio de 2.4 GHz, TI CC2420 compatible con IEEE 802.15.4), alimentado con batería (3.7V Recargable, 750 mAh Ion-Litio), que en su interior tiene una máquina virtual java (JavaMe). Lo que antes solo era posible desarrollar en C++ sobre dispositivos empotrados ahora se puede desarrollar en Java.

El dispositivo SunSpot puede recibir entradas de un conjunto de sensores que lo hacen perfecto como centro de control y coordinación de otros dispositivos. Junto al SunSpot vienen los siguientes:

• 3 acelerómetros (Regulables a 2G o 6G).

• 1 Sensor de temperatura.

• 1 Sensor de Luz.

• 8 Leds tri-color.

• 6 Sensores de entrada analógicos de corriente alterna-continua

• 2 Interruptores instantáneos.

• 5 pins de entrada/salida de propósito general.

• 4 pins de salida de alta tensión.

El kit completo de desarrollo cuesta 630 euros, y contiene:

• 2 Dispositivos SunSpot con los sensores antes indicados.

• 1 Estación base. Que se enchufa al USB del ordenador y sirve como canal de comunicación entre el PC y los Dispositivos SunSpot.

• Herramientas de desarrollo.

• Tutoriales

• Código de ejemplo

• Accesorios adicionales (ver la foto).

Podeís obtener más información en la web del proyecto.

Descubro via Chema Alonso( MVP Seguridad ): Link que el pasado 25 de Diciembre se cumplieron 10 años del paper donde se expone la técnica que más adelante pasaría a llamarse SQL Injection.
Link al paper original

¿ Que no sabes qué es Sql Injection ?. Resumiendo al máximo: es una técnica para atacar una aplicación que maneja sin cuidado la generación de consultas a BD, inyectando sentencias SQL en lugar de los valores esperados.

Según la Wikipedia: Wikipedia

Por poner un ejemplo claro y clásico:

Código de LogIn en la aplicación pide Usuario y Contraseña, accede a la BD y comprueba si existe una fila en la tabla Usuarios con los datos introducidos, si es así el usuario accede a la aplicación.

Si la generación de la consulta se realiza como sigue: ( Quien no lo ha visto en todos los lenguajes de programación posibles?, salvo en LINQ, claro ).

string sql = "SELECT Count(*) FROM Usuarios WHERE NombreUsuario = '" + textBoxNombreUsuario.Text + "' AND Contrasenya = '"+ textBoxContraseñaUsuario.Text + "'";

Bien, si el usuario de la aplicación, espabilado él, introduce por ejemplo, como nombre de usuario: MiUsuario’ OR 1=1 — la consulta resultante sería:

string sql = "SELECT Count(*) FROM Usuarios WHERE NombreUsuario = 'MiUsuario' OR 1=1 -- AND Contrasenya = 'cualquier cosa que ponga'";

Donde “–” en SQL comenta el resto de la línea… por lo que la consulta va a evaluar solamente las filas cuyo usuario sea ‘MiUsuario’ OR 1 sea igual a 1…. que suele serlo

Éste es el ejemplo más simple, recordad que SQL permite realizar operaciones en batches, separando cada consulta por ‘;’, con lo que en casos tan extremos como el anterior se pueden llegar a inyectar acciones DML tan “simples” como pueden ser DROP TABLE o DROP DATABASE: MiUsuario’ OR 1=1; DROP TABLE Usuarios —

Evidentemente para que pudieran realizarse operaciones de DML en la Base de Datos el usuario que ejecuta las consultas tendría que tener esos permisos… y no debería tenerlos, debería lo menos crearse un usuario con los menos permisos posibles para ejecutar las consultas de la aplicación y otro administrador para gestionarla … pero igualmente no se deberían crear las consultas dinámicas que estamos viendo, así que mejor verlo junto

A partir de aquí surgen distintas variaciones de la técnica, basándose en la información que se puede obtener de la página, como por ejemplo:

-Time-Based SqlInjection: Inyectar queries en las que si se cumple la condición que esperas se ejecuta un delay con el que poder distinguir basándonos en el tiempo de respuesta si la condición se ha cumplido o no. El ejemplo básico sería deducir una password a base de ir encontrando cada caracter, sabiendo si es válido porque cuando lo es la ejecución de la página es más lenta debido a la query inyectada. En TechNet hay un artículo, también de Chema, al respecto: link

Además de las neuronas de quien pone a prueba la aplicación, existen Tools que realizan sofisticados ataques basados en diccionarios, comparando resultados de la página, aplicando Time-Based SQL Injection… un ejemplo de herramienta puede ser :sqlpowerinjector

Bueno, me estoy extendiendo demasiado y se me acaba el año

Espero que con este mínimo resumen haya despertado la curiosidad de algunos y elevado el nivel de atención a la seguridad. Recordad que en general estas técnicas son totalmente independientes del lenguaje de programación y de la Base de Datos, cada uno puede tener algún agujero o característica especial, pero las técnicas generales aplican a todos.

El año que viene opinamos sobre qué hacer para evitar estas vulnerabilidades, pero las recetas mágicas no existen y siempre será necesario ser consciente de las técnicas de ataque para intentar evitarlas en lo posible.

Una de las ponencias de hoy ha tratado sobre OSGI. OSGI es un estándar de componentes dinámicos que pretende solucionar algunos de los problemas que presentan las aplicaciones JAVA cuando el número de librerías implicadas en las mismas y de dependencias entre estas es elevado (cuando digo elevado hablo de 50 o más librerías). La ponencia ha sido expuesta por Peter Kriens, artífice de este estándar. He de decir que ha sido de las mejores que he visto ya no solo por la claridad de la exposición, sino porque el pobre hombre se ha presentado incluso estando medio afónico.

Peter nos contó como todo parte del boom de Internet de finales de los 90. Por esas fechas Peter estuvo involucrado en un proyecto cuyo objetivo era hacer llegar a todos los hogares un ordenador que permitiera controlar vía Internet prácticamente todos los electrodomésticos y artilugios que nos rodean cotidianamente. Para ello su equipo creó un pequeño sistema empotrado con java integrado cuya misión era servir de servidor en esta infraestructura. Por aquellas épocas se pensaba que Internet iba a revolucionar el modo de vida de las personas incluso más de lo que lo ha hecho a día de hoy. Este sistema tenía que funcionar con gran diversidad de dispositivos diferentes que los diferentes fabricantes ofrecerían al mercado.

La heterogeneidad de los distintos dispositivos a integrar dio lugar a una serie de problemas:

• Se hacía tedioso y complejo mantener el classpath de las aplicaciones cuando el número de librerías era elevado. Un claro ejemplo es el de mantener un classpath con 500 librerías, las cuales a su vez dependen de librerías cuya única diferencia es la versión (y el nombre es el mismo).
• Dependencias demasiado mayadas. Esto es comprensible cuando las librerías de cada dispositivo son implementadas por distintos fabricantes siguiendo patrones de dependencia completamente heterogéneos. El modelo de paquetes de java no ayuda a esto ya que está concebido para dar una estructura lógica-funcional a las clases, y no para estructurar una aplicación en base a componentes.
• Necesidad de que la carga, descarga, puesta en funcionamiento y parada de los elementos que constituían una aplicación fuera dinámica. El funcionamiento de los ClassLoaders es completamente estático. Esto no era raro teniendo en cuenta que en aquella época Windows 98 era el último grito en sistemas operativos: un sistema operativo que te obligaba a reiniciar hasta cuando movías el ratón.

En base a estas necesidades se conciben los primeros modelos de aplicaciones orientadas a servicios, y en particular el estándar OSGI, cuya primera versión se publica allá por el 2000. $$$

El estándar OSGI plantea un modelo como el de la figura.

Los puntos más importantes a considerar son:

• Se plantea la creación de Bundles. Estos Bundles ofrecen una serie de servicios y engloban todas las librerías jar que estos últimos necesitan.

• Estos Bundles presentan una interfaz, y ocultan el resto de las librerías a ojos de otros Bundles. De esta manera no existe dependencia entre unos Bundles y otros más que a través de las interfaces públicas de los mismos. La determinación de qué librerías y que clases son públicas, y cuales son privadas, se especifica en un archivo de metadatos.

• La seguridad forma parte del modelo desde el comienzo. Toda operación de acceso a los servicios de un Bundle está asegurada por diseño.
• Los servicios son completamente dinámicos. Si un servicio cae el estándar contempla una parada ordenada de los otros servicios que dependen del mismo. También contempla una recuperación ordenada de los mismos. De este modo la caídas de conexión, desconexiones por falta de batería, etc; están contempladas.
• Un Bundle antes de arrancar diagnostica si el entorno en que se encuentra va a permitir su funcionamiento de manera clara, evitando de este modo problemas en tiempo de ejecución. Además diagnostica de manera muy clara los motivos al usuario para que pueda resolverlo.
• La carga de clases es más rápida porque OSGI implementa ClassLoaders especiales que únicamente buscan clases en la interfaz pública de los Bundles.

Si queréis saber más de este tema en la página de OSGI encontrareis más.

En el proyecto actual -una aplicación web JEE / jdk1.5 construida fundamentalmente con portlets, jsf(myfaces, tomahawk) y ejb3 que se despliega sobre JBoss Portal Server- en el que estamos colaborando nos hemos encontrado con un problema, que aunque puede que habitual en algunas ocasiones, nos está afectando en nuestras tareas de desarrollo y despliegue.

Concretamente, el problema es el tiempo que requieren las tareas de compilación, generación del archivo de despliegue (actualmente ocupa 120 megas) y el propio arranque del servidor de aplicaciones. Después de algunas “optimizaciones”, dichas tareas nos pueden llevar de 3 a 5 minutos, así que os podéis imaginar lo frustante que puede ser cuando, después de invertir ese tiempo, tratas de testear los últimos cambios que has realizado y te encuentras con un error tonto como que olvidaste negar la condición pusiste en un if o algo así… y tienes que volver a repetir todo el ciclo…

Tratando de solucionar este problema, probamos el Hotswapping (recarga de “clases” en caliente, es decir, sin necesidad de reinicar el servidor) nativo que ofrece el jdk pero, por desgracia, no conseguimos hacerlo funcionar correctamente (no tengo muy claro donde estaba el problema si en los frameworks o en el servidor de aplicaciones…) así que le dimos otra vuelta más por google y encontramos un JavaRebel:producto de pago :(, con versión de evaluación de 30 días y licencias gratuitas para desarrollos open source, que la verdad funciona bastante bien… En nuestro caso concreto pasamos de tener que construir todo el proyecto y desplegarlo (unos 3-5 minutos) a simplemente compilar las clases modificadas (10-15 segundos).

Básicamente, lo que ofrece JavaRebel es la modificación “casi completa” del bytecode “on the fly”. Aquí podéis ver una comparación con la fucionalidad ofrecida por JavaRebel frente a la ofrecida por los jdk’s actuales.

Bueno, y que hay que hacer para utilizarlo? Pues simplemente hay que descargarse el jar de JavaRebel y luego incluir -javaagent:/path/to/javarebel.jar en el arranque. (El tema de javaagent da al menos para otro post, pero básicamente es un “interceptor” del proceso de carga de clases, que permite monitorizar dicho proceso de carga y modificar el bytecode que se va a ejecutar… Esta funcionalidad es utilizada por algunas herramientas de profiling o frameworks de Programación Orientada a Aspectos)

En la propia página del producto podéis encontrar un flash que describe bastante bien nuestra situación inicial y también hay una demo real de como funciona esto…

Una de las cosas no tan buenas, además del problemita de ser de pago, es que no es posible depurar desde Netbeans (tienen identificado el bug pero de momento no han previsto cuando liberarán esa versión…) En cuanto a otros IDEs funciona correctamente para Eclipse y para IDEA IntelliJ.

JUnit es, a día de hoy, el método más extendido de realizar pruebas unitarias sobre las funciones de nuestro desarrollo. Pero desde luego, no es infalible. Completar con éxito el 100% de las pruebas unitarias solo significa que la aplicación funciona para los supuestos lanzados en las pruebas. Es decir, nuestro código funciona con A+B+C, ¿pero funcionaría para A+C+B?, ¿como podemos saber qué parte del código se prueba con los test que hemos lanzado?

Para poder contestar esta última pregunta podemos usar Cobertura. Un desarrollo opensource con licencia GNU General Public License, Version 2.0.

Cobertura instrumentaliza nuestras clases java. Introduce nuevas instrucciones dentro de las clases compiladas de nuestro proyecto que utiliza para obtener un informe muy completo sobre lo que ha ocurrido en esas pruebas.

Podemos introducir Cobertura en nuestro proyecto empleando las propias tareas de Cobertura para Ant. Dentro del fichero del proyecto Ant (típicamente build.xml) introduciremos la siguiente línea:

taskdef classpath="cobertura.jar" resource="tasks.properties"


Esto será suficiente para comenzar a utilizar los objetivos de Cobertura.

Una vez lanzados los test los resultados se almacenarán en el fichero “cobertura.ser”.
Este fichero lo podremos formatear como un HTML al estilo javadoc o como un XML que nos servirá para procesar y presentar los resultados con nuestra propia herramienta.

Por ejemplo, el resultado de los test para la propia librería de cobertura los podemos ver en la siguiente imagen

De la misma manera que en un javadoc podremos navegar por los diferentes niveles de la librería y comprobar cuantas lineas de código han sido probadas. Además muestra el indice de complejidad de la clase y el porcentaje de ramificaciones del código probadas

Si pinchamos sobre cualquier clase nos mostrará el código asociado con el número de veces que nuestros test han pasado por cada línea de código. Esto es especialmente útil para comprobar de un vistazo si hemos entrado por todas las ramificaciones de nuestros if-then-else o cuantas veces se ha pasado por un determinado bucle.

En la web de Cobertura se pueden descargar las últimas versiones y gran cantidad de documentación (Getting Started, FAQs, samples…)

Una de las cosas más importantes y obvias cuando escribimos un programa es preparar un buen control de errores. Esto que al principio parece algo fácil, sencillo y encapsulable, al final terminamos haciéndolo siempre de una manera diferente, ya que poco a poco se va complicando porque:
- controlamos la excepción y devolvemos un código de error, o si simplemente la propagamos
- qué herramienta/librería utilizamos para generar la información de log
- qué nivel de log vamos a mantener
- cómo vamos a informar del error
- …

Pero siempre hay algo que solemos olvidar, y es que, tan importante como la detección del error, es el registro del contexto en el que se estaba ejecutando el programa cuando falló, es decir, con qué datos estaba operando.
Este conjunto de datos, está claro que es variable en cada caso, con lo que pasárselo a un método genérico que registre el error suele ser algo lioso, a no ser que empleemos un método que acepte un número variable de argumentos no determinado inicialmente. Esta es una característica que antiguamente el C era uno de los pocos lenguajes que la soportaba, pero que es común en los lenguajes modernos (.NET, Java…), así en Java podríamos tener algo por el estilo:


public String generarCadenaParaLog(Object...args)
{
    StringBuilder logString = new StringBuilder();
    for(Object argTemp: args)
    {
        logString.append(argTemp);
    }
    return logString.toString();
}


Para llamarlo por ejemplo del siguiente modo:
...

...

Google acaba de presentar su browser, Google Chrome:

La versión beta ( hay algún servicio de Google que no sea beta? ) se puede descargar de:

link

Como adelanto publicaron el fin de semana pasado un comic que detalla cada una de las nuevas características y es la mejor forma de conocer el navegador y sus características, es bastante técnico y visual al mismo tiempo:

link al comic

En vez de detallar las features como en todos los blogs del universo propongo discutir qué impacto pueden tener algunas features y qué opináis de la “fragmentación de la web”, para abrir el tema:

Una de las características más comentadas es el aislamiento entre los distintos tabs abiertos, cada uno corre en su propio proceso y el browser actúa como “coordinador”. Con ésto se tienen aislados los espacios de memoria de cada tab y un cuelgue en uno no afectará a otro… pero a cambio cada uno de los tabs tendrá su propio tamaño mínimo de stack, el código que use se cargará repetidas veces en cada proceso… y toda comunicación entre tabs y con el “browser coordinador” será mucho más costosa al ser “remota”.

El motor de javascript, V8, lo venden como la próxima maravilla del mundo: corre en una máquina virtual, entiendo que se precompila a un bytecode en vez de interpretarse, contiene heurísticas para detectar paths de ejecución repetidos y optimizarlos… veremos si sufre de problemas de compatibilidad con otros browsers( que posiblemente sean porque éste sea más fiel a un Standard que otros ).

La cantidad de browsers que una aplicación web debe soportar sigue creciendo y creciendo, desde distintas versiones del mismo navegador a los distintos navegadores disponibles. Todos hemos sufrido páginas webs que no funcionan bien en algún browser, incluso hemos visto o participado en webs donde el código cliente tiene 2 ramas, una para IE y otra para FF…

Dónde está aquella supuesta facilidad de despliegue y esa multiplataforma cuando puedes tener 8-12 browsers distintos y donde sabes que en algún momento saldrá otra versión de algún otro que será más o menos standard y tendrás que retocar-actualizar-probar tu aplicación web.

Todo esto lleva a otra discusión, cómo hemos partido de “la web original”, una arquitectura pensada para transmitir cadenas de texto con formato y mostrarlas por pantalla ( algo así como un visor de documentos simples remoto, sin estado ) a una plataforma de de aplicaciones a base de capas y capas y cantidades inmensas de “pequeños hacks” donde cada uno a ido por su lado. Esa es la historia de la web para lo bueno y para lo malo

Y otra batallita distinta va a ser opinar sobre los intereses de Google, claramente es un paso más en intentar llegar a un Sistema Operativo Web, que corra sobre cualquier SO. Está claro que la transición entre la “página web” donde se mostraba texto con un formateo muy básico y la “aplicación web” necesita avanzar muchos aspectos del browser.

Y os lo recomiendo, es un ebook gratuito, muy profesional, donde en 78 paginas muy amenas se tratan por encima muchas de las técnicas de desarrollo modernas:

Agile Development, Domain Driven Design, Persistance, Dependency Injection, Unit Testing, ORM Mappers así como fundamentos de programación como Memoria, Excepciones y el Patrón Proxy componen los temas principales del libro.

El link es http://codebetter.com/files/folders/codebetter_downloads/entry179694.aspx