subscripción
Blog de Julio César Pérez Arques
Sobre pruebas y errores
Junio 24th, 2009 - [Enlace local]
Veo en las noticias las imagenes de una prueba de carga en un nuevo puente de una autovía en Galicia (España). Durante un momento me quedo absorto mirando la larga flota de camiones sobre el majestuoso puente. Impresiona. No puedo evitar pensar: Vaya! eso sí que es una prueba manual. Y luego yo quejándome sobre las pruebas manuales que hacemos en el desarrollo de proyectos software...
Bastan un par de segundos para darme cuenta de la tontería de mi reflexión. Si eso fuera una primera ejecución de una prueba exigente sobre un proyecto software recien construido, el puente se habría caido arrastrando a la flota de camiones tras él.
En el caso del puente, lo que no estamos viendo es todo el proceso de pruebas y control de calidad, que se ha realizado previamente en cada una de las fases del proyecto para evitar errores.
Pero comparar nuestro mundo de desarrollo software -¿ingeniería software?- con el de la construcción o cualquier otra ingeniería es una equivocación. Una equivocación torpe, injusta y desafortunada, porque, entre otras cosas, hace imaginarse a un programador como a un obrero. Así nos va.
Aunque centrémonos en los errores. Errar es humano. Obvio. A veces estamos distraidos, cansados, estresados, desmotivados o simplemente no somos perfectos y se nos escapan cosas.
Otro hecho es que los proyectos software salen a producción con demasiados errores. También obvio si estudiamos el ineficaz proceso de pruebas que se sigue en la mayoría de proyectos, basado en unas pruebas mínimas, manuales y sin documentar. Por lo que las pruebas dificilmente se repiten en el tiempo, aunque se modifique código afectado, haciendo aparecer nuevos errores o, peor aun, haciendo reaparecer viejos errores. ¿Vosotros compraríais algo cuyo proceso de pruebas fuera así?
Lo primero no tiene solución. Pero sí se puede minimizar el efecto. Contratando talento y con motivación.
Lo segundo sí tiene solución. Aplicar un proceso profesional de pruebas, basado en pruebas automatizadas, completas, independiente y repetibles. Los errores seguirán produciéndose, pero la mayoría serán detectados antes de llegar a producción.
Por supuesto, siempre hará falta alguna prueba manual pero, al igual que en el puente, será más un mero trámite de aceptación que el actual infierno de prueba y error sin fin.
» Leer más, comentarios, etc...
Blog de Julio César Pérez Arques
Nuevo cambio de look y AdSense
Junio 17th, 2009 - [Enlace local]
Aprovecho para anunciar un par de cambios en el blog: (1) nuevo cambio de look y (2) AdSense.
Hacía tiempo que me había cansado del anterior template, un día sin querer dí con este The Journalist y hoy he decidido probarlo, tras unas mínimas modificaciones. No tiene más.
El tema de AdSense sí requiere un poco más de explicación. No pretendo monetizar el blog. No creo ni que le fuera a sacar un euro aunque lo intentara. Sin embargo, sí quiero probar AdSense y ver cómo funciona de primera mano. Últimamente se me ha reactivado la vena emprendedora, así que quiero ver cómo va esto de la publicidad.
Como siempre, cualquier opinión sobre alguno de los 2 temas será más que bievenido!
» Leer más, comentarios, etc...
Ideas + Ingeniería del Software
Opera Unite: involucionando la web
Junio 16th, 2009 - [Enlace local]
Hoy Opera ha puesto fin al hype que ellos mismos comenzaron hace un par de días, desvelando su proyecto secreto: Opera Unite. Aunque comercialmente se pueden decir muchas más cosas, lo resumiré en un servidor web dentro del navegador. Mediante esto y un API se desarrollan servicios que se ejecutarán en tu ordenador. Por ejemplo, reproductor multimedia, gestor para compartir ficheros, páginas web, chat...
Actualización 0906161825: Ender Wiggins, un tío mucho más responsable que yo, lo está probando antes de juzgarlo (ver comentarios), por lo que tacho un par de cosas de las que me quejo sin deberlo (no lo borro para que quede constancia ;) ).
Vaya por delante que (todavía) no lo he probado, pero el concepto en sí no me gusta, por muchas razones:
- La fundamental es que obviamente tienes que tener el ordenador encendido constantemente para que esto sea útil. Somos muchos los hace años (incluso hoy, seguro) nos montamos un servidor ftp, web o similar para poder acceder a nuestros ficheros o colgar nuestras páginas web, pero se debía a que no había demasiadas alternativas posibles. Hoy en día, con servicios de almacenamiento baratos (o muy asequibles, más que el consumo energético de nuestro sobremesa) podemos cubrir esto fácilmente. Algunas de los siguientes motivos por lo que no me gusta no dejan de ser derivados de esto.
- No quiero poder acceder a mi ordenador desde cualquier parte. Lo que quiero es poder colgar mi contenido en la red y poder acceder a él donde sea.
- Aún en el caso de querer acceder a mi ordenador, las alternativas son incontables: servidores web, ftp, ssh... Servidores multimedia que además convierten el formato del contenido (hay varios que se orientan a ser servidores para la Wii, por ejemplo). Hasta WinAmp ofrece desde hace tiempo un servidor propio.
- El modelo p2p de distribución de contenido se popularizó entre otras cosas por las implicaciones legales de que un proveedor se convirtiese en distribuidor de contenido. La SGAE y similares se estarán frotando las manos al ver la cantidad de incautos que van a compartir sus colecciones de mp3.
- Hay alternativas para todas las funcionalidades que ofrece que seguro que son mejores. No creo que su servidor web pueda competir con Apache, por ejemplo.
- Siempre se ha podido compartir ficheros (email, directamente a través de cualquier messenger, servidores propios...). No hay nada novedoso en esto.
- Normalmente si quiero compartir ficheros lo hago con Dropbox, que me da 2GB gratis. Y si mis necesidades son mayores, por 10$ al mes tengo 50GB. Sólo el consumo energético de tener el ordenador encendido a todas horas seguro que es mayor. Es un cliente muy ligero, que ni se nota que está corriendo, y me permite tener sincronizados directorios entre varios ordenadores, y también compartir mediante enlaces públicos. Y mi contenido siempre está accesible en su web.
- Si quiero compartir de verdad, lo hago mediante p2p.
- ¿Realmente queremos comprometer aún más la seguridad de nuestro ordenador personal?
- ¿Qué valor van a tener los enlaces a páginas alojadas en PCs, que dependen de tener el ordenador encendido? Además, obviamente la fiabilidad de un PC y una red casera no tiene nada que ver con un servidor "de verdad".
Se necesita, sí o sí, usar DNS dinámicas.- Nuestras conexiones a internet suelen ser asimétricas, con una velocidad de subida irrisoria. Poner contenido online es lento una vez, pero todos los accesos a ellos son bastante rápidos. Sin embargo, con Opera Unite serán lentos siempre (hasta que Telefónica quiera, al menos).
- En la época en la que las prácticas se entregaban en disquetes sí era muy útil montarnos un servidor ftp. Hoy en día, con una memoria USB de 16GB en el bolsillo, no lo es tanto. Y con almacenamiento en red gratuíto, menos.
- ¿Qué pinta toda esta funcionalidad en el navegador?
A la gente ya le costaba configurar el router para redirigir puertos del eMule, esto será lo mismo.- ...
Ójala GDrive, si finalmente se materializa, cumpla las expectativas creadas: gran(-dísimo) espacio de almacenamiento, API para acceder al contenido, búsqueda completa... Eso sí sería un paso adelante.
» Leer más, comentarios, etc...
Ideas + Ingeniería del Software
Redes sociales (II): Firefox Collections
Junio 14th, 2009 - [Enlace local]
Aunque en estos meses de humo nubes hablar de redes sociales suena demodé, tenemos novedades para Firefox que nos pueden hacer reflexionar sobre ello.
Las Firefox Collections son conjuntos de extensiones, listados, que puedes compartir y a las que te puedes suscribir. Por ejemplo, la primera colección que iba a figurar en el editor's pics no podía ser otra: Web Developer's Toolbox. Hecha por el usuario Mozilla (pero podría ser cualquiera), recopila las extensiones que ellos consideran fundamentales para el desarrollo web. Yo, una vez me instale la extensión 'Add-on Collector', puedo suscribirme a esta lista. Al hacerlo podré instalar las extensiones que la componen, recibiré actualizaciones si añade alguna al listado... Es una funcionalidad social pero muy potente. Cada sector puede colaborar generando un lote de extensiones interesantes: brokers de bolsa, bloggers, desarrolladores...
Esto genera una funcionalidad colateral muy interesante: sincronización de extensiones entre navegadores. Es algo que llevo necesitando desde que comencé a usar Firefox, y, aunque había formas de hacer algo similar, nada que me satisficiese.
No sé cómo se lo plantearon en Mozilla: ¿Cubrir la necesidad de sincronizar extensiones y de ahí salió la idea de compartirlo? ¿Al revés? ¿Ambas a la vez? El hecho es que la funcionalidad social (compartir colecciones) es la generalización de un caso particular (sincronizar mis extensiones) de interés para el usuario. Este es un ejemplo perfecto de solución del problema del arranque en frío en redes sociales comentado con anterioridad:
- Cubre una necesidad personal existente...
- ... y a la vez aporta un gran valor añadido.
- Cuando vayas a implementar algo, piensa si en vez de resolver el caso específico puedes encontrar una solución más general...
- ... y piensa si esa solución general tiene potencial con un botón "compartir con más gente".
» Leer más, comentarios, etc...
Ideas + Ingeniería del Software
CexC, Teiid y el estado del blog
Junio 14th, 2009 - [Enlace local]
Llevo mucho sin actualizar el blog (dos meses), y antes de la última entrada el ritmo ya había bajado. Alguna razón tenía que haber, además del habitual cansancio. Esta página siempre ha sido una vía de escape de mis inquietudes tecnológicas, pero últimamente me parecía estar totalmente desinteresado de las novedades del sector. El escaso tiempo libre y el que me ocupa la fotografía hacían el resto.
Dándole un poco de vueltas este desinterés realmente no existe, lo que ocurre símplemente es que lo cubro en horas de trabajo. Hasta ahora mi trabajo había sido de desarrollo o de gestión de proyectos, lo que apenas dejaba margen al cacharreo con nuevas tecnologías, por lo que esa necesidad que realmente tengo de estar al día, de probar cosas nuevas, se cubría en casa.
Desde finales del año pasado estoy trabajando en el Centro Experimental del Conocimiento (CexC para los amigos), y mi papel es, en gran medida, realizar un esfuerzo de investigación e innovación. Para nosotros es fundamental evolucionar nuestra forma de trabajo y mejorar constantemente las herramientas a utilizar, y una buena parte de mi tiempo se va en leer artículos, noticias, descargar nuevas aplicaciones o componentes, y probarlos y pegarme con ellos. La verdad es que da gusto cuando, en este sector tan condicionado por los plazos y clientes, se tiene oportunidad de invertir una buena parte de tu tiempo en tareas de innovación, y se confía en la adopción de nuevas tecnologías en vez de atarse a la tradición.
Como medio para dar algo más de visibilidad a esto, y como medio de comunicación, en el CexC acabamos de abrir un blog de nuevas tecnologías en el que ir mostrando al menos una parte de esta inversión. Todavía está en pañales, pero os agradecería que figurase en vuestros marcadores o lectores RSS.
La primera entrada habla de Teiid, una fantástica herramienta para virtualización de datos que acaban de liberar en jboss.org. Cualquiera que haya realizado una aplicación empresarial con varias fuentes de datos diferentes sabrá valorarla como corresponde, en mi opinión. El primer artículo es introductorio, pero iremos ampliando con ejemplos prácticos de esta y otras tecnologías de JBoss con las que trabajamos desde hace tiempo.
Todavía no dispone de comentarios (espero activarlo en breve), así que quien quiera abrir el diálogo que lo haga por aquí mismo.
Nos vemos por el CexC :).
» Leer más, comentarios, etc...
Blog de Julio César Pérez Arques
Buenas practicas para desarrollar servicios web SOAP
Junio 11th, 2009 - [Enlace local]
Como complemento a mi último post, Arquetipo de WSDL interoperable, he decidido publicar este post con varias buenas prácticas para desarrollar servicios web SOAP. Como siempre, son sólo buenas prácticas según mi criterio, conocimiento y experiencia.
- Analiza qué servicios web y con qué operaciones hay que desarrollar. Parece de perogrullo, pero es uno de los fallos más repetidos. Según mi experiencia suelen darse 2 esquemas a la hora de desarrollar servicios web: (i) el servicio web dios con todas las operaciones para él y (ii) un servicio web por operación. Ambos son malos. El primero incluso peor. Así que piensa y diseña servicios web con las responsabilidades bien repartidas, que sean cohesivos, extensibles, escalables y reutilizables.
- Escribe tu mismo el fichero WSDL (Contract-First). Es el interfaz, el contrato y, en definitiva, la clave para una interoperabilidad real e independiente de la tecnología. Además los generadores de WSDL pueden introducir dependencias con una tecnología concreta. Por eso merece la pena aprender a escribir WSDL (aquí) y schemas XSD (aquí).
- A la hora de diseñar el interfaz de las operaciones, ten siempre en cuenta que es mucho más eficiente un único mensaje enorme que el equivalente en multiples mensajes.
- Sé coherente con la nomenclatura de namespaces de la organización. No hay nada que de peor impresión que un servicio web que no ha cuidado los namespaces.
- El WSDL debe ser compatible con el WS-I Basic Profile. El WS-I Basic Profile es un conjunto de especificaciones y buenas practicas definidas por la industria para obtener servicios web interoperables. Actualmente la última versión final publicada es la 1.1. Como mínimo, evita siempre los estilos RPC y sus tipos de datos no XML (SoapArrays), en su lugar usa el estilo Document/literal.
- Usa http://localhost:puerto como dirección url del endpoint y deja que sea el motor de webservices el encargado de sustituirla por la real. Así evitarás tener un fichero WSDL por entorno.
- Separa la definición de los mensajes del fichero WSDL. Para ello, diseña por separado un schema XSD donde se definan los mensajes y que sea importado por el fichero WSDL. Las principales ventajas son (1) reduce el tamaño/complejidad del WSDL, (2) permite utilizar editores especializados para el diseño del schema XSD y (3) permite reutilizar schemas y namespaces.
- Define los mensajes de forma detallada mediante las restricciones de los schemas XSD. De esta forma podrás validar los mensajes a nivel de XML mediante el api XML u OXM que uses, sin necesidad de implementar código propio.
- A la hora de diseñar el schema XSD, crea tipos y elementos globales (a nivel raíz) para poder reutilizarlos, tanto a nivel de elementos XML como clases del lenguaje de implementación del servicio web.
- Además, usa minOccurs=0 para definir un elemento como opcional y nillable=true para indicar que un elemento puede ser vacío pero siempre estará presente en el mensaje XML. Ojo, no es lo mismo.
- Si necesitas enviar ficheros adjuntos (attachments), hazlo a nivel de http attachment y no como un elemento del mensaje XML.
- Automatiza el proceso de generar el Skeleton y las clases OXM de mensajes del servicio web a partir del WSDL (wsdl2code).
- Para realizar pruebas unitarias del servicio web no necesitas desplegarlo, puedes programar tus tests a nivel de la clase Skeleton. Ahorraras mucho tiempo y ya desplegarás para las pruebas de integración o alguna demo.
- Guarda log de los mensajes de entrada y salida junto con datos del cliente (ip, usuario), a nivel de fichero o base de datos.
- Redacta un documento Guía de pruebas de integración que sea completo e incluya casos de error y no sólo los casos básicos.
» Leer más, comentarios, etc...
Blog de Julio César Pérez Arques
Arquetipo de WSDL interoperable compatible con WS-I Basic Profile 1.1
Junio 9th, 2009 - [Enlace local]
En este post voy a publicar un WSDL de ejemplo que cumple con el WS-I Basic Profile 1.1.
La clave de la interoperabilidad entre servicios web SOAP está en su interfaz WSDL. El WS-I Basic Profile es un conjunto de especificaciones y buenas prácticas definidos por la industria para desarrollar servicios web interoperables independientemente de la tecnología con que fueron desarrollados. Su última versión final es la 1.1 y debería ser un must-know para todos aquellos que tengan que definir un WSDL.
El WSDL de ejemplo está diseñado para que use un schema XSD donde definir los mensajes de petición y respuesta de las operaciones. De esta forma se puede usar un editor de XSD como ayuda para diseñar la estructura de los mensajes, que es la parte más importante del WSDL y que requiere el verdadero esfuerzo intelectual. Dejando de esta forma el proceso de definir el fichero WSDL a un mero trámite de copy&paste.Además es una buena práctica en una SOA publicar los schemas xsd para reutilizar sus elementos.
Este WSDL sólo tiene 1 operación. Además usa los siguientes literales como ejemplo:
- Nombre del servicio: nombreServicio
- Nombre de la operación: nombreOperacion
- TargetNamespace del servicio: http://dominio/ws/nombreServicio
- TargetNamespace del schema xsd: http://dominio/ws/nombreServicio/schema/msg
El fichero schema xsd nombreServicio_msg.xsd sería el siguiente:
La operación del servicio tiene 2 elementos de entrada y 2 de salida, todos de tipo string, a modo de ejemplo. Puedes modificar los mensajes existentes o crear mensajes para nuevas operaciones a tu gusto. No olvides modificar el targetNamespace.
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns:tns="http://dominio/ws/nombreServicio/schema/msg"
xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://dominio/ws/nombreServicio/schema/msg">
<element name="nombreOperacionRequest">
<complexType>
<sequence>
<element name="campo1" type="string"/>
<element name="campo2" type="string"/>
</sequence>
</complexType>
</element>
<element name="nombreOperacionResponse">
<complexType>
<sequence>
<element name="campo1" type="string"/>
<element name="campo2" type="string"/>
</sequence>
</complexType>
</element>
</schema>
Si el schema xsd se complica puedes plantearte dividirlo por operaciones o por entrada y salida.
Este fichero puede ser descargado aquí.
El fichero wsdl nombreServicio.wsdl sería el siguiente:
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="nombreServicio"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
xmlns:tns="http://dominio/ws/nombreServicio"
xmlns:msg="http://dominio/ws/nombreServicio/schema/msg"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:ns="http://schemas.xmlsoap.org/soap/encoding/"
targetNamespace="http://dominio/ws/nombreServicio">
<!-- Importacion de schemas -->
<import namespace="http://dominio/ws/nombreServicio/schema/msg"
location="./nombreServicio_msg.xsd"/>
<!-- Definicion de mensajes -->
<message name="nombreOperacionRequest">
<part name="body" element="msg:nombreOperacionRequest"/>
</message>
<message name="nombreOperacionResponse">
<part name="body" element="msg:nombreOperacionResponse"/>
</message>
<portType name="nombreServicio">
<!-- Relacion Mensaje-Operacion -->
<operation name="nombreOperacion">
<input message="tns:nombreOperacionRequest"
wsaw:Action="urn:nombreOperacion"/>
<output message="tns:nombreOperacionResponse"
wsaw:Action="urn:nombreOperacion"/>
</operation>
</portType>
<binding name="nombreServicioBinding" type="tns:nombreServicio">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<!-- Definicion de operaciones -->
<operation name="nombreOperacion">
<soap:operation soapAction="urn:nombreOperacion"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
<service name="nombreServicio">
<port name="nombreServicioPort" binding="tns:nombreServicioBinding">
<soap:address location="http://localhost:8080"/>
</port>
</service>
</definitions>
Lo primero sería modificar los nombres del servicio, operación y targetNamespaces de ejemplo. Puedes añadir nuevas operaciones a tu gusto. Como puedes ver, he puesto comentarios indicando los sitios que deberían ser modificados.
No cambies la url del endpoint. Por lo general, los servidores de webservices detectarán la url y realizarán la modificación de forma automática. De este modo te evitas tener una copia del WSDL por entorno (desarrollo, pruebas, producción, etc.).
Este fichero puede ser descargado aquí.
Una vez realizadas las modificaciones convenientes no olvides validarlo todo, el schema xsd y el wsdl.
» Leer más, comentarios, etc...
Blog de SQUaC
Próximos cursos en usabilidad y testeo unitario
Junio 4th, 2009 - [Enlace local]
Os anunciamos dos cursos que vamos a ofrecer en Valencia en junio/julio, dentro del plan de formación del ITI .
Los cursos son:
- Usabilidad de aplicaciones interactivas (inicio el 30 de junio), que tiene como objetivos:
- Dar una visión general sobre la usabilidad de software y sus beneficios
- Describir de un modo práctico las dos principales técnicas de evaluación de usabilidad: la evaluación heurística y el test de usuarios
- Estudiar la relación entre la usabilidad y los ciclos de desarrollo de software
- Introducir otras técnicas relacionadas con la... [sigue ...]
» Leer más, comentarios, etc...
Mal Código
Buscar el error del usuario
Junio 4th, 2009 - [Enlace local]
Buenos días,Los datos son:Nombre de usuario: bbernatemail: boromirb@blablabla.comTeléfono: 5556664242Un saludo, Boromir BernatOn Wed, 2009-06-03 at 18:19 +0200, Misma Mente wrote:> Necesito que nos pases los siguiente datos para crearte una cuenta:>> Nombre del usuario:> email:> Teléfono:>> Un saludo, Misma>Ante este intercambio de correos entre un administrador y un usuario. ¿Cual es el fallo