Ha sido un fin de semana intenso: muchas charlas, muchos amigos nuevos y muchas conversaciones construidas alrededor de una ronda de cervezas o el minibar de una habitación de hotel.

The Evnt 2011 ha sido un evento pequeño en tamaño pero ENORME en calidad y contenido. En pocos saraos – y ya he estado en unos cuantos- he visto la devoción y cariño que nos han regalado Javier y Kini a todos los ponentes y asistentes.

Si buscas una conferencia con cientos de sesiones en paralelo y 40.000 asistentes, puedes asistir al Oracle OpenWorld de San Francisco. Si quieres asistir a un congreso más técnico y cercano, la Devoxx belga cumplirá todas tus expectativas. Pero, si esperas asistir a un evento más familiar y cercano, donde se aborde el desarrollo informático de una forma integral -incluyendo desde temas de seguridad a modelos de negocio- y, sobre todo, puedas disfrutar de la noche cacereña tomándote una cerveza y conversar con cualquiera de los ponentes, tu elección debe ser The Evnt.

El patio de butacas y el escenario, ponentes y asistentes, se han confundido y mezclado durante todo el fin de semana.

He disfrutado de todo y todos por igual, desde esos cracks del WordPress y el frontend web que son mis nuevos amigos sevillanos de SVQend, hasta la chavalada adolescente -talento puro en bruto- arremolinados alrededor de los Betabeers de Miquel Camps, que me han hecho sentirme un poco abuelo.

The Evnt 2011 ha sido tecnicazos como Xavi Fernandez -VP Técnico de Abiquo- contándonos como la nube está hoy un poco más cerca gracias a su trabajo; o Christian Kvalheim -líder de equipo en Xing- hablando sobre node.js.

The Evnt 2011 ha sido empresarios como Roberto Canales o Agustín Cuenca explicado su savoir-faire y su visión del desarrollo de software como negocio.

Pero, The Evnt ha sido también mucho más: un viaje en tren compartiendo asiento y sueños con Pablo Jimeno y Dani Latorre, la ilusión de los chicos de BeCode al hablar de su proyecto, ver a Gemma Muñoz olvidarse de la analítica web y demostrar que es una madridista irredenta, pelearte por servir el café con la sonrisa de Abel Hernandez -el cerebro pensante de Agencia Visual- o disfrutar viendo a Jeroclo explicarle a un chico al que dobla en edad que Java no es legacy.

Pero, para mi, The Evnt ha sido, sobre todo, la ilusión en los ojos de Joaquín Engelmo Moriche alias Kinisoftware -extremeño de Zafra, orgulloso desarrollador y mi amigo- por hacer las cosas que le gustan y como le gustan sin tener que irse de su tierra.

Casi se me olvida, pero también me dio tiempo a dar una ponencia sobre La Técnica Pomodoro. Intenté devolver todo el cariño que me habían dado y arriesgué. Me propuse que la charla se alejara completamente de lo que la gente espera de una presentación sobre Productividad Personal y que, fundamentalmente, fuera divertida. Tenía miedo. No sabía si la gente se reiría conmigo… o de mi. Si quieres juzgar por ti mismo, aquí tienes el vídeo:

The Evnt 2011 – La Técnica Pomodoro por David Bonilla

CRÉDITOS

• Foto cortesía de Pedro Lozano. Podéis ver más fotos del evento aquí.
• El Lanyrd del evento
• Vídeos de las ponencias en LiveStream

Hay que ser un pedazo de cretino para soltar una rajada de esas proporciones en el blog de la empresa.

No he trabajado nunca con .NET y sospecho que David Barrett -que es como se llama el individuo- tampoco, pero no creo que el hecho de programar en ese lenguaje en particular, o en cualquier otro, te califique como mejor o peor desarrollador. Ningún programador que lleve más de dos días trabajando se atrevería a decir algo así.

La pregunta es: ¿por qué Barrett se pone a filosofar sobre lenguajes de programación? ¿No se supone que es CEO? Se supone que el trabajo principal de un CEO o Presidente consiste en mantener el foco, tener claro hacia donde va la compañía, evitar las distracciones, rodearse del equipo adecuado, motivarlo y conseguir todo lo necesario para alcanzar el objetivo. Ni siquiera tiene que saber programar. Lo inaudito del caso es que Barrett sí sabe programar, y bastante. No sólo tiene un título como Ingeniero Informático por la Universidad de Michigan -lo cual no demuestra en absoluto que sepas programar- sino que en su primer trabajo programó un motor 3D completo (su perfil en LinkedIn).

Entonces, ¿por qué suelta todas estas tonterías ni más ni menos que en el blog de la empresa? ¿Por qué pierde su tiempo y esfuerzo en algo así? Porque, como casi siempre, todo esto tiene truco.

Expensify -y por extensión su CEO, David Barrett- están desesperados por conseguir buenos programadores. Ya que desarrollan en PHP, no creo que los expertos en .NET sean su objetivo, así que… ¿No será todo esto una maniobra para hacer ruido y conseguir publicidad gratuita? ¿Quizás una manera de conseguir llegar a más candidatos, vendiendo una imagen de compañía cool dirigida por un CEO capaz de meterse con el establishment que representa el lenguaje .NET de la todopoderosa Microsoft? A lo mejor solo soy un mal pensado… pero, si eso es lo que quería, lo ha conseguido con creces. Mientras yo redactaba este artículo, su blog ya iba por los 237 comentarios. Y, lo que es mejor, ha conseguido aparecer en prestigiosos medios del sector… como este blog :P

El problema es que, esa táctica solo parece apropiada para atraer a carne fresca recién llegada de la universidad. En el MUNDO REAL, quien más quien menos ha tenido que programar en un lenguaje que no le gustaba, pero que pagaba las habichuelas a fin de mes. Quien más quien menos conoce y respeta a alguien que programa en .NET. Y, quien más quien menos, ha visto a gente haciendo verdaderas ATROCIDADES en lenguajes bien molones como Ruby, Scala u Objective-C.

A mí no me gustaría que mi CEO soltará una barrabasada así en el blog que representa a toda la empresa. Así que, David, te voy a dar un consejo gratis: si quieres buenos programadores, búscalos en algún congreso de desarrollo web o en la reunión del JUG local o amplía el radio de acción más allá del Coupa Café de Palo Alto. Pero, por favor, aunque estés desesperado, no inicies una nueva batalla alrededor de algo tan estúpido. Estoy seguro que más de un veterano de élite se va a pensar muy mucho si quiere trabajar contigo.

