Monthly Archives: octubre 2008

Scrum y XP

Después de darle un repaso al libro Scrum y XP desde las trincheras, he visto que muchas de las técnicas en las que se basa, son como las que usaban nuestros profesores dinámicos en el colegio para motivarnos a participar en clase.

En esencia, es eso, que cada analista/programador se involucre en lo que está haciendo, llegue a un diseño y una finalidad y, sobre todo, que la información sobre lo que se hace, fluya sin que las interrupciones hagan que el trabajo se pare.

Recomiendo la lectura del documento, puesto que muestra cómo funciona Scrum, XP y algunas técnicas más, en el día a día de varios grupos de desarrollo de Scrum, de la mano de un coach y gerente, encargado de llevar a cabo el desarrollo de productos dentro de una empresa.

Yo, por mi parte, en la etapa en que me encuentro, usaré lo que buenamente pueda para hacer que mi equipo de desarrollo sea más óptimo y, sobre todo, nos divierta lo que hacemos.

La nueva revisión de C++ se llama C++0x

Las últimas revisiones de este lenguaje fueron en 1998 (C++98) y en 2003 (C++03). Ahora se ha presentado el nuevo borrador para lo que será la siguiente revisión C++0x.

Las novedades, muy numerosas, se listan al completo en la wikipedia. Listo las que más me han llamado la atención:

  • Inicialización uniforme: se trata de que las estructuras y otros datos se inicialicen de una forma única y coherente.
  • Autodeterminación de tipos: se pueden declarar variables con la palabra auto de forma que el compilador elija el tipo que mejor convenga, según su uso.
  • Nuevos tipos de for: se podrán especificar con la palabra for al sintaxis típica, una que tome valores de un array y los deposite en un elemento (int x : my_array) y otra, en las funciones estándares, que será tipo for_each.
  • Funciones Lambda: una forma de decir que se permite la declaración de funciones anónimas (como se llamaría en Java) dentro del código de otra función.
  • Concepts: es un tipo más avanzado que las Templates.
  • Mejoras en la declaración de clases: se han agregado facilidades y mejoras al declarar el prototipo de las clases.
  • Nuevas formas de declarar los literales: se pueden declarar texto de tipo Unicode con solo agregar una u antes de las comillas dobles.
  • Modelo de memoria multitarea: una serie de optimizaciones y mejoras para el multihilo y la gestión de memoria.
  • Almacenamiento local de hilos: cada hilo tiene sus propias variables.
  • Tablas hash: la posiblidad de introducir arrays donde los índices, en lugar de ser números, sean textos, como parte de la librería estándar de C++.
  • Expresiones Regulares: también agregado en la librería estándar de C++, la posibilidad de usar expresiones regulares sin problemas.

Y muchas más cosas. Recomiendo leer el borrador a quién realmente le interese. Microsoft parece que ya planea agregar muchas de estas características en Visual Studio, para su versión MVC++2010, y en gcc se tendrá en cuenta para futuras versiones.

Vía: Yet Another Programming Weblog.

Serialización de Información

En los tiempos que vivimos, de la red 2.0, la programación de elementos aislados comienza a ser cada vez menos frecuente, mientras que el desarrollo para la web, para Internet, de aplicaciones que sean escalables, redundantes y tolerantes a fallos, se incrementa de forma vertiginosa.

En ese aspecto, los programas deben de sincronizar sus datos, lo que procesan, con otros elementos de un mismo sistema o copias del mismo (a modo de redundancia).

El envío de datos estructurados en forma de vector, matriz, estructuras heterogéneas o incluso objetos, a través de la red, se complica, puesto que se debe de realizar a través de un sistema que permita su perfecto encapsulado para que al realizar la acción contraria, los datos mantenga su forma íntegramente.

Esta vertiente se ve cada vez más patente en el diseño web con usos de elementos como AJAX, que solicita un paso de información entre servidor y cliente para el proceso en la parte del cliente de todas las acciones de interacción con el usuario.

En este sentido, en el envío de datos de forma plana entre elementos de un mismo sistema, o incluso sistemas distintos, se usa la serialización.

La serialización es un sistema que permite convertir a un formato específico, totalmente de texto, de modo que pueda ser transmitido de forma fácil a través de la red y para cualquier lenguaje de programación. Hay muchos tipos se serialización:

  • XML: consiste en convertir a una estructura de XML toda la información estructurada que se encuentre en el sistema y se quiera transmitir.
  • JSON: es un formato en el que se pueden escribir las estructuras de datos de forma reconocible por los programadores y asequibles para lenguajes como JavaScript.
  • YAML: es otro meta-lenguaje como JSON que propone la forma de escribir los datos, sus estructuras y organización de forma que sea mejor vista por los programadores, e incluso los que no son programadores, al mismo modo que constituye un formato simple y compacto para la transmisión de datos.

Dentro de cada lenguaje, de forma específica, también puede haber otros mecanismos de serialización, como es el caso de PHP, que usa unas funciones de serialización (serialize, unserialize) para tareas como guardar la información en las sesiones, o incluso usarlas para guardar información en memcached.

El SIMO se suspende

