Monthly Archives: marzo 2009

CASE: escribiendo código más fácilmente

27 marzo 2009

Las herramientas CASE (Computer Aided Software Engineering, Ingeniería del Software Asistida por Ordenador), son herramientas diseñadas para dar soporte al programador a través de una interfaz intuitiva y gráfica que le permita, mediante el posicionamiento de objetos gráficos concretos, relacionados entre sí siguiendo una nomenclatura específica, desarrollar la base de un programa automáticamente.

La programación siempre ha estado respaldada por el diseño de gráficos que, de un solo vistazo, den una imagen gráfica de lo que hace un programa, como se estructuran los datos que maneja, o cómo se organiza el código que se está escribiendo. Esto se hace mediante diagramas como los de flujo de datos, organigramas, entidad/relación, jackson, OMT y UML, entre otros.

Actualmente, no hay proyecto de grandes dimensiones que no se desarrolle usando metodologías que no estén respaldadas por diagramas como los de UML. La mayoría de proyectos que se subcontratan actualmente, por consultoras, se desarrollan, principalmente, en Java.

Esto es debido a varios factores, el principal, es que los sistemas heterogéneos a los que se enfrentan los consultores, les hacen decantarse por entornos multiplataforma, como Java, para facilitar su tarea, otro motivo es que Java ha crecido de forma considerable y tiene multitud de herramientas para el desarrollo de aplicaciones de negocio.

A día de hoy, por tanto, la mayoría de herramientas CASE se basan en el uso de diagramas UML que permitan especificar una organización del código, un comportamiento, con definición de casos de uso y secuencias, para después autogenerar la estructura o esqueleto base y escribir el resto del código, dentro de los métodos que quedasen vacíos después de la autogeneración.

Las herramientas CASE más usadas en el entorno laboral y las que hay disponibles de forma libre (algunas no gratuitas) son las siguientes:

  • Visual Paradigm: esta empresa cubre con su oferta de herramientas la generación de casi todo el código y asistentes para el mantenimiento del mismo código una vez acabado, para seguir completándolo, corrigiéndolo y adaptándolo a las nuevas necesidades del cliente. Es una solución no libre y de pago, pero muy completa y aconsejable.
  • ArgoUML: de las herramientas libres que he probado, esta es una de las más completas. El desarrollo a nivel individual es muy potente y permite desarrollar de forma muy rápida una gran cantidad de diagramas UML que después se pueden autoconvertir a Java, C#, C++, Base de Datos…
  • Innovator: este software incluye características para diseño y desarrollo de software de lógica de negocio, basado en SOA y BPM. Es de pago, pero cuenta con una gran cantidad de características.
  • Umbrello: este proyecto, lo usé durante un tiempo, antes de decantarme por ArgoUML y, solo decir que, aunque es libre y tiene bastante buena pinta, el hecho de que haya quedado descontinuado (no se ha liberado ninguna nueva versión desde finales de 2007), tenía bastantes fallos.

Oracle y Sybase también tienen sus entornos para desarrollo rápido de aplicaciones, solo que son de pago y no es fácil acceder a una copia para probarlos, por lo que no los comento en la lista anterior.

Para más información puede ver la página de la wikipedia sobre CASE, la cual completa con algunos conceptos más, y mucho más software.

Posted in: Noticias – Comentarios desactivados

La liebre y la tortuga

24 marzo 2009

En este cuento voy a intentar explicar lo que significa programar rápido y lo que significa programar de forma ágil. La primera forma sería la que se considera comenzar lo antes posible, para terminar lo antes posible… pero ciertamente, sin planificación, dar palos de ciego a ciertos niveles de implementación, es más lento que planificar la estrategia de desarrollo a priori. Vamos a verlo con el cuento de…

La liebre y la tortuga

En Silicon Valley, había un programador tan rápido que podía escribir cientos y miles de líneas de código en cuestión de pocas horas, trabajaba rápidamente y, por ello, era conocido como la liebre. Aunque era un poco alocado, se lanzaba directamente a programar y no planificaba bien los proyectos.

No obstante, todos lo admiraban por lo rápido que hacía aparecer código en tan poco tiempo.

