Hoy he revisado las estadísticas de mi servidor web, como cada día desde hace ya años y veo que, el flujo del correo entrante, en lo que se refiere a SPAM, que se había mantenido en 1000 mensajes diarios, aproximadamente, con un 80% de SPAM, desde hace dos días se mantiene en 300 mensajes diarios, aproximadamente, donde solo el 40% es SPAM.

Leo en el blog de Tom Keating que no es un hecho aislado, que el spam está disminuyendo de forma global, lo que me sugiere la pregunta, ¿los spammers están también en crisis?

Reconociendo al sector informático como la cuarta parte de los estudiantes de las ingenierías que se estudian en las universidades españolas, la regulación de las titulaciones y el asegurar que dichas titulaciones son de calidad y corresponden a la calidad de nuestros vecinos europeos, se cierne sobre Estado y Universidades el debate de la responsabilidad de que esto sea así.

El Partido Popular, en el debate para votación de la Propuesta de No Ley (PNL) sobre la Ingeniería Informática, presentada por este mismo partido, hacía presentación y propuesta de querer defender las titulaciones informáticas por los motivos:

• Creación de Fichas de Grado y Máster donde se reflejen las Competencias de los Titulados de Ingenierías Informáticas.
• Dichas Fichas se crearon en el Libro Blanco, el cual fue anulado y retirado.
• No se han tenido en cuenta las Ingenierías Técnicas y las Ingenierías de Informática para la asignación de títulos que habilitan para el ejercicio de las diferentes profesiones de Ingenieros Informáticos.

Entre líneas, se puede entrever que el portavoz del Partido Popular, intenta dar voz a los Colegios de Informática para vencer el intrusismo que se origina en nuestro sector.

Por otro lado, el portavoz del PSOE, da los siguientes puntos en contra de la PNL, que son a tener muy en cuenta:

• En el contexto europeo, las titulaciones informáticas con relación a másteres, grado y doctorado son muy ágiles y no pueden estar sujetos a regulaciones.
• En este contexto que se tiene, es en el que operan las mejores universidades del mundo y que han demandado decanos españoles.
• Por ley, las fichas que se demanda hacer no pueden realizarse mediante la PNL, puesto que las titulaciones no están reguladas para funciones laborales concretas.
• Los estudiantes y titulados no pierden derecho ni valor de sus estudios y títulos, respectivamente.

Escuchando el audio completo, el portavoz del PSOE rebate el argumento de trasfondo de la PNL, que es establecer unos cortes y asignaciones laborales concretas en el campo de las Ingenierías e Ingenierías Técnicas Informáticas y, establece que, el medio expuesto es el equivocado, que se ha recubierto de algo llamativo, que se establezca como un FUD para la comunidad de estudiantes y profesionales para demandar algo que ya tienen otros Ingenieros como los Arquitectos, por ejemplo.

La votación se produjo, quedando 19 votos en contra, 17 a favor y 2 abstenciones. Con lo que, se deja libertad a las Universidades para el establecimiento de grados, másteres y doctorados.

Por otro lado, queda el tema del intrusismo que, si la educación de las universidades preparase para el trabajo real, yo mismo defendería, pero teniendo en cuenta de que se enseña a ingenieros para desarrollar el trabajo de técnicos… y que mucha gente si titulación resulta, en muchos casos, más profesional y efectiva que gente con titulación, lo que se debería es de defender más que la PNL no haya salido y que las universidades, con la flexibilidad que les ha sido otorgada, se encarguen de hacer competente su plan de estudios para hacer que los universitarios sean trabajadores e ingenieros competentes.

A día de hoy, si se busca a, por ejemplo, un Arquitecto Java, que es una persona que establece el análisis de un productos software, la solución arquitectónica en base a un diseño general y su seccionado para el trabajo de grupos más pequeños… algo básico y rudimentario para un ingeniero, ¿cuántos titulados serían capaces de realizar este trabajo?, ¿cuántos de ellos no se pondrían directamente a desarrollar todo lo que pide el cliente directamente en Visual Basic?

