Criterios de desarrollo del Ekeko

Basado en: XP - La Catedral y el Bazar - Mejores practicas - Sentido comun - Prácticas culturales del Software Libre, Unix e Internet - El arte de programar - Volver a lo básico

Diego Saravia

dsa@unsa.edu.ar

Enero 2004

Version 0.1

Las teorias deben ser lo mas simples posibles, pero no mas de esto.

Albert Einstein. Ekeko

IDEAS

  1. Programar es la tarea principal y definitoria en la creación de sistemas. La herramienta y capacidad fundamental de un creador de sistemas es su capacidad y nivel como programador. Todo lo otro es secundario. La elegancia y belleza del codigo generado es el principal criterio de su evaluacion.
  2. La creacion de software es un arte, no una tecnica, ni una ingenieria. El software debe crearse para resolver problemas nuevos. Cuando se debe crear otro software para tareas similares, se esta fallando en el enfoque del problema. El enfoque correcto es crear un lenguaje con el nivel de abstraccion suficiente para manejar todos las posibilidades de uso. De tal forma cada nueva tarea similar se implementa configurando el software para ella usando un lenguaje de nivel descriptivo acorde a la tarea. Por ejemplo no es correcto adaptar una base de datos para un negocio u otro. Programar seria instrumentar un lenguaje que permita a partir de la descripcion del negocio hacer funcionar el sistema. Cada tipo de negocio requerira una descripcion especifica unica para todos los negocios similares. Todos los restaurantes/puntos de venta/etc del mundo podrian usar el mismo soft!
  3. El diseño se expresa en el Codigo. El Codigo expresa el Diseño. Cualquier descripcion formal del diseño de un sistema, debe ser parte de su programacion. Se debe diseñar con un lenguaje que trasmita este diseño en codigo ejecutable. Cuanto mayor nivel mejor, pero nunca un lenguaje de descripcion que no pueda finalmente ser compilado o interpretado.

    Descripciones cortas introductorias y no formales para explicar los conceptos claves, graficos y esquemas aclaratorios si. Sistemas formales no codificables no.

    Programar y diseñar son tareas inseparables.

  4. La mejor documentación sobre un sistema es un codigo bien redactado. El codigo es el lenguaje humano que describe lo que los sistemas hacen. Los compiladores e interpretadores se encargan de traducir esto a un lenguaje que las computaroas entiendan.

    Codigo que requiere textos en lenguaje natural para explicarse es un codigo de baja calidad y confuso.

  5. Para crear un sistema se debe en primer lugar comprender, probar y hacer interactuar todas las tecnologias que se piensan usar. Se deben construir tests para probrar que funcionan como se piensa y que se conocen sus limites de capacidad y rendimiento. Estos test se aplicaran a los primeros modulos que se vayan construyendo para utilizar las tecnologias en su bajo nivel. La tecnologia determina e impacta profundamente en los diseños por lo que cualquier esfuerzo en clarificar estas interfaces repercute enormemente en todo lo que se haga a psoteriori. Con las primeras versiones de estos modulos se puede comenzar a programar los sitemas deseados, implementando test de los mismos en paralelo con su desarrollo.
  6. Pequeñas herramientas para cada tarea, que funcionan desde linea de comando. Separar gui de herramientas. La herramienta ideal es el filtro
  7. El cambio permanente y rapido es un muy buen amigo de la programacion. Obliga a codificar en forma comprensible y elegante. evita concentrase en los detalles. Los refactoreos de los proyectos son su principal activador y cuestionador externo.

    El trabajo de diseño se expresa constantemente en el refactoreo del codigo. Si es importante la arquitectura se debe refinar la misma permanentemente.

    Se deben sacar nuevas versiones con mucha velocidad. Tiempos de minutos y horas en entre versiones de produccion. No semanas o meses. Tener mecanismos aceitados para poner nuevas versiones es basico. Si un usuario requiere un cambio y se lo puede poner en minutos mejor.

    Los cambios son como conducir un auto. Se debe ir llevando el sistema al objetivo poco a poco. Manteniendo su fuincionamiento, Micro cambios, muchos y seguidos producen lso granddes cambios. el sistema se mantiene siempre en produccion. Realimentacion permanente.

    El mejor sistema es el que se esta usando. El software rapidamente debe entrar en produccion y mantenimiento. Un sistema que no esta en proiduccion es una carga economica y una ineficiencia.

    Los sistemas siempre evolucionan, si se quedan mueren. UN siftware vivo es aquiel que tiene programadores mejorandolo.

  8. La rotacion de las personas sobre diferentes codigos es positiva. Al menos se debe programar de a pares. Los pares revisan permanentemente el codigo de otros. Los usuarios tambien en forma permanente y constante.
  9. Se debe testear todo permanentemente, lo primero a crear para cada funcionalidad son sus test.
  10. El 20% de la funcionalidad es el 80% de lo que se necesita.

    80% del beneficio viene del 20% del trabajo.

  11. Reglas de la cultura UNIX: KISS: Keep it simple stupid. El arte de hackear por placer, o programar.
    1. Flexibilidad
    2. Comunidad y Cultura
    3. Internet
    4. Software Libre
    5. Modularidad: partes simples conectadas con interfaces claras
    6. Composicion: programas diseñados para copnectarse a otros
    7. Simplicidad: solo la minima complejidad necesaria para la funcion
    8. Transparencia: diseñar para la visibilidad, para hacer la inspeccion mas facil
    9. Robustez: es la hija de la transparencia y la simplicidad
    10. menor sorpresa: para diseñar interfaz, esta hara lo menos sorprendente
    11. reparacion: cuando algo deba fallar, lo antes y mas ruidosamente posible.
    12. generacion: evite hackear a mano, escriba programnas que escriban programas en cuanto lugar pueda.
    13. representacion: use datos inteligentes, para que la logica del codigo sea estupida y robiusta.
    14. SDame la estructura de datos y te dare el codigo
    15. Separacion: separar politica de mecanismo, interface de motoroes.
    16. Optimizacion: prototipe antes de pulir. Hagalo tabajar antes de optimizar.
    17. Diversidad: descrea de todos los que dicen el unico camino verdadero
    18. Extensibilidad: diseñe para el futuro, porque esta mas cerca de lo creible.
    Aplicando la filosofia Unix. Jugar y explorar. Mantenga claro y simple.
    1. Cualquier cosa que pueda ser un filtro debe serlo
    2. streams de datos deben ser textuales
    3. las estructurad de datos deben ser textuales, legibles y editables por humanos
    4. interfaces complejas deben ser separadas de los back ends complejos
    5. antes del c prototipe en scripts-
    6. Mezclar lenguajes es mejor que usar uno solo si usar uno complica la cosa.
    7. sea generoso en lo que acepta riguros en lo que emite
    8. cuando filtre, nunca tire informacion que no necesite tirar.
    9. lo pequeño es bonito. escriba cosas chicas y consistentes que cumplan su funcion.