Por otro lado, estaba otro programador, algo más lento, que planificaba en papel y lentamente todos sus desarrollos, con lo que en un día obtenía muy pocas líneas de código. Este programador era conocido, por esto mismo, como la tortuga.

La liebre y la tortuga trabajaban en la misma empresa y, ante la fuerza que la admiración del resto ejercía sobre el primero, por su característica totalmente opuesta a la del segundo, la liebre instigaba e intentaba siempre perjudicar a la tortuga.

En la sala de trabajo, un día, cuando la tortuga ya se cansó de tanta hostilidad, aprovechó la oferta de un trabajo de programación importante, con un nivel de desarrollo importante y grande, para retar a la liebre: tú que eres tan rápido, te desafío a desarrollar este programa más rápido que yo.

Toda la sala quedó estupefacta, salvo el director de proyectos, que disimuladamente sonrió, agregando: sería interesante verlo. A lo que el resto de la sala agregó más risas.

El director de proyecto se dirigió a la liebre y le preguntó: ¿serías capaz de desarrollar este proyecto en menos tiempo que la tortuga? A lo que la liebre respondió sin dudar: ¡claro que sí! Pues os doy a ambos una semana para el desarrollo del proyecto, quien antes lo termine cumpliendo con los requisitos especificados, será el ganador.

La liebre comenzó a reir, aceptó el trato, al igual que la tortuga y fue a seguir riendo con sus compañeros durante largo rato mientras la tortuga marchó a su puesto de trabajo. La tortuga analizó el proyecto e inmediatamente localizó una serie de patrones claros que seguir, tomó los requisitos y trazó los diagramas que le harían cumplir con los mismos de la mejor forma, para seguir con una planificación ajustada al tiempo que tenía para cumplir con el proyecto. Se puso manos a la obra y comenzó el diseño.

Mientras tanto la liebre, se tomaba su tiempo y, mientras hablaba con sus compañeros decía: si ya sé cómo lo voy a hacer, es una chorrada de proyecto, ¡muy fácil!

En el segundo día, la tortuga terminaba su diseño con diagramas de UML, marcaba la división y los patrones que integrarían cada una de las clases, así cómo los detalles del diseño de interfaz y otras características a tener en cuenta en diagramas de secuencia.

Al tercer día, la liebre comenzó a codificar, en poco tiempo, tenía un trozo de código que cumplía los primeros requisitos y reía a gusto creyendo saber que conseguiría su propósito. Mientras, la tortuga, acababa de sentar el esquema de clases y la estructura básica, la arquitectura de soporte y preparaba todo para comenzar la codificación al día siguiente.

En el cuarto día, la liebre comenzó a encontrarse los primeros problemas, algunos requisitos chocaban directamente con muchas de las partes ya desarrolladas y en funcionamiento, así como datos ya implementados en la base de datos, con lo que se veía obligada a rehacer la estructura de datos, eliminar todo el código que no le servía y volver a escribir código nuevo. La tortuga comenzaba la codificación con la estructura de clases autogenerada por las herramientas CASE que usaba y trazaba las líneas de código de acceso a datos y lógica de negocio, escribía las pruebas unitarias para asegurar que todo salía bien y seguía adelante.

El quinto día, para la liebre, comenzaba el stress, la desesperación, se acerca el final del proyecto, aún no están todos los requisitos y se han vuelto a encontrar problemas. Como no hay una visión global, no sabe cuantos problemas más puede llegar a encontrar y, para los ya encontrados, la recodificación es algo pesada. Con lo que parece que solo lleva, de forma constante la mitad del proyecto. Por otro lado, la tortuga ha terminado la parte de lógica de negocio y manejo de datos, así como la parte de seguridad y acceso, el controlador, con lo que solo le restan las vistas, con las pruebas funcionales para acabar el proyecto.

El sexto día, cuando se había previsto la entrega del proyecto, la liebre había pasado toda la noche en su puesto de trabajo, intentando, con chapuzas, terminar a tiempo el proyecto, haciéndolo de forma muy deficiente y sin probarlo. Sin embargo, la tortuga, ya acababa la vista, haciendo siempre la ejecución de las pruebas de regresión para probar la integración de cada una de las partes, junto con las funcionalidades pedidas y el entorno en sí.

