Monthly Archives: noviembre 2008

Libros electrónicos

28 noviembre 2008

Hay mucha gente que piensa que este será el punto de partida de un dispositivo que permitirá reducir el consumo de papel, del formato de libro convencional y que, a nivel ecológico, tendrá un gran avance hacia un ecosistema más sostenible.

Otros lo consideran un juguete y algo no muy serio que solo usa un sector muy específico de tecnófilos.

El caso es que este dispositivo se va expandiendo, va ganando adeptos y cada vez más, se adentra en nuestra sociedad por dos motivos: el espacio que ahorra, ya que permite tener una biblioteca completa que ocuparía cientos de metros cuadrados en el tamaño de una libreta de A5; el factor ecológico y de sostenibilidad que propone, ya que son miles de libros que no se imprimirán.

Mucha gente piensa, casi sin haberlos visto, que leer en dispositivos LCD, TFT o similares es algo malo para la vista… y estamos de acuerdo, pero el libro electrónico no está hecho ni con LCD ni con TFT, sino con e-ink (tinta electrónica). El papel electrónico se compone de montones de microcápsulas que contienen partículas negras cargadas negativamente y partículas blancas cargadas positivamente que flotan en un líquido. Cuando quieres mostrar algo en el papel aplicas un impulso negativo a las cápsulas que quieres en blanco y positivo a las que quieres en negro, con lo que las cargas opuestas se atraen y las partículas negras o las blancas suben a la superficie de la cápsula. Y eso es lo que ves. Es tan inofensivo para la vista como leer un periódico directamente.

Cuando el libro electrónico carga una página, automáticamente se pone en stand-by, no consume energía, por lo que ahorra mucha batería y, se calcula que, una batería convencional de libro electrónico puede durar cerca de dos meses, leyendo a una razón de 80 páginas diarias.

Hay muchos modelos en el mercado, Amazon sacó su Kindle, el cual permite conexión telefónica con Amazon para la descarga de libros digitales. Sony ya ha sacado al mercado varios modelos, entre los que destacan el Reader PRS-505 y el Reader PRS-700, este último con pantalla táctil.

Hay otras empresas como iRex que tiene un modelo llamado iLiad, que es bastante completo, teniendo incluso la función de libreta, es decir, pantalla táctil para poder almacenar páginas escritas o modificadas por el usuario.

Hay muchos más modelos y, cada día más, puesto que es un formato y dispositivo que cada vez se verá más integrado en la vida diaria de las personas. Tal y como los sistemas MP3 sustituyeron a los antiguos reproductores de musicasetes y CD portátiles.

Posted in: Libros – 3 Comments

Paradigmas y Patrones

25 noviembre 2008

Al desarrollar un programa, normalmente, el desarrollador elige un paradigma de programación y algún patrón de diseño, ya sea desarrollado por él, por su forma de trabajo a través de los años de experiencia, o tomado de alguna teoría o grupo de trabajo que lo haya conseguido transmitir.

Los grandes paradigmas de programación han llevado a que existan lenguajes de propósito general orientados únicamente a uno de estos paradigmas, o lenguajes que permiten, de una forma muy flexible, usar uno u otro de estos paradigmas.

Así mismo, los patrones de diseño, en sí, no están ligados, de forma estrecha, a un paradigma concreto, con lo que se pueden llevar a cabo, normalmente, en la mayoría de lenguajes de propósito general.