VALORES

Comunicacion, simplicidad, realimentacion, coraje.

PRINCIPIOS

Realimentacion rapida, asumir simplicidad, cambios incrementales, adopcio del cambio, calidad.

ACTIVIDADES

codificar: porque si no, no se tiene nada testear: porque si no no se sabe si se termino de codificar escuchar: porque si no no se sabe que codificar o testear. diseñar: para mantenerse codificando, testeando y escuchando en forma permanente. administrar: para que el proyecto avance.

PRACTICAS

  1. El juego de planeamiento

    Determinar rapidamente el ambiuto de la proxima version combinando prioridades y estimado stecnicos. A medida que la realidad se impone sobre el plan, cambiar el plan.

  2. Versiones chicas

    Ponga un sistema simple en produccion rapidamente, luego large nuevas versiones cada poco

  3. Metaforas

    Guie el desarrollo con una metafora simpel y compartida sobre como trabaja el sistema (cuadro de mando personalizado)

  4. Diseño simple

    Tan simple como sea posible en cada momento. La complejidad extra es removida apenas se la encuentra Se debe tener el mas simple diseño que ejecute la funcionalidad operativa. A medida que se hay mas funciones se cambia el diseño. A medida que se comprende mejor un sistema para una dada funcionalidad se simplifica. Proceso de expansion - compresion.

  5. Tests

    Los programadores escriben test unitarios todo el tiempo. Estos deben correr sin problemas en todo el ciclo de desarrollo. Usuarios escriben test probando que todo funciona.

  6. Refactoreo

    Los programadores restructuran el sistema sin cambiar el comportamiento para remover duplicaion, mejorar comuinicaciones simplificar o flexibilizar.

  7. Programacion de a pares

    Todo el codigo se escribe por dos programadores por maquina todo el tiempo

  8. Propiedad compartida

    Cualquiera puede cambiar cualquier parte en cualquier momento.

  9. Integracion continua

    Integrar el sistema muchas veces por dia, cada vez que se completa una tarea.

  10. 40 horas por semana

    No mas de este tiempo. Nunca sobretiempo u horas extra.

  11. Usuario en el lugar

    Tener un usaurio del sistema en el equipo., disponible todo el tiempo.

  12. Estandares de codigo

    Todos escriben codigo de acuerdo a estandares con reglas que enfaticen comunicacion.