A la entrega del proyecto, la liebre presentó un proyecto con fallos, que no terminaba de funcionar y que tenía implementados los requisitos solicitados de forma dudosa, mientras que la tortuga entregaba un proyecto bien pensado, con un resultado limpio y funcional.

Ante los resultados, el director de proyectos se dirigió a la liebre y le dijo: no es cierto que es más rápido quien más rápido programa, sino quien, con menos código y menos trabajo, consigue hacer lo mismo en menos tiempo; y con ello, la tortuga ha demostrado, que es más rápido que la liebre.

Conclusión: usar metodologías ágiles acelera realmente el desarrollo, porque optimiza el proceso de creación.

Posted in: Desarrollo de Software – 7 Comments

Reia: Ruby sobre Erlang

18 marzo 2009

Al igual que en Java se pueden ejecutar lenguajes scripting tales como Ruby (JRuby), Python (Jython), Groovy… es posible hacer esto mismo en otros lenguajes, como C y Erlang.

Erlang, es un lenguaje funcional, del que ya hablé en otro artículo, lo cual tiene sus ventajas para ciertos algoritmos… pero también sus inconvenientes para otro tipo de algoritmos, por lo que el poder combinarlo con lenguajes de scripting tan potentes como Ruby, es una forma de poder acelerar nuestros desarrollos… allanamos el camino quitando todas las piedras :-)

El sistema que hace esto es Reia. Este sistema, escrito en erlang y reia (casi la misma sintaxis que Ruby), da las capacidades de un lenguaje dinámico sobre un lenguaje funcional, dando la posibilidad de escribir código tanto en erlang como en reia e ir alternando. El resultado siguen siendo los archivos beam que la máquina de Erlang interpreta y ejecuta sin problemas.

Posted in: Desarrollo de Software – Comentarios desactivados

MVCC: Control de Concurrencia para Múltiples Versiones de PostgreSQL

13 marzo 2009

El sistema de base de datos PostgreSQL integra un sistema de control de concurrencia para múltiples versiones, en principio. Esto no es más que un sistema que se encarga de mantener copias sobre los datos de forma paralela, para acelerar el sistema de escritura de datos a disco duro, haciendo un control de concurrencia entre las distintas versiones que se van escribiendo.

El problema que intenta solucionar este sistema es el siguiente. Imagina que tenemos un sistema que hace múltiples escrituras y lecturas de una base de datos. No es difícil, seguro que conoces cientos de sistemas que lo hacen. Ahora, ten en cuenta que, los accesos a base de datos, depende para qué, realizan ciertos bloqueos, para asegurarse de que la información a modificar o a leer (incluso) no es modificada por nadie, hasta que termine su actividad.

En MySQL, por ejemplo, existen distintos tipos de bloqueos, muchos de ellos automáticos, que hacen el bloqueo de una tabla completa, o de ciertas partes específicas, al hacer una actividad de modificación, o un bloqueo compartido, para hacer actividades de lectura (solo bloquea en este caso a los que intentan escribir).

Pero en tema de índices, hay muchos SGBD que usan sistemas de índices que al actualizarse, se bloquean completamente, dejando, no solo las escrituras bloqueadas, sino también las lecturas, creando un lag de acceso a los datos.

Interbase fue la primera base de datos que eliminó la contención, los deadlocks y garantizaba transacciones ACID mediante el sistema MVCC. La idea es: no actualizar ni eliminar nunca una fila del disco. Si deseas actualizar, se agrega una nueva fila con la misma clave primaria, la cual oculta la antigua fila. Si deseas eliminar, agrega una nueva fila que etiqueta la clave primaria como eliminada, la cual oculta la antigua fila.

Las viejas filas no eran nunca actualizadas, así que no era necesario implementar ningún sistema de bloqueo y la contención (o espera) mágicamente desapareció.

El sistema, no obstante, tiene pequeños defectos: usa más espacio de disco y puede ser algo más lento a la hora de leer datos. La buena noticia es que los datos se pueden respaldar (realizarse un backup) en cualquier momento sin bloquear el sistema.