Algunas veces, nuestras decisiones de diseño son imponderables derivados de los requisitos. Otras, sin embargo, no son más que pura fanfarria y sobrearquitectura. Quien más, quien menos, todos hemos cometido alguna atrocidad en el diseño y usabilidad de nuestras aplicaciones, pero seguro que todos nos reconocemos en muchas de las situaciones que tratan con humor en THINGS REAL PEOPLE DON’T SAY ABOUT YOUR APP. Absolutamente recomendado.

RT @MarcosBL RT @Rrazo

Cuando, hace unos meses, nos reunimos para hablar de formación, nos dimos cuenta de que teníamos un problema: la mayoría de los cursos que se ofertaban no nos valían. Bien, porque eran demasiado introductorios,  demasiado genéricos, demasiado caros  y, en algunos casos, por  nuestra disponibilidad o la del profesor.

No necesitábamos un curso sobre EJBs, sino sobre testing unitario fuera del contenedor. Tampoco queríamos un interminable curso de 20h sobre Ruby y su sintaxis, sino alguien que nos explicara como aprenderlo viniendo desde el mundo Java. Y, desde luego, no buscábamos la típica experiencia de profesor-discurso, sino algo ameno e interactivo, donde cualquiera pudiera preguntar y aportar al resto de los asistentes.

Así que le propusimos a nuestra empresa intentar hacer algo diferente: invitar a técnicos y profesionales de reconocido prestigio a que vinieran a nuestra casa para hablar sobre distintas materias y tecnologías de una forma mucho más practica y menos estructurada. Y creamos las “Charlas Sixservix” que se inauguran con la charla de Alberto, en la que nos  explicará “Que puede aportar Groovy a un equipo de desarrollo que programa en Java”, como piloto.

¿Cuál va  a ser la estructura de las Charlas Sixservix?

• Se impartirán los viernes, en nuestras instalaciones, a partir de las 16h
• Antes de la charla, alrededor de las 15:30h se ofrecerá un bufé/comida a todos los asistentes
• Tendrán una duración máxima de 2h
• Serán de formato abierto. Con un guión y estructura mínimas
• Se espera que el ponente aporte un enfoque divertido y práctico
• Comenzaremos con un máximo de 15 asistentes con la intención de permitir una autentica conversación entre todos los participantes
• Queremos que en cada charla haya también asistentes que no sean de la empresa, para que todos podamos enriquecernos con otros puntos de vista
• Intentaremos retransmitir por streaming la charla para que todo el que esté interesado
• Al final de la charla, se hará una pequeña retrospectiva

¿Cómo puedo asistir?

Para esta primera charla tenemos disponibles tres invitaciones, así que si quieres asistir, mándame un correo, a través del formulario de contacto de este mismo blog, con todos los datos que creas que puedan ser útiles para localizarte e identificarte (twitter, blog, etc).

A ver que tal sale el experimento. Como fieles seguidores del desarrollo iterativo e incremental, nos basta con que esta primera charla Alberto no se pierda viniendo  hacia aquí… ^_^

]]> http://sixservix.com/blog/david/2011/03/01/alberto-vilches-groovy/feed/ 102 http://sixservix.com/blog/david/2011/02/25/programar-o-no-programar/ http://sixservix.com/blog/david/2011/02/25/programar-o-no-programar/#comments Fri, 25 Feb 2011 05:15:46 +0000 David Bonilla http://sixservix.com/blog/david/?p=5390 Que no os engañen. Los que no desarrollan, es porque no saben. No conozco a ningún jefe, jefazo o jefecillo al que no le guste saber como se hacen las cosas. Nadie espera que un CEO programe entero un algoritmo genético de cálculo de rutas de transporte, pero siempre podría dedicarle un par de horitas a la semana para hacer peer code review. No se me ocurre mejor manera de tomarle el pulso a una empresa de desarrollo.

Que no os engañen. Esto no sólo puede aplicarse a pequeñas startups. Algunas de las compañías más importantes del mundo, ya lo están haciendo. Eso si, para poder programar, tienes que mancharte las manos. Tienes que saber.

Pero, a veces, el destino es caprichoso y te lleva por caminos insospechados. Te encargan que hagas un prototipo en Android y, cuando te quieres dar cuenta, estás RESTificando tu aplicación para conectarte a ella, como Dios manda, desde tu zapatófono con el sistema operativo de Google.

Y, cuando te pones en serio a implementar algo, pasa lo de siempre: que te manchas las manos y nada es tan limpio como parece. Perdí al menos un par de horas intentando descubrir por qué el REST del demonio no funcionaba como se supone que debía hacerlo.

Así que decidí escribir un artículo técnico. De esos que dan prestigio y hacen que no te etiqueten exclusivamente como un businessman. Sí, de esos artículos que no lee ni mi mujer. Eso sí, ya que no lo iba a leer nadie, lo he escrito a mi manera, nada de ladrillos incendiarios como los que se gasta el maligno y vehemente Dr. Arranz.

Si quieres saber qué es eso del HTTP Access Control y por qué debes tenerlo en cuenta cuando desarrolles en REST, sigue leyendo.

Banda Sonora del artículo: Cage the Elephant – In One Ear

EL CONTEXTO

Con una aplicación legacy -y una aplicación en Struts 1 lo es-, lo más lógico es recurrir a un framework que te ayude a implementar REST sin tener que entrar como un elefante en una cacharrería ni reinventar la rueda. Según Google, tenía dos opciones básicas: Jersey, la implementación de referencia de Oracle/SUN y Restlet, el voluntarioso esfuerzo que da de comer a Noelios Technologies.

La introducción de la API 2.4.1 de RESTLET es muy LOL :D

Jersey debe ser una maravilla, pero ha debido de ser el último framework en sufrir el rebranding de Oracle y no me funcionaba ni un solo enlace a la documentación. Así que la elección estaba clara.

Lo malo de Restlet es que, el cambio de la versión 1 a la 2 ha sido más traumático que encontrarte a tu abuela desnuda en la ducha, así que todos los ejemplos que encontraba sobre cómo utilizar Restlet valían lo mismo que un billete de 7 euros.

Algunos cambios eran sencillitos, como el rename de Resource a ServerResource, pero otros -el constructor de ServerResource ya no recibe como parámetros un Request y un Response sino que la factoría de creación los inyecta después de instanciar el objeto- te obligaban a hacer lo que hacen los hombres de verdad: remangarse la camisa y tirar de API.