ADMINISTRACION

  1. Metricas

    Cartelera con las metricas elegidas cambiada todos los dias: numero de tests,etc. no mas de 4 medidas reemplazr medidas cada tanto. los numeros son una forma de comunicar el cambio

  2. Coaching

    su trabajo es asegurarse que todos hagan buenas decisiones: explicar el proceso a sus superiore, ayduar a los programadores con habilidades tecnicas como tests, formateo, refactoreo. ver objetivos a largo plazo, impulsr pequeños cambios, ser un compañerpo de programcion, particularmete para los nuevos programadores. Adquirir juguetes y comida es su tarea.

  3. Tracking

    contrastar las metricas usadas con el planeamiento.

  4. Intervencion

    muchas veces los programadores no tienen respuestas a algun desafio o no ven los probleams se requiere alguien que decida. Intervencio a tiempo. cambios de personal

  5. Opciones

    abandonar, cambiar la direccion, diferir, crecer

  6. Factores economicos

    Cash flow, Intereses, Mortalidad de proyecto

  7. Variables en el desarrollo

    Costo, tiempo, calidad, ambito

CICLO DE VIDA

Exploracion, planeamiento, primera version, produccion, mantenimiento, muerte.

Waterfall.

ROLES

programador: usuario, tester, tracker, coach, consultores, jefe

BUENAS PRACTICAS

  1. Planeamiento y diseño incremental durante todo el ciclo de vida..
  2. Cronogramas adaptativos
  3. Test automaticos creados por programadores y usuarios.
  4. Comunicacion oral, con test, y con codigfo fuente
  5. Programadores colaborando
  6. Practicas que trabajan con los intereses de vida corta de los programadores y de largo termino del proyecto.
  7. Los programadores deben trabajar siempre en las cosas que importan. Deben poder tomar las decisiones sobre lo que les compete.
  8. Como usar el tiempo: Escribir test, restructura cuando se aprende algo, conversar mucho con programdores colegas y clietnes.
  9. Los administradores de proyectos deben poder sacar el maximo rendimiento horario en funciones y calidad del softwre por hora de programdor.
  10. Reducir riesgo, aumentar la respuesta al cambio, aumentar productividada lo largo del ciclo de vida, construir soft en equipos.
  11. Desarrollo inducido por test. Primero el test, luego el codigo. Hasta que todos los test se pasan no se termina. Cuando los pasa y no hay mas test posibles, esta listo. Nueva funcionalidad es mas test.
  12. El programa y su diseño evolucionsa, los cambios no se restringen a un area, los programadores añaden valor al analisis, diseño, implemtenacion, y test. Añaden valor a todos los lugares donde es nmecesario-. Diseñar ,analizar y testear es programar.
  13. La Integracion sigue inmediateamente al desarrollo incluido el test de integracion.
  14. Minimizar el costo de cambiar, para cambiar mucho
    1. Buscar el peor problema
    2. Resolverlo
    3. Cuando no sea el peor problema, repetir
Compacto y ortogonal. Seco. NOOOOOOOOOO. Hay mas de una manera de hacerlo.

Patrones guias para el desarrollo, puntos a iluminar

Cambios a la informacion persistente

Todo cambio a las bases de datos o sistema de archivos bajo el Ekeko, debe hacerse mediante interacciones con el sistema de procesamiento. Cuando la interfaz de acceso es CGI mediante las corespondientes variables. Las variables permitiran acceder directamente a modificar los diferentes recursos con un lenguaje particular. Enviando una variable "accion/alm__$MODULO__$SUB__$VARIABLE=$VALOR" Cuando se debe preprocesar o validar la inforamcion se crearan subrutinas especificas cuya entrada son varaibles cgi especiales y salida las variables cgi precitadas que alteran los recursos especificos. El motor de procesamiento discrimina en funcion de la variable, que subrutina ejecutar y en que modulo se encuentra. Distintos componentes o subsistenmas tendran modulos propios con las funciones que interconviertan Esta entonces separada la logica de l presentacion e interaccion del motor de cambios. Este motor tiene variables especificas para cada recurso y un sistema fijo de accioens especiales que convierten las variables especiales (no las de los recursos) en variables especificas de recursos.

