Tellme: un buscador para tu teléfono vía voz

Vía el blog de Enrique Ortiz me entero de la salida como beta restringida a un reducido grupo de usuarios, de esta aplicación Java ME que implementa un buscador vía voz, con mapas interactivos, que apunta maneras para convertirse la "killer app" para móviles del 2007.

Por ahora parece únicamente funcionar en un reducido número de móviles, y es un servicio gratuíto, pero poco más se conoce de la beta.

Y no, no es un producto de Google :-)

¿ingenieros?

Navegando por Internet he topado con este post, en el que se hacen eco de la iniciativa Ingenieros de Primera. Dicha iniciativa pretende impedir que la Ingeniería Informática, en España pase a considerarse una "graduación".



A propósito de esto, se aborda la problemática de si "lo nuestro" debería considerarse una ingeniería o no, amén de los típicos puntos colaterales a esta cuestión: intrusismo, perspectivas laborales, evolución,...



Es poco largo de leer, con bastantes referencias a otros blogs de gestión de proyectos y tal vez sea un poco "dogmático" en cuanto a planteamientos; tampoco es una noticia específicamente Java (aunque los ejemplos concretos que se dan son del mundillo), pero que da qué pensar (al menos a mi).



¿Semos ingenieros? Por el planteamiento del post parece desprenderse que ser ingeniero no implica necesariamente tener título... ¿qué piensan vd.?



Saludos,

Jose

JGuard 1.0 Librería para seguridad

Se ha liberado la primera versión estable de esta librería open source para implementar seguridad en aplicaciones java (pensada sobre todo para aplicaciones jee pero puede ser usada también en aplicaciones j2se) y que está construida encima de JAAS (Java Authentication and Authorization Service).





Como saben, la mayoría de las veces en una aplicación jee basta con confiar en la implementación del servidor usado para controlar la seguridad que por lo general tienen lo necesario para montar un esquema de seguridad basada en el contenedor a través de roles y permisos. Asimismo, existen librerías de terceros que permiten administraciones más avanzadas de seguridad a nivel de toda una organización como ALES de Bea e incluso hay librerías opensource que permiten una integración más transparente con otras librerías opensource (caso de Acegi que funciona muy bien junto a Spring). Por ello, la pregunta lógica es ¿porqué usar JGuard?





Investigando un poco en el sitio de la herramienta, esta no parece ser más que una capa de abstracción de JAAS. Pero por ello resulta muy conveniente ya que facilita trabajar con un framework estándar de java de forma mucho más sencilla. De igual forma, provee de varios LoginModules que permiten administrar la seguridad basados en archivos XML, en bases de datos, en LDAP y en certificados de seguridad. Si a esto le sumamos que Sun provee módulos de Login JAAS para usar autenticación de Windows NT, Unix y Solaris tenemos una herramienta muy poderosa en cuanto a las formas de autenticación que podemos usar e incluso tiene un módulo que provee funcionalidades Captcha para aplicaciones web, un requerimiento que cada vez es más necesario para detener el spam que ataca a las páginas web públicas.





Otro punto fuerte de JGuard es su integración "out of the box" con tecnologías web muy usadas como Struts y DWR e incluso con Swing para aplicaciones de escritorio. En suma, JGuard promete bastante y creo que es una librería a tener en cuenta para administrar la seguridad de nuestras aplicaciones.





¿Tienen experiencia usando JGuard? ¿Normalmente que usan para administrar la seguridad de sus aplicaciones?

¿Google y Jetty implementarán Comet en GWT?

Hace un tiempo, en mi afán por desarrollar una aplicación de tiempo real con el Google Web Toolkit, me topé con la técnica de Comet, también conocida como Server Push, que trata sobre la manera en que un servidor HTTP puede jugar un rol activo en la comunicación con el cliente, enviandole información sin que este último la haya requerido. También contempla el multiplexado de la respuesta en diferentes canales, reduciendo drásticamente el ancho de banda, y logrando el mejor tiempo de respuesta posible. Cuando se utiliza AJAX en conjunto con Comet, se dice que la técnica se llama AJAX-Comet. Existen varios frameworks que utilizan este concepto, entre los que se pueden citar:



* Dojo Toolkit: la potente librería de JavaScript que fue pionera en Comet.

* Jetty: el servidor web basado en Java, que aplica el concepto de Continuations para implementar Comet.

* Lightstreamer: un framework de pago basado en .NET con interfaces en PHP, JSP y ASP.

* Pushlets: Librería de Servlets que aplican el concepto de streaming.

* Flex Enterprise Services: Comet sobre Flex.



Y como en este sitio lo único que importa es Java :P, vamos a ver a qué se debe la pregunta del título. En el blog de Greg Wilkins, el responsable del proyecto Jetty, hay una entrada bastante reciente que habla acerca de la posibilidad de integrar Comet con GWT. Según Greg, el RemoteServiceServlet, que es el Servlet que ofrece GWT para implementar su RPC, no habilita la utilización de las continuations de Jetty. Sin embargo, gracias a que GWT es ahora Open Source, Greg se las ingenió para implementar una versión modificada del RemoteServiceServlet que habilita el uso de Comet. Según las palabras de Greg, la integración está en tratativas con Google. Esperemos que tenga éxito. No es un dato menor que, hace tan sólo una semana, ICEFaces haya anunciado el soporte de las Jetty Continuations en su librería de tags JSF.