Implementé el mejor ejemplo que encontré, adaptándolo para que funcionara con Restlet 2, incrustado en mi aplicación legacy, y creé un HTML+JavaScript (del bueno) independiente, con un formulario básico que me permitiera indicar la URL, parámetros y método HTTP que quisiera probar. Un figura, ese soy yo.

EL MURO DE CEMENTO

Empiezo a probar mi implementación a través de mi cliente  y la cosa parece que funciona: consigo controlar el flujo de la aplicación -hasta un catch-all-, recoger parámetros y devolver mi Response… pero, cuando llega a mi cliente, un flamante Firefox 3.6.2,  el HTTP Status, ese que te indica que todo ha ido como la seda o que has metido la pata, es un cero patatero. ¿¿¿ Cero ??? WTF ???

Bueno… el HTTP Status es básico para validar las cosas van bien, pero podría llegar a prescindir de él. Ya validaré los datos del Response, a lo Pancho Villa, en cliente, pero es que… ¡tampoco llegan los datos! Ostras, esto ya es más grave.

Se me enciende la bombilla y pienso “claro, eso es porque no indicas el status antes de devolver la Response desde tu aplicación de servidor” y me pongo a hacer idioteces como esta en Restlet:

setStatus(Status.SUCCESS_OK);

¡Pero tampoco funciona! ¡Maldita sea! Y, lo peor de todo, es que, cuando llamaba a los servicios directamente por invocación desde la barra del navegador en vez desde mi HTML+JavaScript (del bueno) independiente, todo funcionaba bien… ¬¬

EL PROBLEMA

Después de comprobar unas 20 veces que tenía todo BIEN y, aún así, todo funcionaba MAL, me dio por googlear ‘HTTP Status ==  0′ y la explicación que encontré era tan simple que no podía creerlo. Lo más increíble de todo era el párrafo que decía “... y no te funcionará en otro navegador que no sea Explorer“. Así que,  me esforcé por recordar cómo podía abrir el Internet Explorer, ejecuté mi cliente HTML+JavaScript (del bueno) con él y… voilà! El navegador no solo recibía un Status 200 aka “todo ha ido fino Pochettino” sino que me pintaba, con mi AJAX de todo a 100, los datos de respuesta del servidor.

Al final, todo era una cuestión de seguridad… y de cross-site scripting.

Si os leéis este textazo técnico de Mozilla, aprenderéis que, por defecto, Firefox implementa una restricción de seguridad que impide el cross-site request o, lo que es lo mismo, que un recurso de un dominio A haga una petición de un recurso del dominio B.

En mi caso, mi cliente HTML estaba alojado en mi disco duro, mientras que el recurso que solicitaba por REST era servido por  un TOMCAT en local … pero  evidentemente en dominio diferente para el navegador.

La solución consiste en incluir una cabecera especifica en la HTTP Response que se envía de vuelta al navegador: Access-Control-Allow-Origin

Mediante esta cabecera, desde el servidor podemos avisar al navegador de qué dominios están autorizados para solicitar recursos de nuestro sitio. Si queremos permitir el acceso a nuestra API REST desde cualquier dominio, como en mi caso, tendremos que darle el valor “*” a dicha cabecera.

LA SOLUCIÓN

Soy un looser y no sé cómo incrustar un snippet de GitHub en el WordPress. No me funciona ni un plugin !!! O_o

El problema es que con Restlet no manejamos directamente las cabeceras HTTP, sino que estas se manejan encapsuladas en wrappers propios de la aplicación.

Para poder escribir esta cabecera, debemos recuperar este wrapper en forma de objeto Form y añadir la cabecera directamente.

Para evitar hacer esto en cada método (GET, POST, PUT…) de nuestro ServerResource, he sobrescrito el método do Init() que se ejecuta cada vez que se instancia el objeto.

Es evidente que podríamos hacer una refactorización inmediata y hacer que nuestros ServerResources (realmente, los recursos REST que exponemos gracias a Restlet) no extiendan directamente de esa clase abstracta sino de una implementación propia que sobrescriba el doInit() para todos.

Como soy un auténtico perdedor, no he conseguido copiar el fragmento de código que había colgado en GitHub, pero aquí os dejo el enlace.

Queda mucho por hablar de cómo juguetear, de verdad, con REST (autenticación, el preflighted o verificación previa, etc), pero por hoy es suficiente. Ya os habéis tragado un articulazo de casi 1200 palabras.

DISCLAIMER: La verdad es que no hace falta nada de esto para trabajar con mi aplicación de Android. En Android, pondría un cliente de Restlet y se comunicaría con mi aplicación por conexión directa, nada de navegador.

También es importante que sepáis que mucha gente no utiliza el Access-Control-Allow-Origin con valor *, sino que gestionan una lista blanca de dominios autorizados. ¿A alguien le suena el registro de dominio para utilizar las APIs de Google?

Artículos relacionados:

1. Explicando REST a mi madre Si mamá, desde hace ya un buen tiempo, cuando vienes...

Lo cierto es que es posible que des con la clave para crear el nuevo Facebook. Igual que es posible que te toque la lotería… pero las posibilidades son muy bajas. Para los que realmente quieran hacer cosas, para los que quieran evitar la analysis paralysis, hay otra posibilidad: copiar. Copiar miserablemente y sin recato alguno.

Es sorprendente el número de desarrolladores voluntariosos de los que he hablado antes que JAMÁS dedican más de un par de minutos a leer una reseña o algún artículo sobre startups o nuevas aplicaciones, aunque pretendan crear o trabajar en una.

POR QUÉ COPIAR

Intentar crear un producto informático o sitio web sin haber estudiado mínimamente lo que han hecho otros, cómo y porqué, es lo mismo que esperar que un niño componga sólo conciertos y óperas por haber escuchado ‘Las cuatro estaciones’ de Vivaldi desde la cuna. Demasiado optimista.

Y estudiar una aplicación tiene mucho más que ver con el problema que soluciona y cómo lo soluciona, que con el lenguaje de programación o el framework con el que se implementa la solución. Por mucho que a algunos desarrolladores nos duela porque nos haga plantearnos la mera posibilidad de no ser el ombligo del Universo. ¿Cuántos seríais capaces de enumerar la totalidad de las características de algo tan aparentemente sencillo como vuestro propio blog? ¿RSS, búsquedas, alertas por respuestas a comentarios…? Probablemente, muy pocos. Pero, lo más importante, es que casi ninguno podría hacer una comparación de características con su competencia directa, por ejemplo, MI blog ¿Cómo pensar siquiera en crear un sistema de blogs? Tendríamos el mismo resultado que alguien que construya una casa sin saber que hacen falta cimientos. Da igual que utilices cemento de la marca Ruby o Java, la casa se caerá.