Parece ser que ya es oficial, según fuentes de la organización del evento que se lo han hecho saber a El Mundo y el País entre otros, que el SIMO en este año 2008 no se va a celebrar, por el motivo de que faltarán las grandes empresas (Telefónica, Orange, Microsoft, Toshiba, Siemens, Fujitsu…).

¿Resurgirá para el 2009? :-S

Desmitificando: software y su mantenimiento

Desde siempre, cuando una empresa apuesta por software privativo frente a software libre o de fuente abierta, lo hace por tener cubiertas las espaldas, por tener garantías y saber que hay una empresa que responde por ese software, tanto en mantenimiento, como en incidencias graves, que pueden llegar a pagar indemnizaciones.

Este es el principal motivo de que se abogue por software propietario, simple y llanamente. Cualquier otro motivo es un mito, como cualquiera de los siguientes:

  • Una empresa te dará más y mejor soporte: normalmente suele… o solía ser así. Las empresas de software contratan programadores, analistas y una serie de personal que son capaces de desarrollar un software más o menos eficiente y después mantenerlo… pero, existen muchos casos en los que este soporte y mantenimiento, no se ha pensado, no se da o es ineficiente. Por:
    • El software se ha desarrollado contra-reloj, sin fuerte planteamiento flexible a cambios y falto de documentación sobre la filosofía que sustenta que todo esté “ensamblado” de la forma en la que lo está.
    • La programación ha sido realizada “sobre la marcha” haciendo el software inconsistente, con gran cantidad de fallos y las soluciones no terminan de llegar. Con cada incidencia reportada aparecen nuevas.
    • El equipo de desarrollo cambia íntegramente o parcialmente, haciendo que el nuevo equipo programe el hard-coding de una forma distinta al anterior grupo, con lo que el software va mutando y distnaciándose del planteamiento original, que fue informado únicamente al primer grupo.
    • Una empresa tiene los recursos humanos limitados y, en caso de tener mucho trabajo, puede que incluso esos recursos humanos ya no respondan de la misma forma que al principio.
  • Una empresa te garantiza el software: hay cláusulas que limitan ese tipo de garantía y, en muchos casos, incluso las incumplen con lo que tienen que tirar de un seguro que les pague la indemnización. Tener una garantía no te asegura que funcione y, sobre todo, si quien te da la garantía tiene una veracidad y credibilidad dudosa.
  • El software propietario está mejor hecho: no se sabe, puesto que no se puede ver. Lo que sí se sabe es que no debe de estar tan bien hecho cuando necesita ser reescrito entre versiones, muchas veces. De igual forma, sería mejor no fiarse de una empresa que no tenga departamento de calidad, que certifique que el proceso de desarrollo ha sido llevado usando un cierto proceso lógico y se han llegado a cumplir una serie de espectativas de forma satisfactoria.
  • Es mejor tener el producto que no un servicio: ciertamente, y por eso se debería de preferir tener un software con una licencia que te permite ciertas libertades sobre él, y no un producto del que solo se ha comprado una licencia que te permite usarlo con muchas limitaciones. Muchas veces incluso limitaciones en el tiempo. Adquirir una licencia es como adquirir el servicio de uso sobre un producto, a modo de alquiler, pero sin la ventaja de poder reemplazarlo sin coste adicional en caso de deterioro, el servicio de mantenimiento se suele contratar aparte.
  • Software a medida es caro, difícil de hacer y no suele cubrir las espectativas: si se piensa esto es que no se ha pedido su desarrollo a una empresa seria. El desarrollo de software es un proceso que se debe de seguir, desde una especificación hasta obtener el producto que el cliente quiere usar. Cuando se desarrolla sin seguir un protocolo, con limitaciones o simplemente saltándose pasos… esto deriva en un software “mal acabado”, que no cumple con los requisitos iniciales y que deja la sensación de que, cualquier “chapuza” sobre un software ya hecho (como Office o similar) hubiese sido mejor.

Bueno, la verdad es que podría extenderme mucho más, porque las chapuzas en el campo de la informática están a la orden del día, pero con tener presentes estos puntos, creo que es suficiente para tener una visión un poco más amplia de lo que hay y lo que realmente se debería de buscar en cada caso.

Recordar también que, el software libre es una gran librería de programas que sirven para probar, seleccionar algo que guste usar y solicitar modificaciones y/o ampliaciones sobre ese software en caso de necesitarlas.

Erlang: concurrente, distribuido y en tiempo real

Después de tiempo desarrollando aplicaciones casi exclusivamente en PHP, me encuentro en el problema de que PHP no es, ni mucho menos, un lenguaje de uso general, sino un lenguaje desarrollado y pensado para la creación de aplicaciones web de forma rápida y, de forma controlada, útil y potente para grandes proyectos.

Pero fuera de este entorno, en el background de las grandes empresas donde todo debe de ser escalable, redundante y en alta disponibilidad, y sobre todo cuando las aplicaciones no son para servidores web, usar un lenguaje que no está preparado para el desarrollo deseado, puede conllevar muchos quebraderos de cabeza, e incluso, no alcanzar el objetivo deseado.