Matriz de transformacion de variables en otras para preprocesar

Enviando una variable "mat__$MODULO__$SUB__$VARIABLE=$VALOR" el programa ejecuta la subrutina en cuestion con esos argumentos en esa subrutina podes leer las otras variable de entorno que necesites, leer las tablas y archivos que quieras pero no cambies archivos ni datos en las bases. Emiti variables apropiadas con variable() y retorna de la subrutina con una array conteniendo los keys de esas variables. Con esto el programa modificado cargara y procesara las nuevas variables adecuadamenteç

Variables de modulo

Las funciones deben ser reentrantes, para poder ser llamadas en forma recursiva si es necesario Cada modulo debe tener sus variables internas y las funciones no llamarlas cada vez Solucion: usar objetos.

Politica de errores

La decision sobre que hacer con los errores debe estar al mayor nivel: usuario.

Las rutinas inferiores (que detectan errores) deben reportar por canal independiente al usuario, no a la rutina superior, esta recibira la informacion de la inferior aun ante casos de error, donde recibira lo mejor que pueda. Via estos datos es que la superior sabe del error lo que necesite saber para poder seguir funcionando.

Las rutinas superiores deben saber que hacer ante cada tipo de dato recibido, aun los producidos ante errores.

El usuario sabra que hacer con la informacion de los errores, solo los clasificados con mas de cierto nivel seran informados. Solo los muy especiales seran puestos como alarma al usuario y eventualmente detendran el programa.

Lo pequeño es hermoso

Herramientas tan pequeñas como sea posible comunicandose con protocolos claros o repositorios estandar.

Mas hermoso

refactorear permanentemente. Crecer para mas funciones y achicar para mejorar la calidad. Siempre achicar.

Test

Expect like a browser and retrieve pages or talk to a CGI script

way of testing HTTP servers and running CGI scripts (and winning Web contests :-). You can add error checking and other stuff, but here's the minimum your script should have to read a web page:

match_max 100000

set timeout -1

spawn telnet $host 80 expect "Escape character is *\n"

send "GET $page\r\n"

expect

puts "$expect_out(buffer)"

If you want to communicate information to a CGI script, you'll want more. One way to see what needs to be sent is to load a real browser with the form and then send it to a fake daemon such as this one:

#!/bin/sh

/bin/cat -u > /tmp/catlog

Enable this by adding this service to inetd. Then save the form in a temporary file, modify the form's host and port to correspond to your own host and whatever port you've chosen to associate with your fake daemon. Now fill out the form and you'll find the form data in /tmp/catlog. Using this, you can determine exactly how to amend your Expect script to behave like your browser.

Don http://expect.nist.gov/FAQ.html#q25

Test

Test::Tutorial - A tutorial about writing really basic tests

Testing tools Test::Simple, Test::Inline, Carp::Assert, Test::More, Test::MockObject

