Category Archives: programación

Noticias acerca de Programación. Son temas generales que pueden tener en cuenta a varios lenguajes, ser sobre metodología, algoritmia y/o librerías multiplataforma y portadas a muchos lenguajes.

Lenguajes de Programación

2 febrero 2009

Revisando los tipos de lenguajes de programación existentes, llego a esta clasificación de los mismos:

  • Lenguajes imperativos
    • Lenguajes Spaguetti
    • Lenguajes Estructurados
    • Lenguajes Modulares
    • Lenguajes Orientados a Objetos
  • Lenguajes lógicos
    • Lenguajes declarativos
    • Lenguajes funcionales

Todos estos lenguajes de programación obedecen a una necesidad y/o ideología subyacente, que motivó el desarrollo del lenguaje con la metodología y sintaxis específica. A continuación describiré algo más en detalle cada uno de los anteriores.

Lenguajes Spaguetti

Fueron los primeros lenguajes de programación. El lenguaje máquina y posterior ensamblador, se basaba en la programación de instrucciones, una a una y comandos de salto ante ciertos estados del procesador. Con ello se conseguía un código entrelazado en saltos de línea a línea y parte a parte, consiguiendo un spaguetti bien entrelazado en proyectos grandes.

Lenguajes como Basic, posteriormente, siguieron esta forma de programación.

Lenguajes Estructurados

Los lenguajes estructurados que surgieron después (Fortran, C, Pascal, …) se basan en la estructuración del código en forma de procedimientos, funciones o subrutinas. Cada programa está formado por un conjunto de estas estructuras que son llamadas entre sí, tienen un nombre diferenciado y una funcionalidad bien conocida que se basa en los parámetros de entrada, pudiendo retornar valores en su retorno.

Lenguajes Modulares

Es un nivel más en los lenguajes estructurados. Se basa en la agrupación de los procedimientos, funciones y/o subrutinas en bloques, paquetes o módulos, de modo que queden bien organizados. Lenguajes como Java, Perl, Ruby o Modula-2, hacen uso de esta metodología.

Lenguajes Orientados a Objetos

El enfoque de este paradigma se basa en darle más importancia a los datos que a las acciones en sí. Es decir, en los modelos anteriores, la separación se hacía por unidades funcionales (verbos). La programación orientada a objetos se realiza mediante la organización del código mediante el conjunto de datos con sus funciones afines (objetos = datos + funciones).

Lenguajes que hacen uso de esta metodología son: Smalltalk, Ruby, C++, Java y Python, entre otros.

Lenguajes Declarativos

Los lenguajes declarativos se basan en una especificación lógica de lo que la máquina debe de hacer. Pero sin entrar en detalle en el cómo debe de hacerlo. Es un lenguaje más cercano al lenguaje natural que al lenguaje máquina, que se basa en la entrada de predicados para, a través de inferencia, llegar a un resultado.

Lenguajes que se basan en este paradigma son Lisp, Scheme, Clips y Prolog, entre otros.

Lenguajes Funcionales

Los lenguajes funcionales son como los declarativos, pero en lugar de predicados, trabajan con funciones matemáticas, es decir, carecen de máquina de inferencia y la definición de programas se basa en la especificación matemática del programa que se quiere conseguir.

Lenguajes que se basan en este paradigma son Haskell y Erlang, principalmente.

Otros paradigmas compartidos

Las necesidades de los desarrolladores cambia según el sector en que se trabaje, la época, la empresa… cualquier factor puede influir para tomar como determinación el uso de una tecnología y/o metodología específica y, dentro de la elección tomada, puede permutarse incluso hasta llegara a alcanzar un nuevo paradigma.

Estos paradigmas, se incluyen dentro de lenguajes ya creados y solo requieren de un uso específico de un tipo de lenguajes para conseguir el propósito deseado.

Los paradigmas que obedecen a esta forma son:

  • Programación Orientada a Eventos
  • Programación Orientada a Aspectos
  • Programación Concurrente

Estos paradigmas pueden ser integrados en cualquiera (o la mayoría) de los lenguajes citados anteriormente. Dejo pendiente el comentar estos paradigmas de programación.

Also posted in Desarrollo de Software – Comentarios desactivados

Lenguajes esotéricos

16 enero 2009