Después de revisar varios lenguajes de programación (Java, Python, Ruby…) vi que hay también lenguajes de programación diseñados para tareas concretas y que, saliéndose de la especificación de lenguajes de ámbito general, se especializan en ciertas tareas, tal y como Perl es para el análisis de textos y PHP para la web, encontré esta pequeña joya, Erlang, que es un lenguaje específico para desarrollos que requieran de control de concurrencia, programación distribuida y desarrollos de tiempo real.

El lenguaje en sí ha sido diseñado por Ericsson y dispone de mucha documentación en su sitio web. Su sintaxis no es la típica copia de C que se seguía para Java, C# y PHP, entre otros, sino que tiene un formato nuevo, lo cual hace más lenta la curva de aprendizaje, pero para los programadores que ya hayan usado más de dos lenguajes de programación del tipo Ruby, Python, PHP y/o Perl, hacerse a una nueva sintaxis no será tanto problema.

Iré informando sobre mis avances con este lenguaje, a ver si me deja buen saber de boca ;-)

¿Está mi empresa organizada?

Cuando una empresa se forma, se intenta organizar el trabajo entre las pocas personas que la inician y si su estructura es buena y sus productos/servicios asequibles para el mercado, la empresa crece y con ella su personal. Es el inicio de los problemas.

Cuando una empresa crece, se contrata a más gente y estas personas comienzan a ocupar cargos que antes desempeñaba una persona en un porcentaje pequeño de su actividad laboral. El ritmo vertiginoso hace que las reuniones con esta nueva persona, para explicarle su cometido sean breves y escasas, así que terminan por hacer el trabajo a su manera.

Después de pasar por varias personas, varias formas de hacer las cosas y distintas formas de organizar las cosas, cuando un grupo de personas deja la empresa y retoman otro grupo, suele ser un caos y, el reactivar el proceso de producción en esa parte, muy lento y costoso.

El problema se debe a la falta de método y documentación.

Cuando una persona entra a trabajar en una empresa madura, suele entrar en un engranaje del que tiene que formar parte. Sus conocimientos básicos son los que se le solicitaban al entrar al puesto de trabajo, como pueden ser saber programar, una cierta metodología, idioma o titulación. Pero a partir de ahí, la formación debe de ponerla la empresa y, es en este punto, donde la mayoría de empresas, no tienen forma de explicarles a sus nuevos empleados lo que hay, lo que tienen que hacer o cómo hacer su trabajo.

El funcionamiento de una empresa, sus procesos y su burocracia, debería de estar recogida y revisada en un documento de Modelo de Negocio. En este documento se especifica cómo funciona cada departamento, los cometidos de cada uno de los subdepartamentos y las políticas de trabajo, comunicación y otros aspectos o típicos como seguridad laboral.

Así mismo, cada departamento y/o subdepartamento, debe tener claro su cometido y esclarecer una forma en la que realizar su trabajo, tener sus tareas bien definidas y documentadas para, en caso de enfermedad, vacaciones, cese o fallecimiento, el trabajo pueda ser cubierto por cualquier otra persona.

Estos tipos de documentos no son solo una gran utilidad para el propio empleado, sino también para las consultoras y asesorías externas, puesto que pueden optimizar dichos procesos, e incluso diseñar software que ayude y dé soporte a estos procesos.

¿Sería capaz de diseñar un modelo que optimice el rendimiento de su empresa?, un modelo de negocio podría desvelarle qué puntos podrían optimizarse y mejorarse, así como qué recursos tiene más explotados y cuáles están más libres.

¿Se nos hunde Internet?

Después de varias noticias algo catastrofistas, ha llegado la última que, en sí, podría afectar a todos los usuarios de Internet, puesto que se basa en el propio protocolo TCP/IP. Hasta el momento, la compañía sueca Outpost24, solo ha dejado caer la noticia y la promesa de extenderla en una conferencia.

En lo que llevamos de año, se han sucedido grandes vulnerabilidades de seguridad. La primera ha afectado la protocolo DNS, la segunda al protocolo BGP y ha habido otra vulnerabilidad sobre SSL que ha afectado solo a las distribuciones Debian y derivadas del mismo.

Esta última vulnerabilidad afecta al TCP/IP, aunque matizan los expertos que, de momento, solo es supuesta y que no solo afecta a IP, sino al conjunto TCP/IP. De momento, hasta que sea publicada la vulnerabilidad de forma específica por la compañía sueca, estamos ante, incluso, un posible FUD.

De todas formas, Internet, la concepción de sus protocolos más usados (como DNS y SMTP), no estaban pensandos para ser seguros, sino prácticos, puesto que Internet era una red a la que pocos tenían acceso. Hoy en día, el enfoque ha cambiado, pero los protocolos siguen siendo los mismos y, quizás, el problema haya sido la forma de parcheo que se ha realizado sobre los protocolos existentes, en lugar de optar por desarrollar mejores protocolos orientados a las necesidades actuales.

¿Estamos ante una necesidad de cambio en los protocolos de Internet?, ¿se nos hunde Internet?, no lo creo… pero llegan momentos difíciles y quizás vientos de cambio ;-)