En MySQL, los tipos de tablas Falcon (a partir de la versión 6.0) e InnoDB (antes de la 6.0), implementan este sistema para las actualizaciones (updates) usando bloqueo a nivel de fila, lo cual puede causar un tiempo de espera para otros procesos (contención).

En PostgreSQL se usa el comando VACUUM para actualizar las base de datos, es decir, implementar las transacciones agregadas al final en lugar de a las que reemplazan y eliminar las tuplas marcadas para reclamar más espacio en disco. Esta operación demora, pero hace que la base de datos pase de un consumo alto de disco duro, al ajustado que debe de ser, antes de la próxima sesión crítica :-)

Hay otras bases de datos que también implementan Multiversion concurrency control, tal y como menciona la wikipedia, tales como:

  • Berkeley DB: que es una base de datos a nivel de fichero, como puede ser SQLite, pero sin uso del lenguaje SQL.
  • CouchDB: de la cual ya comenté algunas cosas en otro artículo.
  • Oracle 7: y superiores.
  • Microsoft SQL Server 2005: y superiores. El soporte es opcional, se pueden configurar los niveles de aislamiento (isolation) para poder usar MVCC o no.
  • MySQL: a través de InnoDB o Falcon, pero se usa nivel de bloqueo por fila, en lugar de snapshot.

Más información:

Posted in: Base de Datos – 1 Comment

ETL: Extracción, Transformación y Carga

12 marzo 2009

Este término, ETL, se acuña a la mayoría de transformaciones de datos que deben de realizar empresas para compatibilizar sus datos con los de sus proveedores y/o clientes.

Este sistema se basa en los tres pasos de los que salen sus siglas:

  • Extration: la extracción se refiere a obtener datos. Si tenemos una fuente de datos como puede ser un fichero CSV, o un fichero Excel (lo más típico en muchas empresas), el trabajo comienza por configurar ese fichero como origen de datos. También hay posibilidad, según la complejidad del sistema o lo avezado del programador, de poner otros orígenes de datos más originales, como son: base de datos relacionales, jerárquicas (o directorios), conjuntos de ficheros, conexiones HTTP, FTP, POP3 o IMAP, etc.
  • Transformation: la transformación se refiere a, con los datos tomados de las fuentes específicas, realizar las transformaciones oportunas para obtener los datos que se requieren. Estas transformaciones se pueden realizar en múltiples lenguajes de script. Normalmente, en muchas plataformas, se usan lenguajes como JavaScript, otros tienen una interfaz gráfica desde la que se configuran las transformaciones.
  • Loading: la carga de datos consiste en tomar los datos procesados, una vez terminada la operación de transformación, y depositarlos donde se indique, ya sea una base de datos, un conjunto de ficheros o un fichero, en el directorio especificado o enviado a través de FTP, HTTP POST o SMTP… etc.

El sistema es simple y, por lo tanto, como todo lo simple, tiene una gran cantidad de aplicaciones que facilitan, entre otras cosas:

  • Automatización de tarifas, ya que si el proveedor nos envía sus tarifas en formato de fichero o en un email formateado de alguna forma, se pueden obtener esos datos y cargarlos en nuestro sistema de base de datos, hacer las transformaciones precisas e, incluso, enviar los resultados a nuestros clientes en formato PDF por email.
  • Comunicación con el cliente, en modo de que, tomando los datos de nuestras base de datos con referencia a saldos, ingresos, tarifas o cualquier información que interese al cliente, pueden ser también ofertas o productos marcados como rebajados, se envíe esta información en formato PDF con una presentación predefinida a cada uno de nuestros clientes.
  • Generación automática de informes. Por supuesto, estos ETL que se creen se pueden ejecutar cuantas veces se quiera y de forma programada, por lo que, pueden servir para generar, por ejemplo, ficheros HTML estáticos (o incluso con código PHP) que nos muestren información referente a datos de nuestra base de datos.
  • Simplificar datos. Otra forma de usarlos es para crear lo que se conoce como tablas resumen, son tablas que tienen un conjunto de datos representados por la suma de sus campos, como por ejemplo el gasto de un cliente, se puede representar, además de por las líneas de detalle, por una sola tupla que sume todas esas líneas y se presente solo una por mes, e incluso en otra fuente de datos, una por año.