CÓMO COPIAR

Una vez que interiorizamos que debemos observar y estudiar otras aplicaciones si queremos diseñar las nuestras ¿Por dónde empezamos? Hay miles de sitios web sobre startups y aplicaciones, pero podéis empezar por un listado sencillo como este, con 50 logos de startups creados en 2010 que me envió Jeroclo, “el espartano”. Navegad por los logos, elegid uno que os llame la atención, haced click en el mismo e intentar averiguar qué hace la aplicación, porqué lo hace y cómo lo hace.

Interrogaros a vosotros mismos como usuarios. ¿Satisface vuestra necesidad? ¿Echáis en falta alguna funcionalidad? ¿Creéis que podríais resolver mejor el problema? Si respondéis afirmativamente a alguna de las tres preguntas, ya tenéis la idea, vuestra idea, para desarrollar un producto o aplicación. No hay que sobrevalorar la importancia de ser el primero y debemos olvidar la esperanza de ser los únicos que hagamos algo. Siempre ha habido alguien que ha sido al menos tan listo como tú. Lo importante es ser diferente, pensar en algo que te diferencie de la competencia… y conseguir implementarlo, por supuesto. Facebook no fue la primera red social. Fue la primera que era exclusiva y restringida a universidades americanas de élite. El resto fueron giros en su modelo de negocio.

DE LA COPIA A LA CREACIÓN

Todos conocemos alguna aplicación o servicio que nos gusta, pero que sería perfecto si tuviera tal o cual característica o hiciera las cosas de una determinada manera. Bien ¿Y por qué no lo implementamos? Probablemente no será tan original como crear el nuevo Facebook, pero será mejor que programar la enésima aplicación para enviar un mensaje de agradecimiento a tus nuevos seguidores en Twitter.

La copia e imitación es parte del proceso de aprendizaje humano. Los niños aprenden observando y copiando las actividades de los adultos. Integremos este proceso natural en nuestra carrera como diseñadores y desarrolladores de aplicaciones. De la misma manera que un niño descubre por sí solo con emoción que puede correr después de haber aprendido a andar, quizás, algún día, seamos capaces de diseñar una aplicación original desde cero. Mientras tanto, copiad. Copiad sin vergüenza alguna y, si sois capaces, conseguid que vuestras copias superen a los originales.

DISCLAIMER: redacté este artículo mientras preparaba mi charla para la speakerconf “15 en 5′” que se celebró el 7 de enero en Madrid. Lo creáis o no, conseguí meter todo esto -bueno, al menos, el concepto- en 15 diapositivas y 5 minutos.

]]> http://sixservix.com/blog/david/2011/01/11/copia/feed/ 167 http://sixservix.com/blog/david/2011/01/03/web-designer-vs-web-developer/ http://sixservix.com/blog/david/2011/01/03/web-designer-vs-web-developer/#comments Mon, 03 Jan 2011 06:45:31 +0000 David Bonilla http://sixservix.com/blog/david/?p=5080 Para comenzar el año con energía y fuerza, una de esas infografías que a mi tanto me gustan: diferencias entre un desarrollador web y un diseñador web. Por si a alguien no le había quedado claro :)

RT @WIX

El pasado domingo 5 de diciembre se celebró en Zaragoza la I BoConf. La idea era aprovechar mi viaje a Zaragoza para reunirme con Dani, conocer a la interesantísima scene de desarrolladores que hay en Aragón y que yo he bautizado como Cachirulo Valley. Lo que nació como una broma, acabó reuniendo a “más de veinte personas”, según los cálculos científicos de Dani Latorre.

Lo cierto es que el éxito de la convocatoria nos desbordó y tuvimos que improvisar un plan de contingencia que hizo que Dani nos arrastrara por los oscuros garitos que suele frecuentar. Para que la gente sea consciente de la altura del personaje, en el Ángel Azul, las cervezas pasaron de valer 2,50€ a 1,90€ en cuanto me identificaron como “amigo del caballero” :)

Me fue imposible hablar con todo el mundo, a pesar de que lo intenté hasta las cuatro de la mañana, cuando me retiré a descansar después de ocho horas de BoConf. Aún así, pude constatar que el Cachirulo Valley es una realidad y que tiene una salud espléndida. Una vez más, confirmé una de las máximas del pintxo management, el movimiento de gestión empresarial del que soy -al mismo tiempo- autor, máximo exponente y único seguidor: muchas veces, se aprende más tomando unas cervezas con un puñado de colegas que asistiendo a una conferencia de un gurú del sector.

Primero estuve hablando con los chicos de Kraken Empire, un par de cracks que dejaron su trabajo en Madrid como desarrolladores de videojuegos para volver a Aragón y comenzar a crear su primer juego propio, Kromaia, que tiene una pinta estupenda. Charlamos sobre cómo arrancar una empresa desde cero y, sobre todo, les estuve interrogando sobre los conocimientos necesarios para programar con un uso exhaustivo de las 3D, algo muy alejado del mundo Java del que provengo.

Al poco de haber empezado y haciéndose esperar, como su estatus de estrella mediática requiere, apareció Jorge Rubira que anda celebrando el programa número 100 de su podcast en javaHispano. Un tío grande, aunque no apareció con la camiseta que me hizo traerle de la javaOne…

Escuchando los planes secretos para conquistar el mundo de Gimenete

También estuve charlando con Vanessa y Plunchete durante un rato largo acerca de Masterbranch y la evolución del proyecto. Me contaron muuuchas cosas interesantes que por prudencia no voy a contar, pero sí os puedo adelantar que van a hacer mucho ruido a partir de ahora.

Durante la cena, Gimenete (sí… Plunchete, Gimenete, Dani Latorrete… en Zaragoza, si no tienes un apodo acabado en ‘ete’, estás out) me estuvo contando en que andaba metido últimamente. Después de hablar 10 minutos con él, me di cuenta de que, aunque es un pésimo ciclista, también es uno de los tíos más inquietos y con ganas de hacer cosas con los que he tenido el placer de hablar últimamente. Hasta me enseñó alguno de sus juguetes, como Vitamin Pills.