Otro viernes… las oficinas a medio gas y toca trabajar… me da por buscar información, ahora que aprendo más sobre Ruby y Erlang y, topo con un lenguaje llamado COW. Un lenguaje esotérico.

Ves cosas como la serie de fibonacci:

MoO
moO
MoO
mOo
[[ main loop ]]
MOO
[[ print first number ]]
OOM
[[ temp copy of first number ]]
MMM
moO
moO
MMM
mOo
mOo
[[ store second number off in the first position now ]]
moO
MMM
mOo
MMM
[[ move back to temp number ]]
moO
moO
[[ use temp to add to first and store in second in loop ]]
MOO
MOo
mOo
MoO
moO
moo
mOo
mOo
moo

Supongo que el autor de este lenguaje llegaría hasta el punto de decir si hasta las vacas pueden programar… y mira por donde, ahora sí :-D Ahora tenemos un sistema de accesibilidad para que las vacas, con sus gemidos, puedan trabajar por nosotros :-P

Pero realmente, este es uno de los desafíos que se ponen algunos programadores, diseñar un lenguaje Turing completo que desafíen el ingenio, la creatividad y sentido del humor de todos los programadores en general.

Aquí dejo un enlace a más lenguajes de programación esotéricos.

Comentarios desactivados

Ruby… esa pequeña joya

13 enero 2009

El lenguaje de programación Ruby, creado por Yukihiro Matsumoto (a.k.a. Matz), fue ideado para ser un lenguaje que simplificara las actividades diarias y necesidades de programación de su creador, al igual que Perl (la otra joya) fuera creada por Larry Wall para cubrir sus necesidades como administrador de sistemas, Matz necesitaba un lenguaje que fuese igual o más potente que Perl, y con igual o mejor implementación de orientación a objetos que Python.

En su trabajo, Matz, usaba Perl, mientras desarrollaba Ruby en paralelo, hasta que fue lo suficientemente bueno como para reemplazarlo. El nombre de Ruby, por tanto, está motivado por la similitud, en simbología, con Perl. La primera liberación fue en 1995.

En Japón, Ruby ha llegado a tener más popularidad que Python. Los adeptos de Ruby, así como su creador sostienen que Ruby fue diseñado para ser más fácil, y además divertido.

Viendo muchas de sus librerías, y sus similitudes con las librerías de Perl, se entiende lo que se menciona acerca del paso de Perl a Ruby, al igual que la sintaxis, en lo que se refiere a expresiones regulares, la declaración y uso de datos de tipo array y hash. No obstante, Ruby tiene una característica básica, y es que, todos sus datos son objetos, es decir, lo que en Perl serían datos scalar, aquí son todos objetos.

Podría seguir con más parecidos, trozos de código y explicando cómo se programa en este lenguaje que cada vez me atrae más… pero casi prefiero que lo leáis en sus sitios habituales de referencia:

http://www.ruby-doc.org/

Espero que lo disfrutéis.

Comentarios desactivados

Gráfico Burndown (más de Scrum)

17 diciembre 2008

En estos días, después de haber pasado más de 24 horas en el último Sprint, sin descansar, donde comenté la experiencia de haber usado Scrum y XP en otro artículo, volvemos a la carga.

Esta vez, con dos semanas de Sprint, bastante más tiempo, podemos realizar algunas técnicas más para poder medir cuánto vamos a tardar realmente en terminar el proyecto que tenemos entre manos.

Para esto, hemos hecho uso de un gráfico burndown.

Burndown

El gráfico de burndown se caracteriza por tener en su eje X el tiempo, solo los días laborables que se vayan a trabajar (sino el gráfico saldría algo extraño) y en el eje Y los puntos de tarea que se van a completar en el sprint.

Pila de Producto, Pila de Sprint y Puntos de Tarea

La pila de producto es la cantidad de características que nos piden que incorporemos a un producto software. Estas tareas son funcionales, generalmente.

La pila de sprint es una primera criba que se toma de la lista total de características, a modo de poder desarrollar una versión 0.1. Esto se realiza para que, al final del sprint, que no debe de ser un período de tiempo muy prolongado, se tenga algo palpable para el cliente (o dueño de producto) y pueda replantearse el resto de peticiones en función de lo que está viendo.

Los puntos de tarea son, en sí, la dificultad y el tiempo que se puede llegar a invertir en la tarea en sí. Es una unidad de medida relativa que no implica en sí tiempo, pero está bastante ligada a él.