Quizás, lo que debería de haber es más control de calidad en los estudios y enseñanzas de las universidades a través de exámenes y certificaciones a sus alumnos, para asegurar que salen ingenieros e ingenieros técnicos competentes.

Se ha hablado mucho sobre la escasez de documentación en proyectos libres, tanto de manuales técnicos o de administración, que expliquen como instalar y administrar el software, como manuales de usuario, que expliquen cómo realizar las actividades que propone el software realizar.

Es claro que, cuando una persona aprende a desarrollar, a programar, se sienta frente al ordenador y comienza esa frenética batida de golpes contra el teclado, una pausa para ver los resultados, un momento de pensar en el siguiente paso, y otra vez a teclear… en esos momentos, la documentación, si se piensa hacer, es algo que se estima para un futuro… para cuando se dé a conocer.

Es lógico que un proyecto grande, creado con una línea en mente, a veces por una empresa o una entidad como puede ser una fundación o una universidad, suele ser otra cosa (casos como MySQL, PHP, PostgreSQL, Firefox, OpenOffice, Apache, …).

La documentación es como la lluvia, nunca cae a gusto de todos, por lo que es muy complicado realizar un documento sobre un programa que cumpla con las expectativas de todos los posibles usuarios que vaya a tener el programa.

Los tipos de documentación que se han identificado a lo largo de los años pueden englobarse dentro de los siguientes grupos:

• Receta (o How-To): es un documento para gente que quiere hacer algo funcionar de forma rápida y no se quiere parar en detalles. Suelen ser documentos cortos, concisos y estructurados en pasos.
• Getting Started: algo así como los primeros pasos. Es para gente que quiere ver algo funcionar de forma rápida, para después centrarse en los detalles. Es básicamente en lo que se fundamenta Linux, Unix y demás sistemas parecidos… la filosofía Unix.
• Manual: suele ser un libro extenso donde se explican, por capítulos, cada parte específica del programa. Este tipo de documento suele venir bien para quien tiene interés en aprender a usar bien el programa y, depende del enfoque, el modo en que se use: usuario, administrador, instalación…
• Tutorial: parecido al anterior, pero más pedagógico, intenta adentrar de una forma más suave al usuario a lo que es el uso del programa.
• White Paper: algo así como la filosofía en la que se basa el programa. Explica la ideología, en lo que se basa, pero no cómo se usa. Muy útil para quien tiene interés en saber el trasfondo de la creación del programa.
• Guía de Referencia: suelen ser los comandos o atajos que se pueden usar en cada parte del programa, ya sean comandos, teclas rápidas, combinaciones, menús de acceso… depende de cómo se presente el programa.

Hay proyectos, comerciales y libres, que reúnen toda esta variedad de documentos, lo cual es muy útil y, aún así, sigue habiendo problemas entre los usuarios, puesto que la calidad u orientación de los mismos, puede no ser muy precisa o atinada. En este aspecto, los manuales, en su mayoría, suelen tener un baremo en el que presentan el público a quien va dirigido el documento y lo que trata en sí, encontrándose así libros para gente nueva en el tema, de nivel bajo, intermedio o avanzado.

En proyectos de gran tamaño, como puede ser Apache, la documentación que se reúne, puede sobrepasar, perfectamente, las mil páginas. Más en concreto, el manual de usuario con guía de referencia de PHP (de su página web) tiene un tamaño de aproximadamente 2000 páginas.

Por lo tanto, no es que los programadores o desarrolladores no hagan documentación… es que escribir documentación es una tarea ardua, larga y conlleva más tiempo que en escribir el código del programa que se documenta para, después, encima, ver que la documentación escrita no es suficiente, o no se entiende bien… ya que, además, si la escribo en castellano, no es lo mismo que si la escribo en inglés, por supuesto.

Cada lenguaje que es potencialmente útil para el desarrollo web, termina teniendo un framework para el desarrollo de aplicaciones web de forma rápida. A continuación pongo un listado de los lenguajes con sus respectivos entornos (los más usados y/o conocidos):