En un bar donde los copazos sólo valían cinco euros -ocasión que ningún madrileño desaprovecha para soltar nuestra frase favorita: “¡Qué baaaaraaatooo!”- Lucas aka Calvo con Barba y yo estuvimos hablando de nuestras ideas y futuros proyectos. Lucas, no sólo comparte estilista conmigo, sino que es un gran tipo. No es informático, sino que se dedica a vender humo. Eso sí, humo del bueno. Además, es el tipo que está detrás de Spain on Twins, así que, si tienes una Harley, deberías conocerlo.

En el (pen)último antro al que nos arrastró Dani, estuve filosofando de nuevo con él. Los dos coincidíamos en que había gente con muchísimo más talento que nosotros haciendo muchas menos cosas. Y creo que esa frase, ese pensamiento, resumen el espíritu de la BoConf: una reunión de gente con ganas de hacer cosas y en donde se trata a todo el mundo de igual a igual, seas un empresario de éxito (con “participación minúscula”, pero empresario) como Dani Baeyens de Warp, o una programadora COBOL de cartón-piedra como Candela, mi mujer. Una reunión donde no se expone, sólo se conversa.

Me dejo a muchos, como el amigo Pablo Jimeno, Jose B. Cortes @uncurioso o el crack de Jose Felix Lucía (el hombre con tres nombres), pero prefiero dejarme cosas en el tintero para la próxima vez. Porque estoy deseando volver a Zaragoza y reencontrarme con mis viejos y nuevos amigos. Gente maja, gente maña. La savia del Cachirulo Valley.

Artículos relacionados:

1. BoConf Zaragoza 2010 Si ya tengo mi propia televisión ¿Por qué no tener...

Durante la AOS2010, empecé a bromear con uno de esos amigos, el desarrollador y bon vivant Dani Latorre, sobre la posibilidad de aprovechar mi visita a Zaragoza en el puente de la Constitución para montar nuestra propia micro-conferencia sobre tecnología, desarrollo de aplicaciones… y pintxos, la BoConf (DISCLAIMER: vale, el nombre no es muy original, pero es lo único que se nos ocurrió a las 4 de la mañana. Buscamos sugerencias), donde intentar conocer a todos los miembros posibles de lo que yo denomino Cachirulo Valley, la vibrante escena de desarrollo que hay en Aragón en general y en Zaragoza en particular.

Hay un MONTÓN de empresas haciendo cosas interesantes en la capital del Ebro y alrededores, como Frogtek, SevenClick, Masterbranch o Pragmatic; y aún más personalidades relevantes como Alberto Gimeno, Jorge Rubira, Teresa Oliver, Calvo con Barba, el propio Dani Latorre y muchos más.

Dani y yo conocíamos todos los obstáculos para tener un mínimo poder de convocatoria: pretendíamos reunirnos un domingo, con frío, en mitad de un puente y con la misma planificación ganadora que la del estratega de Ferrari, pero siendo maño y cabezón el, y madrileño de pro yo, nadie dio su brazo a torcer, aunque comenzamos a olvidarnos de lanzar cualquier tipo de convocatoria pública. Hasta que el amigo Pablo Jimeno hizo un all-in y nos pasó por la izquierda lanzando ESTO.

Así que, me veo empujado a convocar, con orgullo y satisfacción, la primera BoConf, el domingo 5 de diciembre de 2010 en Zaragoza, Aragón. Nos reuniremos a las 20h en El Ángel Azul, el punto de reunión que el maestro de ceremonias Latorre ha considerado más adecuado para acoger a los centenares de asistentes.

Si quieres asistir a la única micro-conferencia celebrada en España y primer Testosterone Driven Event del mundo, no te puedes perder la Boconf Zaragoza 2010. Hablaremos de la teoría del superhombre de Nietzsche, la alegoría de la caverna de Platón y, si hay tiempo, de los avatares del día a día de todos los que intentamos ganarnos la vida con el desarrollo de software. Estructurada con el modelo Agile Beer Space, cada uno podrá unirse a las conversaciones que quiera con una única norma: tener un vaso de cerveza en la mano.

Por supuesto, los acompañantes y acompañantas serán bienvenidos. De hecho, la famosa programadora Cobol Candela Milán impartirá su magistral ponencia “Como hacer creer a un informático que escuchas con atención las tonterías de las que habla mientras repasas mentalmente la lista de la compra”.

Más de uno pensará que esto es una tontunez. Para nosotros, no es más que hacer Comunidad de la mejor manera posible: con eventos que surgen espontáneamente de la misma. Otros pensareis que hay que ser muy valiente para convocar públicamente a la gente y arriesgarte a que no asista NADIE. No es valentía, es pura inconsciencia :) De todas formas, la última vez que hicimos algo similar, no salió nada mal. Es probable que no seamos muchos, pero haremos MUCHO RUIDO.

Si vas a asistir y quieres que orgulloso el Mundo lo sepa, deja un comentario en este blog y te añadiremos a la lista de asistentes confirmados ¡Arriba el Cachirulo Valley!

ASISTENTES CONFIRMADOS

• La buena gente de Kraken Empire
• Jose B. Cortés
• Jose Manuel Cristobal
• Guillermo Latorre
• Jesús García Gil
• Jorge Rubira
• Ignacio Andreu aka Plunchete
• Jose Felix Lucía
• Pablo Jimeno
• Oriol Coll
• Candela “Miss Cobol” Milán
• Dani Latorre
• David Bonilla

Y ¡bola extra! La página pública del evento en facebook, para el que quiera socializar y tal. Otra fantástica idea de Dani y donde, de momento, no se ha registrado ni él :)

Artículos relacionados:

1. Crónica de la BoConf Zaragoza 2010 En Zaragoza hay muchas más cosas que el Cierzo y...

Hasta ahora, nada revolucionario. La mayoría de las características de la GAE sobre las que se habla en el artículo están ampliamente documentadas y, aunque seas aficionado -como yo- al Macho Programming y no leas ni una vez los manuales, son evidentes a los cinco minutos de intentar trabajar con la misma.

Lo revolucionario del artículo es que, en él, Carlos reconoce, bien clarito aunque en inglés, que SE HA EQUIVOCADO.

Independientemente de estar de acuerdo o no con lo que cuenta y con el estilo que utiliza, yo reconozco que HE APRENDIDO con el artículo de Carlos y quiero darle las gracias por ello. ¡Ojalá hubiera más artículos como el suyo! Pero no los hay. Al menos no aquí, en España.