Por ejemplo, si hacer un alta de cliente implica una sola consulta a base de datos y retornar el valor de resultado, esa tarea podemos estimar que tiene 1 punto. El caso de la modificación, implicaría tomar los datos, mostrarlos, tomar los cambios y hacerlos efectivos. Esa tarea se puede estimar en 2 ó 3 puntos. Ahora, hacer el balance de todos los clientes dados de alta y los ingresos que tuvieron en el año pasado, todo ello paginado… puede ser una tarea con una puntuación de 10, relativamente con respecto a las anteriores.

Datos en el gráfico de Burndown

El gráfico se traza para cada sprint. Se estima el tiempo que se puede o quiere tardar en realizar una serie de características. Al comenzar, el primer sprint, no se sabe la velocidad del grupo, realmente, por lo que se puede comenzar sin estimación precisa. Esto se va ajustando con el tiempo.

En principio, se comienza el trabajo, se comienzan a realizar tareas.

Al día siguiente, se hace revisión de las tareas acabadas y se apunta en el gráfico el día anterior y los puntos que se avanzó. El gráfico, al crearlo, se suele trazar una línea que cubre la diagonal de la esquina superior izquierda hasta la esquina inferior derecha. Si los puntos van cayendo sobre la línea, ya sabemos lo que se va a ir tardando en realizar el proyecto.

En caso de que los puntos vayan cayendo en el rectángulo superior, eso será indicio de que hay que eliminar historias. Si se mantiene siempre en el bloque inferior, se pueden agregar más historias.

Conclusiones

Después de un par de jornadas, se puede ver la velocidad del equipo y se tiene una percepción real de lo que se hace, lo que se tarda y las tareas que hay que ir acelerando o postergando para llegar a la fecha, sin necesidad de estar cerca de la fecha de entrega. Es, sin duda, uno de los mejores métodos de estimación de tiempos a corto plazo… para el sprint.

Hablaré en los próximos artículos sobre las estimaciones a largo plazo, gestión de hitos y más sobre la pila de producto.

Also posted in Desarrollo de Software – 1 comentario

Algoritmos heurísticos y algoritmos voraces

13 diciembre 2008

Realizando una práctica de la asignatura de programación 3, de la Universidad Nacional de Educación a Distancia (UNED), he podido comprobar la diferencia, en coste computacional y rendimiento, que supone realizar un algoritmo mediante un algoritmo heurístico, como puede ser el de vuelta atrás (backtracking) y un algoritmo voraz (reducción).

El problema consiste en resolver, dar las posibles soluciones, de un tablero de shikaku. Se trata de un juego japonés que consiste en resolver un tablero, con unos números, mediante el uso de rectángulos que tengan un área igual al número que encierran, no pudiendo solaparse. Es decir, un número 4 en el tablero, puede formar rectángulos de 1×4, 2×2 y 4×1, y mientras tenga al número en cualquiera de las casillas que ocupa, es una combinación correcta. Un ejemplo gráfico:

Tablero de Shikaku

Al principio, la solución más fácil, consiste en tomar todas las posibles combinaciones de los rectángulos, e ir probando combinaciones hasta dar con todas las combinaciones de solución. El problema, es que el costo computacional de la solución es muy alto cuantos más números haya y, sobre todo, cuantos más números con muchas combinaciones existan. Esto supone un coste exponencial e imposible de calcular en muchos casos.

Una solución, es el uso de un algoritmo voraz de reducción, que elimine muchas de las combinaciones posibles, antes de la aplicación de la solución. En sí no es complicado, ya que solo consta de tomar una de las combinaciones y comprobar si es posible su aplicación en el tablero, respecto a los números que hay colocados y que no se salga del propio tablero. Esto reduce mucho las probabilidades, pero aún no lo suficiente.

Otra reducción que se puede llevar a cabo es, si una combinación no es posible de encajarla en el tablero con ninguna de las combinaciones posibles de otro número, entonces esa combinación no es posible. Se puede eliminar.

Estas reducciones suelen ser rápidas, puesto que su coste computacional es muy bajo, y realizan una criba de elementos muy alta, de forma que rebajan mucho el coste que supondría ejecutar el algoritmo de vuelta atrás sin reducciones.

En la práctica, programado en Java y con tableros de la página de Nikoli, he comprobado que no se tarda más de 6 segundos en resolver los tableros más complejos, mientras que, sin reducciones, podría tardarse horas.