• Ruby: este lenguaje dio el salto al desarrollo web con su framework denominado on Rails. Es un sistema que ayuda al desarrollador para realizar un sitio web dinámico que requiera de acceso a datos y características típicas de los CMS, foros, webmails, etc.
• Java: el desarrollo de aplicaciones empresariales siempre ha estado marcado por Java. En el desarrollo web, Java usa tanto servlets como JSP. Un entorno muy conocido que se comenzó a usar en el patrón MVC con Java fue Struts. Se considera de los primeros. Luego hay otros que se consideran más completos, como por ejemplo Spring.
• PHP: en PHP realmente no haría falta ningún entorno en sí, pero ciertamente, para marcar el camino de un desarrollo grande para una empresa, debería de existir un método que permita a varios programadores no realizar código difícil de mantener. En este sentido, hay entornos como CakePHP o como Symfony, que facilitan pensar todos los aspectos relativos al desarrollo de una aplicación web grande y pone en manifiesto pocos patrones de desarrollo a seguir. En BosqueViejo tenemos nuestro propio framework para desarrollo de CRM: Oak Framework.
• Erlang: dispone también de ErlyWeb que al igual que los frameworks de los demás lenguajes, permite el desarrollo rápido de elementos basados en base de datos y similares.
• Python: es un lenguaje que se ha basado, para la web, casi siempre en la existencia de Zope para el desarrollo de aplicaciones (o productos) de forma fácil y rápida. No obstante, hay mucha gente que comienza a usar otros frameworks como Django.
• Groovy: este lenguaje, concebido como lenguaje embebido para Java, se ha comenzado a usar como simplificación del mismo y uso en sistemas de scripting y con el framework Grails en la web.
• Perl: este lenguaje script, de los más rápidos en ejecución y con una sintaxis que, hace tiempo, se ganó el apodo de write-only, tiene también su framework para el desarrollo web, cuyo nombre es Catalyst, y se encuentra disponible en su propio CPAN.

Cada uno de estos lenguajes tiene su potencial y es más indicado para un tipo de desarrollo que los otros. Hay que tener en cuenta que, los lenguajes más estructurados (Python y Java, por ejemplo) tienen la propiedad de poder estructurar de forma correcta el código, con lo que son más indicados para proyectos grandes y muy configurables.

En cambio, para proyectos pequeños, el uso de otros lenguajes rápidos como Groovy, PHP, Perl o Ruby, está mejor indicado puesto que, aunque son lenguajes perfectamente válidos para desarrollos grandes, su potencia radica en la posibilidad de escribir código rápido y, muchas veces, de cualquier forma, y terminan convirtiéndose en códigos difíciles de mantener.

Sin embargo, hay muchos proyectos desarrollados en estos lenguajes que han demostrado que, con un poco de organización y una política algo estricta a la hora de escribir código, permiten al equipo de desarrollo mantener y hacer que un sistema web se haga grande a lo largo del tiempo, como han sido: Wordpress, Drupal, eGroupware, LiveJournal, Radiant, etc.

Otros lenguajes de alta escalabilidad, como Erlang, que permite el desarrollo de aplicaciones en varios nodos (equipos) de forma fácil, sin necesidad de emplear aplicaciones y servidores extra, que al fin y al cabo, resultan siendo un SPOF más en nuestro sistema.

Como conclusión, podemos sacar que, para la web, cualquier lenguaje es válido, y sus respectivas comunidades no lo demuestran día a día. Si el proyecto que hay que realizar es pequeño, introducirse en Java o Python (a menos que sea Plone y/o Zope) es algo costoso, mientras que si se hace en otro lenguaje de scripting, suele ser más rápido. Pero cabe recordar que, si el proyecto es grande, lo que hay que hacer, es un planteamiento y una línea general, una política de actuación y llevar siempre el código claro y limpio, sobre todo si lo queremos mantener y reutilizar en el futuro.

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.

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.

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.

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

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.

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