En cuanto más se adentra uno en este mundo de la acumulación e integración de datos, más funcionalidades se le pueden dar a estos sistemas ETL.

Sistemas ETL disponibles hay:

  • Benetl: un software algo simple, escrito en Java, que presenta las posibles transformaciones a través de pantallas. Ofrece bastantes características, pero se ve algo limitado.
  • Barracuda Integrator: tiene la pega, para mi gusto, de que es software propietario y que parece que solo funciona en Windows, pero hay que admitir que tiene buenas características y tiene una serie de presentaciones en las que se puede apreciar su uso, fácil y sencillo, y su potencial. El lenguaje para transformaciones es Visual Basic.
  • Clover ETL: este software es gratuito, no libre y, la parte negativa, es que la interfaz (Clover GUI) es de pago. No obstante, ofrece un sistema intuitivo, ágil y fácil de usar. Se ejecuta sobre varias plataformas, no solo Windows, y el lenguaje de transformación implementado (además de la posibilidad de uso gráfico) es propio: CTL; basado en C.
  • Pentaho Data Integration: es un software libre escrito en Java que permite tomar información de muchos y diversos orígenes de datos, hacer la transformación en lenguajes como Javascript y hacer la “entrega” de datos en distintos destinos.

Por tanto, considero el sistema ETL a tener en cuenta y usar software específico, una forma de acelerar los procesos más pesados en lo que respecta la informatización de tareas en las empresas.

Posted in: Desarrollo de Software – Comentarios desactivados

Pruebas Unitarias

11 marzo 2009

Después de haber estado adentrándome en TDD, muy poco a poco, he visto que el primer paso para hacer más fácil esta doctrina, son las pruebas unitarias.

Las pruebas unitarias son pruebas que se realizan sobre unidades aisladas de código, generalmente objetos, para asegurar que, con unos ciertos valores de entrada, siempre se reciben los mismos valores de salida, o los valores de salida que se esperan.

Para implementar las pruebas, según el lenguaje que se use, existen las siguientes librerías o métodos:

  • Java: el proyecto junit podría considerarse el primero en tener este tipo de framework para realización de pruebas, es de los que más activo tienen su desarrollo, la última versión publicada es de hace unos meses.
  • C: el proyecto CUnit no se actualiza desde 2006, pero parece que el desarrollo quedó muy avanzado y es útil para realizar las pruebas.
  • PHP: el proyecto PHPUnit se sigue actualizando y sigue creciendo poco a poco, es bastante maduro y apto para su uso en proyectos de PHP, ya sean de la versión 4 ó 5.
  • Ruby: el nombre del proyecto para ruby, a diferencia del resto, es Test::Unit. En este caso se presenta como un módulo para la realización de pruebas unitarias. Esto es porque en Ruby, no solo están disponibles este tipo de pruebas, sino también pruebas funcionales y de integración… pero eso será otro tema ;-) . El uso del módulo resulta muy similar al resto de frameworks.
  • Python: el proyecto recibe el nombre de PyUnit. Este proyecto hace tiempo que no recibe actualizaciones, pero está en un estado maduro. En su página se dice que se usa para las pruebas de Zope, que es, posiblemente, la mayor pieza de código escrita en python.
  • Perl: en las instalaciones desde CPAN, para instalar módulos de Perl, siempre que se descarga el módulo se ejecutan las pruebas unitarias del mismo, para asegurarse de que se cumplen todas las dependencias y que el código, en ese entorno, reacciona como se espera. El proyecto es PerlUnit.

En la mayoría de casos, cada uno de los proyectos ha sido motivado por junit, con lo que el uso, la ideología y la forma de trabajar es muy similar.