Los paradigmas de programación más importantes son:

  • Spaguetti: este tipo de programación está basada en la consecución de mandatos y órdenes en líneas consecutivas, y una serie de etiquetas o numeración de las mismas líneas, que permitan el salto, en cualquier momento, de una parte del código a otra. Lenguajes de este tipo son: Ensambladores, Basic, Logo y muchos tipos de shell script.
  • Funcional o Procedimental: este tipo de programación se basa en la separación del código en unidades funcionales, normalmente identificadas como verbos o acciones (abrir, cerrar, coge, eliminar, imprime, …). Los lenguajes que hacen uso de este tipo de paradigma son: PHP, Perl, C, Fortran y Pascal, entre otros.
  • Modular: es parecido al tipo anterior, solo que las unidades funcionales se agrupan en módulos, bajo un nombre (o jerarquía de nombres), que le permite tener una organización y uso más lógico, así como seguridad y tipos de optimización al poder incluir solo partes o módulos específicos al código. Los lenguajes que hacen uso de la modularización son: PHP (versión 5.3 y superiores), Perl, Modula-2 y C (con los “namespaces”), entre otros.
  • Orientada a Objetos: este tipo de programación muestra una ideología que se centra en los datos en sí, con una nomenclatura diferente a la funcional, que incluye terminos como: clase, objeto, atributo, método, herencia, etc. Los lenguajes orientados a objetos son: Smalltalk, C++, Java y Python, entre otros.
  • Declarativo: es otra ideología diferente a la funcional, que se usa, sobre todo, en Inteligencia Artificial. Se basa en decir qué es lo que hay que hacer, y no el cómo. En este tipo de lenguajes encajarían todos los de 4ª generación, como puede ser incluso SQL, pero los lenguajes más comunes son: Prolog y Lisp; otros lenguajes que derivan de estos: Scheme y Clips.
  • Orientado a la Concurrencia: en un mundo cada vez más paralelo, donde cada proceso de servidor se ejecuta de forma paralela, pero con necesidad de combinación con otros procesos, nace la necesidad de un paradigma de programación que se base en la concurrencia, más que en los demás aspectos. Con esta visión hay lenguajes como: Haskell, Erlang y Scala, entre otros; que permiten hacer concurrencia de forma más fácil.
  • Orientado a Eventos: este tipo de programación esté íntimamente ligada al lenguaje y entorno en que se programe, ya que los eventos serán dados por el sistema en sí, y su forma de tratarlos y las facilidades que se puedan conseguir vendrán determinadas, en parte, por el lenguaje que se use. Es el caso de la programación de interfaces de usuario con Swing en Java, por ejemplo.

Habiendo elegido el paradigma que más facilite la forma en la que queramos realizar el diseño y codificación, así como el lenguaje, seleccionar un patrón de diseño puede ser el siguiente paso. Patrones hay muchos y sería complicado listarlos todos, pero voy a poner los que más suelo usar y los que he ido aprendiendo… si sabéis alguno más que se me escape, podéis agregarlo como comentario. De todas formas, en la wikipedia se puede tener más información sobre los Patrones de Diseño.

Los tipos de los patrones de diseño son, según la wikipedia:

  • Creacionales: que son los que se usan para la creación o instanciación de datos, objetos o recursos (Factory, Singleton, …).
  • Estructurales: son los que hacen de mediación entre dos partes específicas, como Proxy, que se encarga de agregar seguridad a un código ya programado.
  • Comportamiento: establece la forma de funcionamiento de una parte de código en sí, dando una capa de abstracción al código para su mejor comprensión.
  • Sistema: son patrones de diseño más completos que envuelven a todo el sistema a desarrollar en sí, no solo una parte o un cierto algoritmo. El más característico es el MVC, Modelo-Vista-Controlador, que separa en tres unidades lógicas el desarrollo de la aplicación.

Los patrones de diseño se pueden mezclar entre sí, aunque los de Sistema es más complicado mezclarlos entre sí, sí que pueden ser usados conjuntamente con el resto de patrones, como los creacionales y de estructura, sin problemas.

Posted in: programación – 1 Comment

Erlang y Asterisk… ErlAst

20 noviembre 2008

Para permitir una forma más dinámica de programar el plan de marcado (dialplan) de Asterisk, se emplea lo que se conoce como AGI (que viene a ser como el CGI), pero a través de la entrada estándar (stdin) y la salida estándar (stdout).

Como hacer fork dentro de la misma máquina y lanzar los intérpretes de los lenguajes que se suelen usar para AGI (PHP, Perl, Python…) trae consigo una carga considerable a una máquina que puede ya, de por sí, tener bastante carga con Asterisk, la aplicación de dialplan AGI, trae consigo la posibilidad de cambiar el medio de comunicación de entrada y salida estándar, por un socket abierto hacia otro equipo.