En España no tenemos cultura del fracaso. Cuando alguien fracasa en algo queda estigmatizado, es un perdedor, un inútil que no sirve para nada. Por aquí habrá muchos que piensen que Carlos es un looser por no haber evaluado mejor donde se metía. En cambio, en otros sitios, tendrán una lectura muy diferente de la situación. Pensarán que al menos ha aprendido mucho sobre la GAE, a tener muy en cuenta las condiciones y términos de servicio y, sobre todo, que LO HA INTENTADO, y eso es mucho más de lo que suele hacer el 99,99% de la gente.

En la última javaOne asistí a una charla del CTO de Mint donde explicaba cómo, al principio de comenzar el desarrollo de la aplicación, aparecieron graves problemas de rendimiento en su base de datos MySQL que no sabían resolver porque “no había ningún DBA en el equipo“. Así que, aunque tenían poco dinero, decidieron contratar a un consultor para que les ayudara con el problema. Según él “la primera mejora fue casi instantánea, porque descubrió que habíamos instalado la BBDD con las opciones por defecto y que estaba corriendo en nuestro megaservidor de miles de dolares… utilizando sólo 256MB de memoria“. Mint salió de aquel bache, fue comprada por Intuit por 170 millones de dólares y es casi seguro que el cenutrio que instaló la base de datos con 256MB sea hoy un feliz millonario ¿Recordáis haber visto a alguien contar en público alguna historia parecida en nuestro país? Yo no.

Realmente, aquí tampoco tenemos cultura del éxito, porque cuando alguien consigue un mínimo triunfo siempre hay alguien que dictamina “que tuvo suerte o un enchufe o ambos“.

La verdad es que yo estoy aprendiendo bastante más de la aventura empresarial de Carlos que de las de otros supuestos emprendedores de éxito. Si hiciéramos caso sólo a lo que se lee en la blogosfera y se publica en los medios, España estaría llena de startups punteras… para que luego resulte que el bombazo del año sea la compra de Tuenti por el mismo dinero que en Estados Unidos dedican a financiar una web especializada en la venta de botones con anclas.

Eso si… creo que hay algo, en mi humilde opinión, en lo que sí se ha “equivocado” Carlos y es… en la audiencia a la que ha dirigido su mensaje. Se nota que ES un técnico y todo este embrollo  -por mucho que diga que sólo escribe para él y sus amigos- no ha dado otra impresión que la de ver a un técnico, un buen técnico, explicando sus decisiones de arquitectura y repitiendo unas 400 veces “nuestro código es de lo bueno lo mejor y de lo mejor lo superior ¡Fue la plataforma no fui yo!” para justificarse delante de la Comunidad de desarrolladores. Pero Carlos no tiene que justificar un carajote a la Comunidad. Ante los que tiene que justificarse son sus clientes, usuarios y posibles inversores, a los que lo de la latencia de la Google App Engine o del condensador de fluzo no solo les suena a chino sino que además, no les interesa lo más mínimo.

Yo hubiera escrito antes en el blog de la compañía pidiendo perdón a los usuarios por los problemas de funcionamiento y explicándoles porque ya no iban a repetirse más, como ya hizo en twitter. O explicando las estrategias y acciones que están adoptando para ganar cuota de mercado. Porque Carlos tiene inversores -algunos son amigos míos- y no puedo dejar de pensar que, al menos parte de los 15.000€ que dice que ha perdido, no son suyos.

Pero claro, es fácil decir esto “desde la barrera y a toro pasado”, lo difícil es acertar a la primera cuando estás creando algo de la nada. Hasta que yo lo consiga, espero seguir aprendiendo mucho gracias a Carlos y a gente como él Ánimo.

En estos 5 minutos, hemos intentado condensar la filosofía que nos guía en nuestro día a día: disfrutar de nuestros amigos, de nuestra pasión y nuestro modo de vida. Nos gusta lo que hacemos e intentamos hacerlo cada día un poco mejor. Eso sí, sin olvidarnos nunca de que uno no debe tomarse muy en serio a si mismo :)

Pinche aquí para ver el vídeo

Creemos que no hay que ser aburridos para ser serios y que merece la pena arriesgarse a hacer algo nuevo, en vez de repetir una y otra vez las mismas fórmulas.

Sabemos que, cuando empezamos esta aventura, más de uno sonrió pensando que hacíamos el ridículo. Dos semanas después, podemos daros con orgullo algunas cifras:

• 1.200 páginas vistas diarias de media en el blog (una cuarta parte del tráfico total de, por ejemplo, javaHispano)
• 185 comentarios generados
• Más de 3.400 visionados completos en YouTube
• 100º canal de YouTube con más subscriptores en el mes (58) a nivel global
• 7º canal de YouTube con más subscriptores en el mes de la categoría “Gurús“
• Más de 50 followers nuevos en Twitter entre la cuenta de Jeroclo y la mía
• Apoyo MASIVO de la Comunidad…

Gracias por estar ahí y dar vuestro apoyo a esta nueva iniciativa. No sabemos si BonillaTV seguirá existiendo en el futuro, pero ha sido un placer y un privilegio compartir esta aventura con vosotros.

Artículos relacionados:

1. BonillaTV – Capítulo 6: El cuarto poder Una zona oculta del Moscone Center para la mayoría de...
2. BonillaTV – Capítulo 5: Pasándonoslo PIRATA Segundo día de javaOne y ya estamos totalmente integrados en...
3. BonillaTV – Capítulo 4: ¡Esto empieza! Primer día de javaOne, primer día de conferencias. Y queremos...

Y, sin embargo, lo es. El modo en el que Glassfish trabaja con logs es peculiar y guarda algún oscuro secreto.  Sólo te pido dos cosas:

1. 1. Cinco minutos de tu tiempo para que juzgues si lo he conseguido.
   2. Que, para vivir una experiencia completa, escuches la canción ‘Old Souls‘ de la banda sonora de Origen mientras lees el artículo.

Lo peor que te puede pasar es que salgas de aquí aprendiendo algo nuevo y, por supuesto, siempre puedes tirarme tomates virtuales en los comentarios del artículo.  ¿Te animas?

EL MISTERIO DE LAS TRAZAS INEXPLICABLES

Como parte de mi asedio y conquista al entorno de trabajo de STORETTO, comencé a estudiar nuestro sistema de traza y la configuración del mismo. Parecía algo relativamente sencillo (una configuración típica de log4j) Sin embargo, algo no encajaba. Ni las trazas aparecían por donde debían ni tenían el formato que queríamos. Nada se parecía ni remotamente a lo que teníamos configurado.