Ahora, después de comentar los proyectos, vamos a comentar lo que realmente importa, las ventajas:

  • Pruebas exhaustivas: el desarrollo de pruebas unitarias tiene como ventaja principal que el código se prueba con datos planteados con detenimiento e intentando cubrir todos los casos posibles, por lo que, es muy útil para descubrir si nuestro software cumple con las especificaciones marcadas (requisitos).
  • Facilita el probar reiteradamente: es decir, si necesitamos realizar pruebas sobre un componente, y ese componente no reacciona como esperamos, en lugar de ir alimentando la entrada de datos cada vez que lo probemos, podemos realizar una batería de pruebas específicamente para él, e incluirlo en la batería de pruebas global.
  • Fase de Calidad: el agregar las pruebas unitarias y ejecutarlas al final, cuando ya se ha terminado de desarrollar el código, no indica que el código sea infalible, pero si las pruebas se han desarrollado cubriendo todos los casos de uso triviales y posibles fallos que se puedan suceder, asegura que el código funcionará como se espera.

Por tanto, el desarrollo de estas pruebas, ya sea a priori, como indica TDD, o a posteriori, como elemento de QA (quality asurance, garantía de calidad), o ambos, resulta una herramienta indispensable que nos puede ahorrar la mayor parte de incidencias que se abren una vez el proyecto está en producción o entregado al cliente.

Posted in: Desarrollo de Software – Comentarios desactivados

Scrum: 7 sprints y 3 proyectos después

6 marzo 2009

Mi última entrada sobre Scrum, hablaba de la implementación del gráfico Burndown, de esto hace ya casi 3 meses, aunque realmente, comenzamos la andadura en algo antes.

En principio, tengo que tener presente que he estado usando algunas otras metodologías, como la Espiral de Boehm y Metrica-3, con lo que, he podido ver y sufrir en mis propias carnes, lo que significa e implica usar una metodología ágil, las ventajas que aporta y lo fáciles que tienden a ser, realmente.

Después de haber realizado siete iteraciones, o sprints, y haber completado tres versiones de un proyecto, ya en producción, y otros tres proyectos más casi en producción, puedo dar mis conclusiones acerca de esta metodología de planificación del desarrollo de software:

  • Scrum permite el desarrollo ágil, esto es, sobre todo, basándonos en un diseño global, y aplicando un poco la metodología de los prototipos evolutivos, conseguir una versión simple, lo más rápidamente posible y que asiente las bases de lo que será la aplicación futura.
  • Las iteraciones cortas, de dos a tres semanas, permiten una supervisión de lo que se va haciendo cada poco tiempo, pudiendo cambiar el rumbo entre sprint y sprint, para adecuarse a los cambios de requisitos funcionales o cambios de prioridad que puedan surgir a lo largo del desarrollo del programa.
  • El gráfico de burn-down es una muy útil herramienta que permite tener una visión dinámica de la velocidad con la que se va produciendo el desarrollo y prepararse, de forma anticipada, a posibles variaciones en las fechas de entrega, ya sea resumiendo o eliminando funcionalidad. En caso positivo, si la marcha del proyecto va más rápido, permite agregar otras tareas no planificadas o prioritarias que se pensaban hacer en futuros sprints.
  • Las tarjetas y el tablero de juego que plantea esta metodología, le da una visión lúdica al trabajo y hace que se convierta en un juego. Las tareas se suceden y, todos saben lo que hace cada cual. Incluso los directivos inmediatamente superiores, en lugar de interrumpir el trabajo, con solo mirar el tablero, ya saben cómo va el proyecto.
  • El hecho de partir tareas, hace que se puedan paralelizar mejor, con lo que aumenta la potencia del trabajo en equipo, pudiendo hacer varias personas tareas sin solaparse. En esto, el trabajo con metodologías de tipo Xtreme Programming, programando por parejas, tareas concretas de corto espacio de tiempo y basándonos en el desarrollo orientado a pruebas hace que sea más óptimo.

A todo esto, sumamos el orgullo de poder presentar los proyectos en la fecha pactada, junto con la sensación de que el trabajo se ha realizado en el tiempo adecuado, sin quemar a nuestro personal, y tenemos una combinación muy óptima.

¿Qué es lo siguiente? En principio me planteo seguir profundizando en las técnicas de Xtreme Programming para integrarlas en el desarrollo de las tareas individuales que propone Scrum, ya que así son completamente compatibles y muy potentes. Así mismo, adentrarme más aún en los frameworks de pruebas unitarias tanto para PHP, como Ruby, Erlang y C. Espero así, conseguir incluso hasta mejores resultados, ya no hablando de tiempos, sino de calidad de producto.