Esto trae consigo la ventaja de que, al estar el código de AGI en otra máquina, ya no tiene que lanzarse cada vez una ejecución de intérprete y su consiguiente carga de memoria y tiempo.

Además, otra ventaja, es que el programa externo no tiene que ser lanzado cada vez, sino que puede permanecer en ejecución, con lo que se ahorra aún más.

Prácticamente, todos los lenguajes tienen ya desarrollado un interfaz abierto o libre que maneja lo que se conoce como FastAGI: Java, PHP, Perl, Python… e incluso Erlang.

El lenguaje Erlang me llamó hace poco la atención por ser un lenguaje, al igual que Scala, orientado a la concurrencia, al desarrollo distribuido y tolerante a fallos, por lo que pensé que podría ser un buen lenguaje para desarrollar soluciones que tuviesen que ver con Asterisk, ya que es lo que siempre se busca en las empresas de telecomunicaciones: redundancia, escalabilidad y alta disponibilidad.

El desarrollo de ErlAst está algo abandonado, pero la parte que se refiere a fast_agi es totalmente funcional, por lo que, siguiendo estas líneas, se puede instalar sin problemas en nuestro equipo. Doy por hecho que Erlang se tiene ya instalado y funcionando, al igual que Asterisk. En un sistema Debian o Ubuntu, instalar ambos se hace con apt-get ;-)

Configura ErlAst

Tal y como se dice en la página oficial del proyecto, lo que hay que hacer es bajar la última versión de erlast del repositorio con el siguiente comando:

svn co http://tools.assembla.com/svn/erlast/trunk erlast

NOTA: el código viene con un error que hace que la aplicación de ejemplo no funcione. Tendremos que agregar, antes de trace(true) en el fichero fast_agi.erl el siguiente código:

trace(on) -> trace(true);
trace(off) -> trace(false);

Una vez descargado, tendremos el directorio erlast creado. Como la versión de AMI es aún inestable, pasaremos a compilar y usar solo la parte de fast_agi:

cd erlast
make
cd lib/fast_agi/
make

NOTA: el primer make originará fallos, puesto que AMI no está aún terminado de implementar por el autor.

Escribimos un fichero de configuración dentro del directorio ebin, que se llame fast_agi_conf.config con el siguiente contenido:

[
    {fast_agi, [
        {port,4573},
        {opts, [
            {ip, {192,168,1,1}}
        ]}
    ]}
].

NOTA: configurar de forma correcta la IP que se ponga en este fichero, puesto que si la IP no corresponde con la de nuestro equipo, el sistema devolverá un error y no arrancará.

Por último, probamos que todo funcione, desde dentro del mismo directorio ebin ejecutamos:

$ erl -config fast_agi_conf
Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [kernel-poll:false]

Eshell V5.5.5  (abort with ^G)
1> application:start(fast_agi).
ok

Configura Asterisk

En este momento ya tendremos lanzada la aplicación y en escucha a través del puerto 4573, con lo que si configuramos un asterisk con el siguiente extensions.conf, debería de reproducirnos el audio de demo de asterisk (en caso de que esté) y colgar:

exten => 123,1,AGI(agi://192.168.1.1:4573/test_agi/test)
exten => 123,n,HangUp

Lanza una llamada contra asterisk al número 123 y debería de reproducirse el audio.

Conclusión

Visto esto, se puede combinar con el almacenamiento redundante y distribuido de mnesia para conseguir que la llamada a AGI sea tolerante a fallos y se tenga memoria del flujo de llamada, lo cual daría mucho juego y unas aplicaciones mucho más fiables.

Posted in: programación – Comentarios desactivados

Menos SPAM, ¿los spammers están en crisis?

14 noviembre 2008

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?

Posted in: Noticias – 1 Comment

Debate sobre la Ingeniería Informática

10 noviembre 2008

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 sin 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.

Posted in: Opinión – 3 Comments

Documentación de Proyectos Libres

6 noviembre 2008

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.

Posted in: Opinión – Comentarios desactivados

Programación Rápida de Webs

3 noviembre 2008

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 nos 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.

Posted in: programación – 1 Comment