¿Alguien ha trabajado con Comet y alguna de las tecnologías citadas?

Por qué C# no tiene excepciones cheked (más sobre excepciones)

La semana pasada tuvimos una discusión bastante interesante sobre excepciones cheked y uncheked. Al final de ella seguía habiendo personas que no veían ningún problema en las excepciones cheked y que estaban a favor de usarlas en escenarios donde muchos pensamos que no se deberían de emplear.



Me ha parecido que una buena forma de profundizar en este tema y reflexionar sobre él sería analizar en detalle lo que ha hecho el lenguaje de programación que ha nacido como una evolución de Java: C#. Para crear este lenguaje, aunque no se reconozca oficialmente, se tomó todo lo que funcionaba de Java (la gran mayoría de las cosas) y se quitó y mejoró lo que no funcionaba adecuadamente. Exactamente lo mismo que hizo en su día Java con C++.



Este lenguaje de programación no tiene excepciones cheked. En palabras de su principal responsable, Anders Hejlsberg, no las incorporaron en el lenguaje porque no estaba claro que fuesen beneficiosas. Efectivamente, resolvían una serie de problemas. Pero creaban otros problemas y al final no estaba claro si "el mundo es mejor con o sin ellas, simplemente es diferente".



Dos son los principales motivos que llevaron al equipo que diseñó C # a no incorporar estas excepciones en el lenguaje:

• Escalabilidad de las excepciones: Imaginemos que un conjunto de desarrolladores está diseñando un componente complejo. Imaginemos que el código de cada uno de los desarrolladores puede lanzar cinco excepciones (por poner un número cualquiera). Imaginemos que un componente está siendo desarrollado por cinco desarrolladores. Cuando junten su código tienen 25 excepciones. Ahora supongamos que el componente se junta con otros cinco componentes para crear un subsistema. 125 excepciones. Ese subsistema se une a otros cinco subsistemas. 625 excepciones.
  
  
  
  El ejemplo es un poco exagerado. Pero creo que se coge la idea. Además, no es necesario que las excepciones sean excepciones que hayamos definido nosotros. Si se usan en un mismo proyecto Hibernate, Struts, JasperReports... puedes obtener un efecto similar. Acabas con una jerarquía de excepciones monstruosa. Y esto es probable que lleve a los desarrolladores a hacer cosas como "throws Exception" en todos sus métodos para no listar la interminable lista de excepciones. En ese momento todo el propósito de las excepciones cheked ha sido completamente destruido y el mecanismo de gestión deja de tener sentido.





• Versionabilidad de las excepciones: En Java un método no está definido sólo por su tipo de retorno, su nombre y los parámetros que toma. También por las excepciones que lanza. Supongamos que tenemos una determinada interfaz de una librería que puede lanzar las excepciones A y B. En una versión posterior de la librería añadimos nueva funcionalidad y respetamos la definición de todos los métodos de la interfaz, sólo que ahora (por culpa de la nueva funcionalidad) uno de ellos lanza una excepción C.
  
  
  
  Si añades si esa excepción a la interfaz estará rompiendo todo el código cliente existente. Habrás cambiado la interfaz. Si no la añades irás en contra de la filosofía de las excepciones cheked. Observa que, en este caso, podrías añadir cuantas excepciones uncheked quisieses a la interfaz sin romper el código cliente.

Además, Anders Hejlsberg a firma de las excepciones cheked que:

• No te obligan a gestionar la excepción: Sólo te obligan a "asentir" que se puede lanzar: try{...} catch (AlgunaExcepcion){}. Este código "reconoce" que se puede lanzar la excepción AlgunaExcepcion. Pero no la gestiona. ¿Te resulta familiar ese código? ¿Lo has visto alguna vez?





• Son "dictatoriales": Yo conozco mi aplicación. Yo sé lo qué está haciendo. Yo se qué filosofía de gestión de excepciones estamos usando en el proyecto. ¿Por qué el diseñador dictatorial del API que estoy usando me está obligando a capturar excepciones que no me interesan?. Si las excepciones fuesen uncheked yo podría capturarlas o no capturarlas según se adecuase mis necesidades en cada caso.





• En la mayor parte de los escenarios lo importante es protegerse de las excepciones, no gestionarlas: es más, afirma que la relación entre try-finallys y try-catch en un buen código es 10 a 1. Efectivamente, me interesa protegerme de las excepciones para que mi código siga en un estado consistente. Pero la mayor parte de las veces no la voy a gestionar. Ya se gestionarán en algún punto cercano a la interfaz del usuario "más arriba".

Indudablemente, podemos afirmar que Anders Hejlsberg tiene que defender las decisiones de diseño que tomaron para crear C#. Aún así, sus argumentos son bastante respetables. Y hay una cosa que es innegable: para crear C# estudiaron en profundidad lo que funcionaba bien y lo que no funcionaba en Java. Y ya sabemos la decisión que tomaron respecto a este tema.



Por otro lado, como siempre, un buen programador va a escribir buen código con o sin excepciones cheked. El problema con esta característica del lenguaje, como con casi cualquier otra, es el uso que puede acabar haciendo el programador perezoso harto de gestionar tanta excepción: throws Exception o try{...} catch (Excepcion){}.



¿Opiniones al respecto?