Posted in: Desarrollo de Software – 3 Comments

CouchDB: REST y Base de datos documental

5 marzo 2009

Tal y como comentaba en otro artículo anterior, el sistema REST permite un acceso a los datos basado en la mezcla entre localizaciones de elementos (URL) y verbos de HTTP para indicar lo que se desea hacer con ese elemento. Eso, agregando un almacén de datos que permita albergar elementos y otras características añadidas, nos dan como resultado CouchDB.

El sistema de CouchDB, además de destacar como base de datos documental, cuya definición, extraída de la Wikipedia, viene a decir:

Permiten la indexación a texto completo, y en líneas generales realizar búsquedas más potentes. Tesaurus es un sistema de índices optimizado para este tipo de bases de datos.

Este sistema está altamente indicado para proyectos del tipo:

  • Buscadores, ya que se pueden almacenar webs y después hacer búsquedas en texto de forma eficiente.
  • Bitácoras, blogs, weblogs…; donde el almacenamiento de artículos o extensos textos, puede ser indizado y manejado para realizar las búsquedas.
  • Almacenes de libros, documentos y otros textos que puedan escribirse, sobre todo en formatos de texto plano, como pueden ser HTML, XML (Docbook, DITA, …), SGML, TXT, LaTeX, …

A esto sumamos que el transporte se realiza mediante HTTP, por la convención establecida mediante REST, y tenemos un sistema fácil de implementar y que soporta la carga que supone transmitir todos los documentos almacenados de una forma eficiente.

Cabe destacar que, aunque sea una base de datos documental y esté basada en el almacenamiento de documentos en campos de texto grandes, también se pueden almacenar otros tipos de datos y crear “tablas” a modo de tener un formato relacional, donde el documento juegue el papel principal, claro.

Posted in: Base de Datos – Comentarios desactivados

Debootstrap: probar sin ensuciar

3 marzo 2009

Desde hace tiempo, llevo usando esta herramienta para generar jaulas de modo que pueda probar nuevos sistemas, servidores y/o configuraciones, sin necesidad de desconfigurar mi sistema actual.

El sistema se basa en tener una copia exacta y nueva de un sistema operativo basado en Debian GNU/Linux, que se instala en un directorio específico de nuestro árbol de directorios. El comando que genera la jaula, que tiene el nombre de debootstrap, se encarga de realizar la instalación del sistema a partir del directorio solicitado y con las fuentes solicitadas, es decir, si queremos instalar un woody, sarge, etch, lenny… o un gutsy, hardy, ibex… pues solo tenemos que indicarlo, con la URL de donde conseguir los paquetes y listo.

Por ejemplo, instalar en nuestro directorio /home/usuario/lenny una distribución lenny de Debian, sería hacer lo siguiente:

# debootstrap lenny /home/usuario/lenny http://ftp.rediris.es/debian

Esto tardará unos minutos hasta realizar la instalación completa, ya que se tiene que descargar los paquetes de internet, pero en el momento de finalizar, tendremos un sistema básico de lenny instalado en la ruta indicada.

Para poder usarlo, solo tendremos que hacer lo siguiente:

# mount -t proc proc /home/usuario/lenny/proc
# chroot /home/usuario/lenny

El hecho de montar el directorio proc es para poder tener acceso, desde la jaula, al kernel y poder lanzar servidores como apache, proftpd, postfix o similares.

Una vez dentro, podremos realizar las instalaciones y configuraciones que queramos realizar sin miedo de estar estropeando nuestra configuración normal.

Posted in: seguridad – 1 Comment

PostgreSQL: configuración de acceso

3 marzo 2009

Esto es algo que siempre me toca buscar en Internet, puesto que es algo que hago una vez cada tantos meses, y siempre se me olvida de cómo empezar, así que, para tener la chuleta a mano, he decidido escribir esta entrada que, además de servirme ahora, seguro que me servirá en el futuro para cuando configure más servidores de este tipo.

Aquí os dejo el enlace: PostgreSQL: Instalación, Configuración y Trucos.

Posted in: Base de Datos – 3 Comments