Tampoco entendía por qué el equipo de STORETTO había configurado el sistema de log4j habitual de la compañía mediante una variable de sistema, en vez de colocar el fichero de configuración en el classpath de la aplicación.

¿Qué estaba pasando? ¿Era todo esto real o era un sueño? ¿Estaba soñando dentro de un sueño? ¿Cómo distinguir la realidad del sueño?

Como en el anterior caso de las JSPX desestructuradas, yo tenía un poco más de tiempo disponible que el equipo para comprender qué estábamos haciendo y por qué lo estábamos haciendo. Lo que averigüé fue SORPRENDENTE.

FRAMEWORK DE LOGGING DE GLASSFISH

Antes de nada, era importante conocer qué sistema de registro de trazas utiliza Glassfish y cómo funciona el mismo.

He resumido todo lo que se necesita saber en un par de párrafos:

Glassfish utiliza para su sistema de trazas la implementación por defecto de la especificación JSR-047, una API de logging, y recomienda el uso de la misma, aunque permite el uso de otras como Apache Commons Logging o log4j.

El uso de la API de logging del JDK implica varias cosas a tener en cuenta:

1. Se basa en un sistema de Handlers, clases que heredan de java.util.logging.Handler y que son los que encapsulan tanto la lógica de publicación de trazas como la configuración de las mismas.
2. Estableciendo un level o nivel por Handler podemos establecer el nivel mínimo de traza que queremos que recoja el HANDLER. Estableciendo un nivel determinado se recogerán todas las trazas de ese nivel y de los niveles superiores jerárquicamente (para conocer más sobre los nieles de traza, pinchar aquí). También se puede establecer el nivel mínimo de traza por paquete de clases, independientemente del nivel implementado por paquete (se usará la configuración más restrictiva)
3. Además del nivel, se puede establecer un control secundario y opcional sobre lo que se registra o no, mediante la asignación de un filtro o Filter (clase que hereda de java.util.logging.Filter) a un Handler. Un Filter, básicamente, implementa un método isLoggeable que devuelve un booleano que indica si un log se debe trazar o no.
4. Si se quiere formatear las trazas generadas con alguna estructura especifica, se debe implementar un Formatter (clase que herede java.util.logging.Formatter) y asignarlo al Handler deseado.
5. Toda esta configuración se hace a través de un fichero denominado logging.properties

La primera diferencia que chocará a todos los que venimos de usar log4j es que todo se configura programándolo. Es decir, no tienes una manera de poder configurar de forma flexible el formato de tus trazas. Si quieres un Formatter que saque el patrón de tu traza de un fichero de propiedades, vas a tener que programártelo.

TRABAJANDO CON LOG4J

¿Son mis logs reales o sólo un sueño?

Para trabajar con log4j en Glassfish v2 se recomendaba configurar la librería de traza como librería del sistema para evitar problemas con el classloading pero esto ya no puede hacerse con Glassfish v3 así que la solución pasa por indicar al servidor la ruta del fichero de configuración de log4j.

En log4j se configuran Appender (el equivalente de los Handler en JSR-047) El Appender típico que todo el mundo utiliza al desarrollar es el org.apache.log4j.ConsoleAppender, que publica los logs en la salida por defecto de System.out.

El problema es que las trazas no salen por la consola habitual que esperamos todos los programadores sino en un fichero server.log que se encuentra en la ruta /midominio/logs/.

Eso es bastante fácil de explicar porque  ese fichero es la salida por defecto del servidor, así que, ésa es su consola.

Lo que no tiene ni pies ni cabeza es que nuestras trazas salgan con el formato de las trazas de la API de logging de JDK o, más exactamente, envueltas por su formato, puesto que nuestro traza aparece… pero sólo como parte del mensaje de la traza de logging del JDK.

Bueno… podemos pensar que, de alguna manera, el sistema está ignorando nuestra configuración de log4j. Sin embargo, si configuramos cualquier otro Appender, por ejemplo uno que publique en un fichero inception.log, log4j funciona PERFECTAMENTE.

¿Entonces? ¿Qué está pasando? ¿Por qué salen todas mis trazas rodeadas de almohadillas ‘#’  y con un retorno de carro cuando las publico por consola?

LA SOLUCIÓN AL MISTERIO

No, no estamos soñando. Nuestras trazas son reales y nuestra configuración también. No estamos haciendo nada mal. Simplemente, alguien ha estado jugando con nosotros. Alguien ha estado haciendo trampas.

Glassfish, utiliza una implementación propia y sobrescrita del objeto System cuyo método out devuelve un PrintWriter que redirige todas las salidas al sistema de logging del servidor. Probadlo, hacer un System.out.println en una clase desplegada en Glassfish. No sólo aparecerá en la salida por defecto -server.log- sino que, además, aparecerá con el formato específico del sistema de logging.

Lo más grave de todo esto es que System es una clase final. Es decir, que no puede ser extendida, precisamente para evitar lo que Glassfish ha conseguido: que nuestro código tenga un comportamiento extraño y nos desconcierte. Que nos tengamos que frotar los ojos para comprobar que no estamos soñando.

De acuerdo, Glassfish nos ha engañado pero ahora, después de leer este artículo sabemos cómo vencerlo:

• ¿Queremos modificar el formato de las trazas del servidor? Implementaremos nuestro propio Formatter y se lo asignaremos al ConsoleHandler del fichero logging.properties
• ¿Queremos que nuestras propias trazas no se mezclen con las del servidor? Nos olvidaremos de utilizar el ConsoleAppender
• ¿Queremos que sólo nuestras trazas de error salgan en la salida por defecto del servidor? Podremos utilizar un ConsoleAppender y configurarlo en nuestro log4j.properties para que sólo registre trazas de nivel ERROR o superiores (recordad que sea cual sea el nivel de traza de log4j, la salida se publicará en System.out y el logging de JAVA las publicará por defecto como trazas de nivel INFO)

Glassfish ha luchado contra nosotros y ha perdido, por lo menos a nivel de logging. Nosotros le dominamos. No él, a nosotros. Y, desde luego, no estamos soñando… ¿o sí?

BONILINKS:

• Gente despotricando sobre el tweaking de System de Glassfish
• Gente flipando con el comportamiento de System.out
• La fuente del UniformLogFormatter (o el origen del formato de traza infernal de Glassfish)
• Información Oficial de Glassfish sobre configuración de logging, donde se les olvida comentar lo del asuntillo del System.out…
• Información para entender lo básico de la API Java Logging