Tips

  • checkar logs sistematicamente
  • correr desde la linea de comando
  • checkar con -c (-wcT)
  • testear variables cgi mandandolas a la pantalla
  • $|=1; turn buffering off

    unbuffer stdout

    use Fcntl ":flock"

    flock FILE, LOCK_EX (exclusive) SH (shared) UN (unlock)

  • abrir dos veces shared para leer y exclusive para escribir
  • IO:File archivos temporarios
  • usar use strict
  • chekear status de system calls
  • verficar que todos los archivos se abren OK
  • no usar die sino carp u otro: CGI carp
  • http://extremeprogramming.org/ h2xs -AXn Ekeko::loquesea Dos niveles de error: MENSAJES: los predetectados, errores al abrir archivos, incorporaciones o no a la base de datos, etc que son manejados por el modulo de error y que se confunde con el sistema de mensajes al usuario, 1) Algunos mensajes son normales, realimentacion al usuario, informacion por un canal adicional al del programa sobre lo que hace. el nivel de debug indica que mensajes se tiran, registran o cuales se registran y se muestran. Los cambios a los datos estables conviene guardarlos como historicos. 2) Otros son errores que reflejan problemas diversos, de organizacion del sitio, etc, siempre se deben mostrar. BUGS: los imprevistos a CGI carp, la idea es que los registre y los muestre al usuario com tales, en forma cruel al programador, pero tambien que no existan, o sea si aparece avisar al desarrollador de un BUG del programa

    Procesos

    Sistema de Menus, procesos y tareas para ekeko

    Basico para el tablero de comando personalizado

    En funcion de los procesos en marcha y las responsabilidades, atribuciones del rol presenta un menu de posibles weblets.

  • La gestion se organiza en procesos
  • Los procesos son conjuntos de tareas.
  • Las tareas se ejecutan mediante weblets, con sus templates y datos
  • Para cada proceso, las tareas cumplidas exitosametne se consideran OK
  • Los elementos (archivos, directorios, tablas, etc) son los datos
  • Las personas actuan en base a su rol.
  • Los roles se implementan por alias o grupos
  • La tabla acl relaciona roles, con permisos y con datos o weblets (que son un dato)

    tabla tipo_tareas id sigla weblet variables especiales para esa tarea en el weblet icono .... tipoproceso_id tipo_tareas_previas_id (lista)

    tabla tareas id fecha inicio fecha fin status/resultado realiza descripcion proceso_id

    La tabla tipoproceso contiene: id, nombre

    La tabla procesos contiene id, tipoproceso_id quien inicia fecha inicio lista de tareas con OK, y quienes las hicieron. expedte fisico relacionado Actividad/Suspendido/TerminadoOK comentarios

    Tabla acl tipo_tarea derechos ... dato (base, archivo, directorio, weblet) individual ("alias", o grupos) este campo indica que cuando se crea el dato a nivel registro, en el campo acl del registro, se coloca el alias del usuario (caso alias) o el alias de los grupos indicados a los que el alias pertenece

    Tabla responsables alias tipo_tarea

    tabla grupos alias_id grupo alias_id integrante

    El esqueleto del menu es una lista jerarquica de tareas

    El menu se hace incorporando tareas segun cuales de los tareas del esqueleto del menu, son iniciales a alguin proceso (sin tareas previas) y cuales de los procesos no terminados tienen tareas pendientes sin tareas previas.

    De la lista de tareas resultantes se toman solo las que pueden ser ejecutadas por el rol del usuario en cuestion.

    El esqueleto es un conjunto de listas de menues y tareas

    tipotarea-sigla=>{D/R: display/href, incluido en tipotarea-sigla tipo: tarea/menu }

    proceso (si aparece se verifica si es inicial o si hay procesos con tareas pendientes sin previas)

    El menu se arma poniendo para cada tarea una opcion tarea_nueva, mas la lista de las tareas que esa persona tiene para procesar

    Al ejecutarse una tarea el display que ejecuta el weblet en cuestion regitra, el hehco y si termina con proceso sin errores o no.

    Estos hash se ponen en un weblink archivo_idx_e.pl

    Un weblet idx_wl.pl procesa estos weblinks

    Cuando este archivo se ejecuta dispara el weblet menu que presenta el mismo a cada usuario.

    El archivo idx_idx_e.pl se dispara automaticamente de existir al entrar a un directorio.

    El ekeko presenenta el weblet que ejecuta la tarea y permite incorporar comentarios al proceso bajo el cual se ejecuta la tarea.

    usar mostrador de listas para desplegar menues.

    Paginas

  • http://httpunit.sourceforge.ne/t
  • http://www.zdnet.com.au/builder/program/java/story/0,2000034779,20264830,00.htm
  • http://search.cpan.org/~mshiltonj/CGI-Test-0.104/Test/Page/HTML.pm
  • http://search.cpan.org/~corion/Test-HTML-Content-0.07/lib/Test/HTML/Content.pm
  • http://search.cpan.org/search?query=test+html+forms&mode=all
  • http://www.petdance.com/perl/large-project-testing.pdf
  • http://www.w3.org/DesignIssues/RDF-XML.html
  • http://www.w3.org/DesignIssues/RDFnot.html
  • http://www.redland.opensource.ac.uk/using.html
  • http://www.hacknot.info/servlet/HS?cmd=sen&eid=22
  • http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
  • http://www.agile-spain.com/
  • http://www.agile-spain.com/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=15&page=1
  • http://slashdot.org/article.pl?sid=04/01/05/1712222
  • http://www.w3.org/RDF/FAQ

    Bibliografia

    1. The art of Unix programing. Raymond.
    2. Exterme programing Explained. Beck.
    3. The art of computer programing. Knuth.
    4. Conferencia de Larry Wall en el Tercer Encuentro Regional de Software Libre. Montevideo.
    5. EL bazar y la Catedral. Raymond.
    6. El manifiesto GNU. Stallman.
    VALID HTML 4.01!