subscripción
¿El núcleo de Linux independiente de SMP?
Noviembre 30th, 2005 - [Enlace local]
Hoy Ubunto Dapper Drake nos tenÃa reservado una sorpresa. Una nueva versión del núcleo, la 2.6.15-5. Hace tiempo que no sigo el desarrollo del núcleo de Linux, pero para mà que esa versión del núcleo está todavÃa en desarrollo. El caso es que ha funcionado después de hacer algunos cambios en los ficheros (por ejemplo, entre otras cosas, no encontraba el firmware de la inalámbrica ipw2100). Una vez que ha arrancado, sin embargo, he encontrado una cosa curiosa. Al principio del dmesg encuentro:
CPU0: Intel(R) Pentium(R) M processor 1500MHz stepping 05 SMP motherboard not detected. Local APIC not detected. Using dummy APIC emulation. Brought up 1 CPUs smp2up: Dynamically optimizing SMP kernel code for UP operation... smp2up: Made 3887 modifications to 'kernel'.
Esto es, al principio intenta detectar si la placa o el procesador es SMP. Si no es asÃ, lo que parece que hace es optimizar el núcleo para que funcione mejor en una única CPU. Al menos eso es lo que creo que hace (por otro lado no parece ni tan complicado ni tan descabellado). Al intentar buscar «smp2up» en google, la página sale vacÃa. ExtrañÃsimo, lo cual da la idea de lo nuevo de esta cuestión. Voy a bucear un poco en el código a ver si lo encuentro y puedo determinar qué hace. Publicaré una actualización cuando lo vea.
Actualización: IncreÃble. He revisado todo el código del núcleo de Linux (incluyendo los parches -git y -mm) y no he encontrado absolutamente ninguna referencia a ese “smp2up”. Estoy realmente intrigado. ¿Alguien puede dar algo de luz?
» Leer más, comentarios, etc...
Mejorando los procesos
Noviembre 30th, 2005 - [Enlace local]
» Leer más, comentarios, etc...
La luna ilumina por igual a culpables e inocentes
Drools I. Introducción a los motores de reglas de negocios.
Noviembre 30th, 2005 - [Enlace local]
Saludos.
Drools (http://drools.org) es una implementación libre de un motor de reglas de negocio compatible con la especificación JSR-94 Rules Engine API (http://www.jcp.org/en/jsr/detail?id=94). ¿Y qué es un motor de reglas de negocio?. Es un componente que, a partir de una información inicial y un conjunto de
reglas, detectas qué reglas deben aplicarse en un instante determinado y cuáles son los resultados de esas reglas.
Uno de los puntos fuertes de los motores de reglas de negocios es que hablan el mismo lenguaje que el dominio del problema. Un ejemplo tÃpico: supongamos que estamos hablando con un cliente para el desarrollo de una tienda virtual.
Algunas de las cosas que nuestro cliente nos pedirÃa pudieran ser:
Si la cuantÃa del pedido supera cierta cantidad o si es un cliente de confianza, entonces se le aplica un descuento. Si se compra más de N productos del mismo tipo se le aplica un descuento. Entre las fechas X e Y, un producto está en oferta y, si se lleva 2, se le añade un 3º gratis
En una aplicación normal, todo lo anterior deberÃamos codificarlo en métodos de clases que se ejecutaran al procesar un pedido, lo cual no siempre es sencillo. Con un motor, solo tenemos que indicarle las reglas de negocio, e ir indicándole los hechos. En este ejemplo, tendrÃamos que suministrarle al motor la información sobre los pedidos, clientes y productos mediante clases JavaBean.
Otra ventaja es a la hora de realizar cambios o mantenimiento. Si nuestro cliente desea cambiar el descuento por pedido, o el descuento por número de productos, o las fechas o tipos de productos (o quitar todos los descuentos), con un motor de reglas de negocio sólo es necesario cambiar las reglas, sin necesidad de modificar código, recompilar, ni siquiera de parar la aplicación.
Básicamente un motor de reglas de negocio está compuesto de tres elementos: un conjunto de reglas, el espacio de trabajo (o el conocimiento que tiene), y el procesador de reglas. Las reglas son sentencias de la forma IF-THEN, de tal manera que si se cumplen todas las condiciones del IF se ejecutan todas las acciones del THEN. El espacio de trabajo es donde se guarda el conocimiento (objetos Java) que el motro utilizará para decidir que reglas deben activarse.
Dentro de las reglas pueden existir conflictos. Un conflicto es cuando varias reglas distintas pueden activarse para el mismo conjunto de hechos y, la aplicación de dichas reglas, pueden tener resultados contradictorios. Algunas de las estrategias para resolver conflictos son: asignarle una prioridad a cada regla, estrategias FIFO o LIFO, aplicarlas en el orden en que se declararon o aplicarlas en orden aleatorio.
Existen otros motores de reglas de negocio para java, por ejemplo JESS (http://herzberg.ca.sandia.gov/jess/), Mandarax (http://mandarax.sourceforge.net/) o OpenRules (http://java-source.net/open-source/rule-engines/openrules). También hay
motores de reglas de negocio para plataforma .NET como Quick Rules, JRules o Blaze.
Los motores de reglas de negocio pueden utilizarse, por ejemplo, para desarrollar prototipos rápidos o, incluso, para implementar la lógica de la aplicación. También pueden utilizarse como parte de un sistema de workflow.
En el próximo mensaje pondré un ejemplo de como implementar el caso práctico que hemos visto.
» Leer más, comentarios, etc...
La luna ilumina por igual a culpables e inocentes
Drools I. Introducción a los motores de reglas de negocios.
Noviembre 30th, 2005 - [Enlace local]
Drools (http://drools.org) es una implementación libre de un motor de reglas de negocio compatible con la especificación JSR-94 Rules Engine API (http://www.jcp.org/en/jsr/detail?id=94). ¿Y qué es un motor de reglas de negocio?. Es un componente que, a partir de una información inicial y un conjunto de
reglas, detectas qué reglas deben aplicarse en un instante determinado y cuáles son los resultados de esas reglas.
Uno de los puntos fuertes de los motores de reglas de negocios es que hablan el mismo lenguaje que el dominio del problema. Un ejemplo tÃpico: supongamos que estamos hablando con un cliente para el desarrollo de una tienda virtual.
Algunas de las cosas que nuestro cliente nos pedirÃa pudieran ser:
Si la cuantÃa del pedido supera cierta cantidad o si es un cliente de confianza, entonces se le aplica un descuento. Si se compra más de N productos del mismo tipo se le aplica un descuento. Entre las fechas X e Y, un producto está en oferta y, si se lleva 2, se le añade un 3º gratis
En una aplicación normal, todo lo anterior deberÃamos codificarlo en métodos de clases que se ejecutaran al procesar un pedido, lo cual no siempre es sencillo. Con un motor, solo tenemos que indicarle las reglas de negocio, e ir indicándole los hechos. En este ejemplo, tendrÃamos que suministrarle al motor la información sobre los pedidos, clientes y productos mediante clases JavaBean.
Otra ventaja es a la hora de realizar cambios o mantenimiento. Si nuestro cliente desea cambiar el descuento por pedido, o el descuento por número de productos, o las fechas o tipos de productos (o quitar todos los descuentos), con un motor de reglas de negocio sólo es necesario cambiar las reglas, sin necesidad de modificar código, recompilar, ni siquiera de parar la aplicación.
Básicamente un motor de reglas de negocio está compuesto de tres elementos: un conjunto de reglas, el espacio de trabajo (o el conocimiento que tiene), y el procesador de reglas. Las reglas son sentencias de la forma IF-THEN, de tal manera que si se cumplen todas las condiciones del IF se ejecutan todas las acciones del THEN. El espacio de trabajo es donde se guarda el conocimiento (objetos Java) que el motro utilizará para decidir que reglas deben activarse.
Dentro de las reglas pueden existir conflictos. Un conflicto es cuando varias reglas distintas pueden activarse para el mismo conjunto de hechos y, la aplicación de dichas reglas, pueden tener resultados contradictorios. Algunas de las estrategias para resolver conflictos son: asignarle una prioridad a cada regla, estrategias FIFO o LIFO, aplicarlas en el orden en que se declararon o aplicarlas en orden aleatorio.
Existen otros motores de reglas de negocio para java, por ejemplo JESS (http://herzberg.ca.sandia.gov/jess/), Mandarax (http://mandarax.sourceforge.net/) o OpenRules (http://java-source.net/open-source/rule-engines/openrules). También hay
motores de reglas de negocio para plataforma .NET como Quick Rules, JRules o Blaze.
Los motores de reglas de negocio pueden utilizarse, por ejemplo, para desarrollar prototipos rápidos o, incluso, para implementar la lógica de la aplicación. También pueden utilizarse como parte de un sistema de workflow.
En el próximo mensaje pondré un ejemplo de como implementar el caso práctico que hemos visto.
» Leer más, comentarios, etc...
Métricas Web
Consejos para el desarrollo en C en sistemas UNIX
Noviembre 30th, 2005 - [Enlace local]
Hace poco me tuve que enfrentar al desarrollo de un pequeño servidor de
"servicios" en UNIX (un programa similar a un servidor web). Os pongo
aquà algunas observaciones y consejos que tuve en cuenta en el momento
del desarrollo, por si os pueden ayudar.
- Gestión del log de la aplicación:
Crear un buffer de lÃnea para el log:
setvbuf(access_log, (char *) NULL, _IOLBF, 0); (acces_log es el
descriptor del fichero de log que abrimos siempre con los flags de
concatenación)
Con este buffer nos aseguramos que en cuanto se llene una lÃnea esta se escriba inmediatamente al fichero.
Podemos redirigir la salida estándar de errores al log de error mediante dup2 (duplicación de descriptores de fichero)
dup2(error_log, STDERR_FILENO) Todo lo que valla al STDERR_FILENO (la
salida de error) irá a nuestro log cuyo descriptor es error_log
También lo podemos hacer para la salida estandar mediante: STDOUT_FILENO
Otro truco, si no queremos que el programa imprima nada por las salidas
estándar, es abrir el fichero /dev/null asignándole, por ejemplo, el
descriptor dev_null y hacer lo siguiente:
dup2(dev_null, 1); dup2(dev_null, 2);
Para escribir en el log conviene utilizar fputs antes que fprintf ya
que en sistemas SOLARIS si escribÃs algo NULL podéis tener problemas
con fprintf.
También podemos poner el flag Close on exec a TRUE:
fcntl(acces_log, F_SETFD, 1)
... si vamos a utilizar cualquier función de la familia exec, de esta forma no se heredan los descriptores de fichero abiertos.
- Lanzar el programa como un demonio (si está destinado a ese fin).
Podemos utilizar fork() de la siguiente forma al inicio del proceso para que se nos ponga en background.
if (fork())
exit(0) // terminamos el proceso padre
setsid(); // El hijo ahora no tiene terminal
asociado y es el nuevo lider del grupo de procesos
if (fork())
exit(0) // terminamos el proceso padre
Gracias a Jim por avisar en los comentarios que faltaba el segundo fork
- Cuestiones de seguridad.
Nada más iniciar el programa podemos crearle una jaula chroot mediante la función:
chroot(/directorio/aplicacion)
De esta forma el proceso tomará como directorio "/" el
/directorio/aplicación y no podrá salir de dicho directorio para leer o
modificar otros ficheros.
Podemos cambiar el uid del proceso
a uno sin privilegios mediante setuid. Si hemos lanzado el proceso con
privilegios de root, por ejemplo, y nos interesa poder volver a ser
root cuando queramos podemos utilizar seteuid.
Por ejemplo:
seteuid(852)
abrir un fichero o hacer algo
seteuid(0) // volvemos a ser root
Si hacemos un seteuid antes de un fork, el proceso hijo tendrá el uid indicado por el seteuid.
Establecer la máscara de creación de ficheros: mediante la función umask definimos los permisos con los que se crearán los nuevos ficheros.
- Capturar las señales que lleguen al programa.
Mediante la biblioteca sigaction podemos capturar
todas las señales (exceptor SIGKILL o SIGSTOP) y asignarles un
controlador. Esto es útil para poder cerrar los descriptores de
ficheros, indicar en los logs que se está reiniciando, abortando el
programa o realizar cualquier acción.
- Fijar los lÃmites de consumo del programa.
Mediante la llamada al sistema setrlimit(); podemos
fijar lÃmites de consumo al proceso. Por ejemplo, el número máximo de
descriptores de fichero que puede abrir (útil si trabajamos con
sockets), también podemos limitar el uso de cpu etc... Para más
información, este link.
- Obtener los parámetros de entrada al programa.
Os recomiendo utilizar la función getopt. En bulma tenéis un excelente tutorial para ello.
- Autoconf y Automake.
Con estas herramientas podemos hacer que nuestra aplicación siga el proceso de instalación estándar de GNU. Además, nos chequean el sistema antes de la instalación para ver que no falta ninguna biblioteca además de crearnos los makefiles para compilarlo. Os recomiendo leer Autobook
Seguro que me dejo algún truquito más en el tintero, agradezco comentarios y crÃticas (positivas o negativas) y ,por supuesto, mención a cualquier error que haya cometido en el artÃculo.
» Leer más, comentarios, etc...
MonoTella
Noviembre 30th, 2005 - [Enlace local]
Despues de pasar cerca de 2 semanas metido en windows para poder terminar un trabajo de Dinamica de Sistemas, y casi pelearme con todo el mundo (Es increible como te cambia el humor despues de pasar mas de 8 horas en windows), al fin logre terminar el bendito curso. Y convencido como estoy que nadie mas en el mundo debe tener que soportar usar windows para poder pasar curso alguno, decidi embarcarme en la construccion de monotella que hasta donde tengo entendido seria el primer programa libre para desarrollar diagramas de forrester (tanta era mi deseperacion que hubiera usado un programa hecho en java o incluso uno de KDE :S).
Esta basado como no en mono y gtk, de momento estoy revisando el trabajo de CeronMan y MarioC en el canvas de monouml. Pienso que puedo tomar eso como base y evitarme mucho trabajo.
Para los que no sepan que un diagrama de forrester ahi les dejo unas pantallas. 
Si alguien estuviera interesado (o interesada) en participar comuniquese conmigo cualquier ayuda es bienvenida.
» Leer más, comentarios, etc...
Desarrollo con Ruby on Rails en Mac OSX (IV): Comenzando el desarrollo
Noviembre 30th, 2005 - [Enlace local]
Pues ya sólo falta probar la instalación por completo generando el modelo para la aplicación e intentando conectar a la misma. Lo primero será, por tanto, generar el modelo.
Como puede verse en la siguiente imagen, la estructura del proyecto es clara y bien organizada. Cada cosa está en su sitio.
El siguiente paso, es generar el controlador:
Para tener una aplicación mínimamente funcional, en la que están implementadas ya las cuatro operaciones básicas (alta, baja, modificación y consulta) tan sólo hay que editar el controlador de mi aplicación, regalo_controller.rb, y añadir una línea:
¡Y ya está!. Alta, baja, modificación y consulta, en dos minutos. Sobre decir que ahora es cuando debe comenzar el trabajo de verdad, pero ya tenemos un prototipo visible, a los pocos minutos de comenzar el desarrollo. ¿Somos ágiles o no?.
Para comenzar a introducir registros, hay que atacar la url http://localhost/test/regalo/new, y comenzar a toquetear:
Resumiendo: he instalado Rails (media hora más o menos), he instalado MySQL (un poco más largo, por los problemas con las herramientas de administración, pero en total ha sido una hora), he compilado el binding para MySQL (varias horas de google y unos minutos de resolución) y he realizado la primera iteración del desarrollo propiamente dicho (¡cinco minutos!).
Ahora empieza lo bueno…
» Leer más, comentarios, etc...
Turbo C++ 3 con 128 Kb de memoria
Noviembre 29th, 2005 - [Enlace local]
¿Te imaginas poder ejecutar Turbo C++ 3 para DOS con solamente 128 Kb de memoria?
Al menos eso es lo que asegura Borland en la página de producto de Turbo C++ Suite.
Turbo C++ 3 para DOS es capaz de funcionar con solamente 128 Kb de RAM (1 Megabit).
Turbo C++ 4.5 para Windows 3.1, se conforma con solamente 2,5 Mb de espacio en disco (20 Megabit).
JurarÃa que las cantidades correctas estaban entorno a 8 veces más… porque si la memoria no me falla, ya el Turbo C++ 1.0 requerÃa al menos 512 Kb de memoria.
Por supuesto la confusión se debe a un error de transcripción, indicando las unidades en bits, cuando se quiere decir bytes.
Cuando esta errata ocurre en una empresa que desarrolla software para desarrolladores, el asunto se torna considerablemente más grave. Quizás estoy dando demasiada importancia a los tecnicismos… Imaginaros por un momento que el error hubiera sido poner el precio en pesetas en vez de euros.
¡Malentendidos mucho mayores he visto por cosas muchÃsimo más pequeñas!
;)
» Leer más, comentarios, etc...
Turbo C++ 3 con 128 Kb de memoria
Noviembre 29th, 2005 - [Enlace local]
¿Te imaginas poder ejecutar Turbo C++ 3 para DOS con solamente 128 Kb de memoria?
Al menos eso es lo que asegura Borland en la página de producto de Turbo C++ Suite.
Turbo C++ 3 para DOS es capaz de funcionar con solamente 128 Kb de RAM (1 Megabit).
Turbo C++ 4.5 para Windows 3.1, se conforma con solamente 2,5 Mb de espacio en disco (20 Megabit).
JurarÃa que las cantidades correctas estaban entorno a 8 veces más… porque si la memoria no me falla, ya el Turbo C++ 1.0 requerÃa al menos 512 Kb de memoria.
Por supuesto la confusión se debe a un error de transcripción, indicando las unidades en bits, cuando se quiere decir bytes.
Cuando esta errata ocurre en una empresa que desarrolla software para desarrolladores, el asunto se torna considerablemente más grave. Quizás estoy dando demasiada importancia a los tecnicismos… Imaginaros por un momento que el error hubiera sido poner el precio en pesetas en vez de euros.
¡Malentendidos mucho mayores he visto por cosas muchÃsimo más pequeñas!
» Leer más, comentarios, etc...
Entrevista en Radio Creswin
Noviembre 29th, 2005 - [Enlace local]
El proximo jueves, 1 de diciembre, a las 18:30 horas en Mexico ( 1:30 horas del viernes 2 de diciembre en España), seré entrevistado en Radio Creswin sobre temas de SQL. Para formular preguntas, enviad un correo a radiocreswin@hotmail.com indicando…
» Leer más, comentarios, etc...
Páginas y controles compilados al vuelo con ASP.NET
Noviembre 29th, 2005 - [Enlace local]
A la hora de desarrollar páginas web en .NET es posible hacer que las páginas y los controles estén compilados y con toda la lógica en una DLL, o hacer que las páginas y los controles se compilen al vuelo conforme se van solicitando por los usuarios, quedando disponibles a partir de entonces para sucesivas peticiones. Dentro de la opción de compilación al vuelo podemos tener la lógica y la presentación (HTML) juntas en un mismo archivo, o en diferentes. Voy a tratar únicamente la forma basada en archivos independientes, ya que es la opción predeterminada en Visual Studio, SharpDevelop, además de propiciar una mayor separación entre lógica y presentación, lo cual incrementa la mantenibilidad del proyecto.
Ambas aproximaciones, compilación estática o al vuelo, tienen sus puntos fuertes asà como algunos inconvenientes. La opción de tener toda la lógica compilada nos aporta una mayor velocidad desde el momento inicial en el que se arranca la aplicación, pero en contra nos obliga a tener que recompilar la aplicación o alguna parte de ella y generar una nueva DLL cada vez que se realiza un cambio, implicando un reinicio de la aplicación con el coste que ello supone.
Por contra la opción basada en compilación al vuelo, on the fly
en inglés, nos permite modificar la lógica de cualquier página y control sin tener que recompilar la aplicación ni tener que reiniciar la aplicación. Sin embargo tiene como desventaja que el arranque de la aplicación será algo más pesado, ya que ninguna página o control estará compilado y por lo tanto será necesario compilarlos conforme se vayan solicitando, incrementando los requisitos del servidor en esos momentos.
En lo que a mi respecta, la mayorÃa de los proyectos que realizo últimamente los hago utilizando compilación al vuelo, a pesar de que al comienzo utilizaba la compilación estática. El motivo principal que propició este cambio fue la facilidad de mantenimiento que aporta la compilación al vuelo, aunque en ningún caso deberÃa deberÃa tomarse esto como una regla ya que cada proyecto es un mundo.
A continuación voy a explicar cómo hacer que las páginas y controles se compilen al vuelo, detallando algunos problemas con los que nos podemos encontrar y posibles soluciones.
» Leer más, comentarios, etc...
Las 10 reglas de una Start-up
Noviembre 29th, 2005 - [Enlace local]
Continua leyendo “Las 10 reglas de una Start-up”
» Leer más, comentarios, etc...
knocte :: MonoTema
Mozilla Firefox 1.5 ya está en la calle
Noviembre 29th, 2005 - [Enlace local]
Nos lo cuenta stripTM antes que nadie en BarraPunto. Bueno, pues tras mucho testeo, mucho commit de última hora y mucho bug cosmético pendiente de aplicar para una posible versión 1.5.0.1, ¡Firefox ya está en la calle! Y además en español desde la portada de Mozilla Corporation desde su primer dÃa de lanzamiento (es-ES). Tengo que agradecer a todos los miembros de NAVE por su apoyo en hacerme
» Leer más, comentarios, etc...
Software Guru No. 6 en circulación
Noviembre 28th, 2005 - [Enlace local]
- LINQ, Reduciendo la complejidad del Acceso a Datos, por Luis Daniel Soto
- La Calidad no basta, Innovar para ser competente, por Francisco Rivera
- Patrones de Casos de uso, por Saúl Cuesta Rodriguez
- El proceso de la prueba de software, por Luis Vinicio León
La revista la pueden descargar del sitio de Software Guru.
» Leer más, comentarios, etc...
Delphi vs Visual Basic
Noviembre 28th, 2005 - [Enlace local]
» Leer más, comentarios, etc...
Tres horas por un link
Noviembre 28th, 2005 - [Enlace local]
Continua leyendo “Tres horas por un link”
» Leer más, comentarios, etc...
MonoDevelop 0.9
Noviembre 28th, 2005 - [Enlace local]
Revisando el blog de Miguel veo que ya ha salido una nueva version de MonoDevelop y tiene características nuevas muy interesantes; las notas de esta version estan aqui.
- Página de bienvenida. En la cual aparecen los proyectos creados o modificados recientemente.
- Una nueva arquitectura basada en componentes para la IDE. Para mas detalles ver Architecture Overview.
- Un nuevo administrador de Add-In.Para instalar, remover y actualizar plugins para la IDE de MonoDevelop.
- Una herramienta de construcion (build) en linea de comandos.. Ahora se puede integrar proyectos de MonoDevelop dentro de un batch de proceso de compilación.
- Smart Indent para C# y Boo.. Esta opcion puede ser habilitada desde el panel de comportamiento del editor de texto, en el diálogo de preferencias.
Aunque yo uso Vim 
para programar, pero es bueno ver los avances que se hacen con la IDE de MonoDevelop.
Ahi los vidrios 
.
» Leer más, comentarios, etc...
Thefull
T-Gtk + Eagle1
Noviembre 28th, 2005 - [Enlace local]
T-Gtk + Eagle1 bajo GNU/Linux
» Leer más, comentarios, etc...
knocte :: MonoTema
eXtreme Programming: La chispa adecuada
Noviembre 27th, 2005 - [Enlace local]
Estos dÃas he estado desempolvando una carpeta de mis marcadores titulada "Lecturas pendientes". Son enlaces que en su dÃa me parecieron interesantes pero demasiado largos de leer en ese momento (una idea similar a lo que son los FIXMEs en el código). Uno de los enlaces a los que he llegado ha sido extremadamente interesante. Tanto, que los enlaces dentro de éste me han hecho abrir pestañas y
» Leer más, comentarios, etc...
vnsjava
programar para el nuevo procesador Cell
Noviembre 27th, 2005 - [Enlace local]
espero que lo disfruten.
» Leer más, comentarios, etc...
vnsjava
Sobre JavaWebStart
Noviembre 27th, 2005 - [Enlace local]
Si de java también, otra tecnologÃaEs un lanzador de aplicaciones via un navegador web. Creo que el grafico es muy explicito.
ventajas:
- control de versiones y actulizacion automatica de la aplicación transparente al usuario
- independiente de navegador
- independiente de sistema operativo
- firma de código
- agrega caracteristicas de las que disfrutanlos applets como: seguridad, etc.
para más información:
http://java.sun.com/products/javawebstart/
también este artÃculo:
http://www.javahispano.org/article
» Leer más, comentarios, etc...
CMM - CMMI Nivel 2
Noviembre 26th, 2005 - [Enlace local]
Para aquellos que ya tengáis una noción de lo que es el Modelo de calidad CMM-CMMI y queráis profundizar un poco en el nivel 2 de CMM-CMMI os recomiendo esta lectura.
» Leer más, comentarios, etc...
Escalabilidad. Parte 1. El autobús.
Noviembre 26th, 2005 - [Enlace local]
Al entrar en un autobús, con el fin de no matarte intentando sentarte, has de esperar a que el conductor te sitúe en tu asiento. Como no es posible saber que asientos están vacÃos o no, en cada autobús hay un señor, llamado amablemente GC (Garbage Collector), que se dedica a pasar por los asientos viendo cuales están libres e informando al conductor de que están disponibles. De esta forma, cada cierto tiempo se cede la linterna al señor GC para que recorra el autobús en busca de asientos libres.
En circunstancias normales, el asiento queda libre en cada parada, y al señor GC le da tiempo a recorrerse todos los asientos antes de llegar a la siguiente parada. Y en el caso de que no le de tiempo, el señor GC se siente seguro al ceder la linterna a un viajero para que pueda sentarse, porque en circunstancias normales suelen quedar asientos libres que ya han sido comprobados por el señor GC.
Pero ahora el señor GC está de suerte, porque va a realizar su trabajo en un gran trasatlántico. El señor GC está encantado, porque en un trasatlántico existen multitud de asientos libres –piensa- y aunque tarde casi 30 minutos en recorrer todo el barco con la linterna, puede ceder la linterna cada pocos segundos a otro pasajero para que este pueda moverse por el barco, y asà contribuir a que nadie se mate.
Un dÃa, 6000 personas deciden subir al barco. Las personas no dejan de moverse por el barco, de sentarse y levantarse, por lo que el señor GC se encuentra con un inmenso problema: no es capaz de recorrer todo el barco y comprobar cuantos asientos libres hay, asà que pasa la mayor parte del tiempo corriendo de arriba a abajo por el barco, acaparando todo el tiempo de linterna. En el mejor de los casos, la mayorÃa de pasajeros simplemente se quedará inmóvil la mayor parte del crucero, con lo que esto supone. En algunos casos extremos, en aguas del pacÃfico, se dice que algún barco naufrago a causa de que todos los pasajeros corrieron presa del pánico.
Primera regla barata de la escalabilidad: El recolector de basura te evita lidiar con los punteros, devuélvele el favor e intenta no darle mucha faena entre petición. En una aplicación para 40 clientes puede funcionar, pero “crujirse un crucero� con el GC es más fácil de lo que parece.
» Leer más, comentarios, etc...
Pointer to (void)
Branching como apoyo a la configuración
Noviembre 25th, 2005 - [Enlace local]
Una de las ventajas de los sistemas de control de versiones es la posibilidad de mantener distintas lÃneas de código abiertas (branches o ramas). La acción de derivar código de una lÃnea a otra es lo que en diveka (y en medio mundo) denominamos branching. Generalmente, cada lÃnea tiene una polÃtica de desarrollo distinta, que establece que tipos de cambios se realizan sobre el producto. Utilizando esta breve definición, ya podemos sacar dos ventajas:
- Es posible configurar un mismo producto para diferentes necesidades, manteniendo una base común entre los dos. Esto se aplica, por ejemplo, a clientes distintos, plataformas distintas, etc.
- Es posible reflejar el estado del producto en un determinado momento, de forma precisa. Esto se aplica, por ejemplo, para distinguir versiones de desarrollo de versiones release de un mismo producto.
Asà pues, introducidos en el tema, hoy me gustarÃa exponer el modelo de branching que utilizamos en Empresa Solidaria, y como este modelo flexibiliza nuestra producción.
En el repositorio de Empresa Solidaria existe una lÃnea principal, a la que llamamos cariñosamente Main, donde se introducen nuevas caracterÃsticas. La polÃtica de versiones que hemos trazado, establece que se libera una versión por mes y una serie de releases internas durante ese mes.
Por lo tanto, disponemos de lÃneas de versión sobre la rama de release de la Conselleria de Bienestar Social, que nos permiten configurar el producto para la Conselleria e ir integrando en esta rama todos los cambios que vayamos incorporando al producto. Es más, como trabajamos con secciones atómicas de código, en alguna ocasión hemos tenido que liberar cambios pertenecientes a una versión de release y tirar atrás algunos de ellos (en ese momento es en el que puedo justificar el coste de desarrollo del sistema de build :) ).
Para aquellas caracterÃsticas que han sido ya implementadas, el equipo de QA puede dedicarse a testearlas en la correspondiente rama de QA. Una vez se completa, y se determina que el producto es suficientemente estable, se pasa a la rama de release. De igual forma, en el proceso de build se recoge código de otros componentes de desarrollo propio de diveka, que obviamente se utilizan en diversos productos. Cada componente, incorpora la información de cómo debe construirse, y el sistema de build es capaz de indicar qué tipo de configuración es necesaria para ese componente en el producto actual.
Afortunadamente, el sistema de build es capaz de generar una versión (y cuando decimos versión, es una release en toda regla, con instalador, documentación, pruebas unitarias, etc.) de forma automática, a partir de cualquier rama del producto, ya que estas están configuradas para contener la información de generación. ¿Quién dijo que era una pérdida de tiempo dedicarse a esto?
» Leer más, comentarios, etc...
Pointer to (void)
Branching como apoyo a la configuración
Noviembre 25th, 2005 - [Enlace local]
- Es posible configurar un mismo producto para diferentes necesidades, manteniendo una base común entre los dos. Esto se aplica, por ejemplo, a clientes distintos, plataformas distintas, etc.
- Es posible reflejar el estado del producto en un determinado momento, de forma precisa. Esto se aplica, por ejemplo, para distinguir versiones de desarrollo de versiones release de un mismo producto.
Asà pues, introducidos en el tema, hoy me gustarÃa exponer el modelo de branching que utilizamos en Empresa Solidaria, y como este modelo flexibiliza nuestra producción.
En el repositorio de Empresa Solidaria existe una lÃnea principal, a la que llamamos cariñosamente Main, donde se introducen nuevas caracterÃsticas. La polÃtica de versiones que hemos trazado, establece que se libera una versión por mes y una serie de releases internas durante ese mes.
Por lo tanto, disponemos de lÃneas de versión sobre la rama de release de la Conselleria de Bienestar Social, que nos permiten configurar el producto para la Conselleria e ir integrando en esta rama todos los cambios que vayamos incorporando al producto. Es más, como trabajamos con secciones atómicas de código, en alguna ocasión hemos tenido que liberar cambios pertenecientes a una versión de release y tirar atrás algunos de ellos (en ese momento es en el que puedo justificar el coste de desarrollo del sistema de build :) ).
Para aquellas caracterÃsticas que han sido ya implementadas, el equipo de QA puede dedicarse a testearlas en la correspondiente rama de QA. Una vez se completa, y se determina que el producto es suficientemente estable, se pasa a la rama de release. De igual forma, en el proceso de build se recoge código de otros componentes de desarrollo propio de diveka, que obviamente se utilizan en diversos productos. Cada componente, incorpora la información de cómo debe construirse, y el sistema de build es capaz de indicar qué tipo de configuración es necesaria para ese componente en el producto actual.
Afortunadamente, el sistema de build es capaz de generar una versión (y cuando decimos versión, es una release en toda regla, con instalador, documentación, pruebas unitarias, etc.) de forma automática, a partir de cualquier rama del producto, ya que estas están configuradas para contener la información de generación. ¿Quién dijo que era una pérdida de tiempo dedicarse a esto?