Artículos relacionados:

1. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (III) Tercera parte del tutorial sobre como utilizar transacciones y bloqueos...
2. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (II) Segunda parte del tutorial sobre como utilizar transacciones y bloqueos...
3. Transacciones y bloqueos en Glassfish v3 con EJB3.1 y JPA2 (I) Un sencillo tutorial sobre como utilizar transacciones y bloqueos con...

Todos los que hemos trabajado con páginas y aplicaciones web conocemos la entidad   o, al menos, creemos conocerla… Pero, sorprendentemente, la mayoría de nosotros no sabemos qué es exactamente y eso hace que aparezcan problemas en la transición desde HTML hacia XTHML.

¿Queréis enteraros de qué es eso de   en apenas cinco minutos, mientras leéis una apasionante historia de intriga y misterio? Entonces, no lo dudéis y seguid leyendo…

EL MISTERIO DE LA JSPX DESESTRUCTURADA

Hace poco que empecé a sacar algo de tiempo libre para aportar al desarrollo  puro y duro de STORETTO. Al instalar el entorno de trabajo en Eclipse,  casi me caigo de la silla golpeado por un error rojo y horrible que señalaba a una JSPX traidora y maligna donde, según el IDE, había errores en la estructura del XML, la etiqueta de cerrado ‘</h:form>‘ no se correspondía con ninguna etiqueta de apertura.

Cuando les pregunté a los desarrolladores por qué daba el error, me dijeron que era un error de Eclipse porque la estructura XML de la página estaba bien, funcionaba y la famosa etiqueta ‘ </h:form>‘ tenía su correspondiente etiqueta de apertura.

¡Tenían razón! Entonces… ¿Qué estaba ocurriendo? ¿Qué era lo que estaba rompiendo el Chi del Eclipse? Era un claro caso para Bonilla Holmes…

LO MALO DE UN ECLIPSE, ES QUE NO TE DEJA VER

Cuando oficialmente eres Jefe de Equipo, Project Manager o Code Leader, te puedes permitir ciertas licencias, como pararte a ver porqué algo falla aunque el error no sea crítico, que casi compensa el horrible título con el que definen tu puesto.

Así que me enfrenté al error con valentía y decisión. Era evidente que el el Eclipse fallaba a la hora de analizar la estructura de la página, la pregunta era: ¿Por qué?.

Al principio pensé que era por un código comentado que incluía la etiqueta en cuestión, pero lo borré y el error seguía. La cosa se ponía difícil, pero, entonces, observé un montón de errorcillos (perdonad por mi léxico, no soy un experto en Eclipse, yo soy más de IDEA) provocados por el uso de la extraña combinación de caracteres ‘&amp;amp;nbsp;‘.

¿Para qué diantres estábamos escapando el carácter & para, a su vez, escapar el carácter espacio? No tenía sentido. Cuando lo cambié a &amp;nbsp; sin más, el error de estructura en Eclipse dejó de aparecer, pero la página daba un error al cargarse. No un error de maquetación, sino en la compilación en servidor.

Raro, raro, raro…

Cuando volví a preguntar a los desarrolladores si tenían idea alguna de por qué podía fallar la carga de la página web, me dijeron que no tenían ni idea pero que, por algún motivo, JSF -el framework que utilizamos- no se comía directamente el &amp;nbsp; y, por eso, teníamos que escapar el carácter & utilizando &amp;amp;.

ELEMENTAL, QUERIDO WATSON

No tenía sentido. Una cosa es que al tocar la página web descoyuntara la maquetación y otra cosa es que  rompiera el código del servidor. No comprendía muy bien qué tenía que ver JSF con los caracteres de escape del código HTML, así que le pedí al tío que más sabe de JSF a este lado del Pecos, César Vivero, que mirara conmigo las trazas de servidor.

No nos hizo falta más de 10 segundos para localizar el error -”The entity “nbsp” was referenced, but not declared.“- e, inmediatamente, mi mente de viejo rockero sufrió un espectacular flashback peliculero cuando recordé que había tenido el mismo problema al trabajar con hojas de estilo XSLT que producían HTML.

Miré a mi compañero y le dije “Lo tenemos César. Ya sé quién mató a Laura Palmer“.

EL HTML NO ES XML, Y XHTML TAMPOCO

El error en servidor no lo daba el uso de JSF en sí, sino el validador del XML de la página web. Sí, amigos, porque nuestras páginas son JSPX, lo cual quiere decir que utilizan XML y XHTML como lenguaje de marcas, no HTML… y ahí estaba el problema.

&amp;nbsp; es una entidad usada para representar el carácter espacio en HTML, pero no en XML. Aunque a veces se nos olvide y haya cierta confusión al respecto porque algunas de las entidades, como la utilizada para representar el carácter ‘&‘ -&amp;amp;- sean idénticas, las entidades de caracteres en XML y HTML no son iguales.

Así, lo que está cantando el validador de XML es, traducido al cristiano, “no sé qué me estás contando, brother“. Y eso es así porque &amp;nbsp; para XML no es absolutamente NADA. El carácter espacio en XML es &amp;nbsp; o, lo que es lo mismo, el carácter 160 de UNICODE.

Este error trivial es relativamente normal ya que, muchas veces, los desarrolladores trabajan directamente con una maqueta en HTML proporcionada directamente por un diseñador y la adaptan al lenguaje de plantillas correspondiente para que en java acabe siendo una JSP -con HTML incrustado- o una JSPX con XHTML.

UNA SOLUCIÓN QUIERO…

Para poder solucionar este problema tenemos dos posibilidades:

1. Utilizar el DOCTYPE al comienzo de nuestra página XHTML para que identifique la entidad &amp;nbsp; tal y como se especifica en este enlace:

Por ejemplo, para una página XHTML cuyo nodo raíz es jsp:root, escribiríamos:

<!DOCTYPE jsp:root [
<!ENTITY nbsp "&amp;nbsp;">
]>

2. Haciendo una sustitución masiva de la entidad &amp;nbsp; por la entidad &amp;#160 que sí es una entidad reconocida en XML.

Lo que nunca descubrimos fue por qué Eclipse se volvía loco, pero el chi de los programadores ahora descansa tranquilo porque la pestaña de avisos y errores ya no muestra ninguna inquietante aspa roja. El misterio de la JSPX desestructurada había sido resuelto.

]]> http://sixservix.com/blog/david/2010/08/18/nbsp-en-xhtml/feed/ 339