Por lo tanto, la elección del algoritmo sí importa.

Also posted in Desarrollo de Software – 2 comentarios

Scrum y XP en la práctica

10 diciembre 2008

Hace un tiempo escribí sobre Srum y XP, en ese mismo artículo, comentaba que estas técnicas, tanto Scrum como XP, eran dos técnicas que me gustaban mucho y que probaría en un futuro… bueno, pues ese futuro ya es presente :-)

La semana pasada, tuvimos, en la empresa en que trabajo, la presión de entregar un proyecto de forma rápida. Pensé que, en estos casos, lo que más se necesita es, como no, la organización. No se puede estar haciendo una actividad de desarrollo entre varias personas y estar con la cabeza preguntando siempre: ¿qué queda por hacer?; así que, me lancé, cogí dos tacos de post-it, uno de tamaño normal para las partes a desarrollar y otro de tamaño más pequeño, para las tareas que hay dentro de cada una de las partes.

Scrum

En la imagen se puede apreciar el cómo quedó la pared de la oficina cuando comenzamos la experiencia. Comento un poco como lo hicimos, aunque la verdad, fue algo muy básico.

Usando Scrum

Lo primero que hicimos fue localizar los grandes grupos a desarrollar. En este caso, lo que había que desarrollar, principalmente, era una interfaz web para un cliente específico. Así que nos encargamos de convertir, cada parte importante de la interfaz en un bloque de tareas.

Dentro de cada uno de los bloques (alrededor), se agrupaban las tareas que había que realizar para completar ese bloque.

Los papeles se ordenan de arriba a abajo, según su prioridad, de más alta a más baja, respectivamente. Todos ellos, a su vez, se colocan en la parte izquierda del marco que se vaya a emplear para el proyecto de scrum. La idea es que, cuando una tarea se esté realizando, se pase a una zona central y, cuando haya sido terminada, se pase a la zona derecha. Nosotros usamos la separación física existente entre vidrio y vidrio, considerando la parte central justo la línea de unión entre ambos.

¿En qué beneficia?, pues básicamente en que cuando una tarea se finaliza, todos ven que se ha finalizado y que, cuando alguien no sabe que hacer, se puede levantar y mirar las tareas que hay por realizar.

Cabe señalar dos aspectos muy importantes y a tener muy en cuenta:

  • Hay que definir, y muy bien, lo que significa terminado. Ya que alguien puede considerar una tarea terminada cuando ha terminado de codificarla (sin probarla), mientras que quien la solicita, considera que se termina cuando ya no se debe de tocar más, ha sido comprobada, validada y está lista para producción.
  • El scrum master es la única persona que debe de mover los papeles, así como agregar nuevos o eliminar, según se dé el caso. Esto es para controlar que, realmente, se ha terminado, como se decía antes, la tarea. Además, el hecho de agregar/eliminar tareas es una actividad muy sensible, que no se debe de dejar a todos, puesto que sino, podrían sucederse situaciones indeseables.

Y un poquito de Xtreme programming

Hay otra práctica que realizamos ese mismo día, y es la del empleo del Xtreme Programming, otra vez, a nivel muy básico. En esencia, se trataba de realizar la programación más costosa (o la que se hacía ya con sueño :-P ) entre dos personas, una haciendo de piloto (al teclado) y otra haciendo de navegante (cabeza pensante).

Los beneficios de esta técnica fueron la velocidad a la hora de desarrollar ciertas partes, puesto que la presión que ejerce el navegante al piloto y la dinámica que se crea, hace que el desarrollo carezca de partes de inactividad y cada tarea se acabe antes.

Algunas conclusiones

Puedo decir que la valoración acerca de estas técnicas, en sus inicios dentro de la empresa, han sido muy positivas, llegándose a conseguir los objetivos deseados, por lo que seguiremos empleando dichas técnicas, así como implementando cada una de ellas de forma más completa para ganar en eficiencia y conseguir que los proyectos se puedan medir de forma más precisa en el tiempo.

Pero de eso ya contaré más adelante… :-)

Also posted in Desarrollo de Software – 2 comentarios

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.

1 comentario

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.

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.

1 comentario

Serialización de Información

16 octubre 2008

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.

Comentarios desactivados
« Older posts
Newer posts »