Robots y modelos

Notas sobre pruebas, modelado y aventuras en Java y Android

Archive for the ‘Desarrollo’ Category

Mis impresiones del Apache Barcamp Spain 2012

with 6 comments

Ayer tuve la oportunidad de asistir al Apache Barcamp Spain, que se celebró en la Escuela Técnica Superior de Ingeniería Informática de Sevilla. Por cierto, no la visitaba desde el II Concurso Universitario de Software Libre, y me alegró ver otra vez a Ana Rey, una de sus organizadoras. Iba desde Cádiz junto con Francisco Pérez (fundador de CadizDevelopers y conductor del coche compartido), Cayetano Soriano (antiguavíctima alumno y sufrido organizador de las Betabeers de Cádiz) y Francisco Peregrino (no estoy seguro del apellido: ¡perdona si me equivoco!).

El evento comenzó pasadas las 10:00, con una presentación general del evento y los patrocinadores:

  • BitNami, que además de proporcionar instaladores fáciles con pilas de tecnologías comunes como WordPress, Joomla, Drupal o Redmine, tienen su propia infraestructura cloud por si nos queremos ahorrar montar y mantener el servidor. La verdad es que no sabía que eran españoles, y daban unas camisetas muy simpáticas, por cierto ;-).
  • CodeBusters, una empresa de consultoría sevillana basada en código abierto con mucha gente de la Apache Software Foundation.
  • Deiser, a los que les debo la entrada (tardé demasiado y se acabaron las entradas :-S). Se especializan en soluciones para desarrollo ágil y cooperativo, con plugins para Sparx Enterprise Architect y Atlassian JIRA entre otras cosas.
  • Koliseo, el proveedor de venta de tickets utilizado para la Barcamp.
  • Novayre, una empresa que trabaja mucho con las líneas de arquitecturas orientadas a servicios y procesamiento de eventos complejos que tenemos en el grupo. Novayre también participó en la organización de Sistedes 2012, un evento académico al que asistí esta misma semana. Tuve el placer de conocer a su director gerente Víctor Ayllón en la cena de gala de Sistedes 2012, y me comentó muchas de las prácticas punteras que tienen en Novayre. Pude coincidir con él ayer también y conversar un rato más.
  • Zaizi, integrador premiado de Alfresco, de Ephesoft y de eXo.

Algunos de los colaboradores del evento fueron la gente de Klicap, los desarrolladores de Clinker, un ecosistema virtualizado de desarrollo de software que estamos evaluando en la Universidad de Cádiz, y de cuyas imágenes he aprendido un par de trucos que he adaptado a los servidores que llevo manualmente :-). Tuve la oportunidad de desvirtualizar a Manuel Recena, uno de sus desarrolladores principales, y se ve que van a toda vela con el proyecto.

Desconocía la organización de los Barcamp, y me ha parecido curiosa en tanto que era bastante distinta de las usuales conferencias. Al registrarte en la entrada, te daban una tira de pegatinas y una ficha de póquer. En el acto de apertura se presentaron todos los candidatos para dar charlas, y la gente usó sus pegatinas para votar a las ponencias que más les interesaran. A continuación, las ponencias se filtraron y ordenaron por votos y se dividieron en tres tracks paralelos.

Tras el primer “coffee break” del día (en una sala algo apretada para mi gusto, he de decir), asistí a estas ponencias:

  • Una introducción a CoffeeScript, un lenguaje traducible a JavaScript que evita muchos de sus problemas y es en general mucho más fácil de leer y escribir. Me pareció muy interesante el enfoque general, y el lenguaje parece bastante más cómodo que JS. Una cosa simpática es que la forma en que implementa el ámbito léxico de las variables consiste básicamente en crear clausuras que envuelven a la variable original. La gente preguntó bastante cómo integrar CoffeeScript con código JavaScript ya existente, pero viendo que al final se compila a JavaScript no creo que haya mucho problema.
  • Herramientas de desarrollo web, en que el ponente explicó muchas funcionalidades ocultas (por lo menos, lo eran para mí) de Chrome útiles para desarrolladores web, contó de qué iban LESS y SASS (lenguajes compilables a CSS que facilitan ciertas cosas y ayudan a respetar el principio DRY) y enseñó algunas de las cosas que puede hacer Sublime Editor. Sublime es el editor de moda, y reconozco que está bastante bien para ciertos lenguajes. Para Java, sin embargo, sigo creyendo que las mejores opciones son Eclipse (por su extensibilidad) e IntelliJ (por su pulido e “inteligencia”). Además, ambas son de código abierto (aunque IntelliJ tiene extensiones “premium”).
  • BDD con JavaScript, en que el ponente enseñó cómo hacer BDD con los frameworks Jasmine y Casper sobre una aplicación que ayudaba a usar la técnica Pomodoro(que desconocía), y anunció que publicaría algunos de sus componentes como código abierto.Aunque la charla estuvo bien, la vi demasiado centrada en código. En particular, Jasmine me pareció que mezclaba el código con la historia: por lo que he visto, Cucumber parece mantener una mejor separación entre la historia de usuario y la prueba en sí. Casper provee un navegador automatizable sin interfaz: Cayetano me mencionó ZombieJS, otro entorno parecido a Casper, y Behat, que parece el equivalente de Cucumber en PHP. Discrepo de su afirmación de que BDD sea lo mismo que TDD: para mí, uno se centra en historias de usuario (y produce pruebas funcionales o de integración), y otro en unidades específicas de código y su comportamiento esperado. En mi opinión hacen falta ambos, ya que puede haber “corner cases” que sean difíciles de probar con historias, y una prueba unitaria no cubre tanto código como una historia.

Aquí paramos y nos fuimos a almorzar al Sloppy Joe’s que había cerca. Si vais, recordad que la “pizza pequeña” es para 2 y la “mediana” supongo que para 3 :-D. El resto de ponencias (con otro “coffee break” intercalado tras la primera) fueron:

  • Git avanzado: antes de seguir, he de decir que he dado unos cuantos cursos y talleres de Git por mi cuenta, y que tengo materiales y enlaces por aquípara el que los necesite ;-). En este taller enseñaron cómo replantear una rama en base a otra (“rebase” y su versión interactiva), las dos formas básicas de reunir ramas, con “fast-forward” o una nueva revisión de reunión (“merge commit”) y los diversos tipos de “reset” (blando, duro y mixto). También hablaron un poco del modelo interno de datos de Git y detallaron algunas cosas como que git-foo se convierte a “git foo” si está en el PATH. La idea de poner el log debajo para que se vean los cambios de HEAD y las nuevas revisiones me pareció muy buena.Dicho todo esto, considero que el título de “Git avanzado” es un tanto discutible. No me imagino a un usuario de Git que no tenga que hacer reuniones de ramas o replantear ramas en base a otras, por ejemplo. De todos modos, entiendo que con las restricciones de tiempo disponibles era lo mejor que se podía hacer. Supongo que “Git básico” no tendría el tiempo suficiente para ver esos conceptos. Como usuario común de Git, me habría gustado mucho que discutieran algunas cosas más recientes, como “git notes”, o algo más ocultas, como “git add -i”, “git grep”, “git bisect”, “git mergetool”, o “git bundle”.
  • Karmacracy: esencialmente, fue un caso de estudio en que explicaron cómo habían conseguido que Karmacracy escalara a millones de peticiones utilizando las tecnologías cloud de Amazon. Fue bastante interesante ver todo lo que Amazon tenía que ofrecer, y cuánto costaría en un despliegue típico. Otro aspecto importante fue que Amazon no te da esa escalabilidad mágicamente: aprovecharlo exige mucho diseño previo y planificación.
  • Push & Pull: en esta charla se describieron las distintas tecnologías que se habían estado usando para pasar del típico modelo petición->respuesta del paradigma cliente-servidor a una comunicación bidireccional en que tanto el cliente pudiera solicitar información en un momento dado (“pull”) como que el servidor le enviara notificaciones sin esperar a que el cliente las pidiera (“push”). Mencionó el antiguo sistema basado en consultas periódicas (“polling”), los plugins de navegador (Java y Flash), el “long polling” de Comet, los “server-sent events” de HTML5 y los Web Socketsde HTML5, comparando las ventajas y desventajas de cada uno.A nivel didáctico me gustó mucho la charla, pero habría preferido aligerar la discusión de las alternativas y enseñar con un ejemplo sencillo cómo se utilizarían los Web Sockets a nivel de código. Un detalle simpático fue su comentario de que los Web Sockets funcionaban especialmente bien a través de SSL, ya que los cortafuegos no se molestaban en analizar los paquetes cifrados y no destrozaban las comunicaciones como lo hacían con el puerto en claro.

Tras las charlas, volvimos al salón de actos y votamos con nuestra ficha de póquer a la que pensamos que fue la mejor charla del evento. Ganó la de “Push & Pull” merecidamente, aunque personalmente voté a la charla de CoffeeScript. Y tras una foto de grupo, de vuelta a Cádiz: ya estábamos cansados y había mucho que hacer, así que no pudimos asistir a la fiesta tras el evento.

El Barcamp de este año me ha gustado mucho, he aprendido muchísimo y he tenido oportunidad de encontrarme y reencontrarme con mucha gente interesante (¡hola Moisés!). Si tuviera que poner una pega, diría que fue la calidad de la aplicación Android: la lista de ponencias muchas veces salía vacía a menos que se actualizara mediante un botón Actualizar sólo accesible con la tecla menú (que no aparecía en mi Nexus 7), y en otros casos era imposible deslizar la lista a la derecha para ver las otras “tracks”.

Pero vamos, en resumen: que si el Barcamp vuelve el 2013 cerca de Cádiz o en Madrid, contad conmigo :-).

Anuncios

Written by bluezio

23 de septiembre de 2012 at 15:54

Publicado en Desarrollo, Eventos

Eclipse Commiter en Epsilon

leave a comment »

Me alegra decir que acabo de entrar como Committer en el proyecto Epsilon de Eclipse GMT. La verdad es que llevaba desde verano del 2009 contribuyendo pequeños cambios para cubrir fallos que me encontraba y necesidades que tenía.

Ahora estoy de estancia en la University of York con los desarrolladores de Epsilon (Dimitris Kolovos y Louis Rose), realizando una contribución más grande, y decidieron invitarme al proyecto. La verdad es que está siendo muy interesante y están saliendo cosas curiosas. Estoy ocupado desarrollando EUnit, un marco de pruebas unitarias para temas de modelos, basado en Epsilon. Tengo en la cola de prioridades un artículo acerca de él: cuando tenga algo más definido, hablaré un poco más de EUnit por aquí.

Por lo pronto tengo 50 commits que limpiar y subir al SVN de Eclipse :-D. Por supuesto, estoy usando git-svn: es una alegría ver que puedes replantear tus 50 últimos commits limpiamente sobre los últimos cambios de Dimitris y Louis en SVN.

Written by bluezio

18 de abril de 2011 at 15:09

Publicado en Desarrollo

Tagged with , , , ,

Smart HTTP de Git y Redmine

with 5 comments

Actualmente estoy preparando la actualización de un servidor Redmine que gestiono. Es una actualización bastante grande: no es sólo cuestión de actualizar la instancia Redmine, sino todo el sistema y herramientas de apoyo. Lleva demasiado tiempo sin tocarse y tiene una distribución antigüilla.

Una de las cosas que quería añadir en el servidor actualizado (junto con Redmine 0.9.2, la última versión estable a fecha de hoy) era soporte integrado con Git. Sin embargo, hay un problema, conocido por todos los usuarios de la red de la Universidad de Cádiz: el cortafuegos cierra el paso a prácticamente todo salvo correo y HTTP (y ocasionalmente HTTPS). Por eso, muchos de los protocolos que admite Git están fuera de la cuestión: el propio de Git (que de todos modos no serviría para los push), SSH (como lo proponga le da un patatús al CITI) y rsync (en desuso).

Git ha permitido el uso de HTTP y HTTPS desde hace tiempo sobre WebDAV, al estilo de Subversion, pero nunca me ha gustado este método. Además de sus problemas de rendimiento, de no poder usar “hooks” (manejadores de eventos) y de las molestias que origina (hay que meter un trabajo cron que ejecute “git update-server-info” periódicamente en cada repositorio), tiene una pega gravísima: la consistencia del repositorio está a completa merced de todos y cada uno de los clientes que acceden al repositorio.

Cuando di mi primer curso de Git en 2008, algunos de los asistentes me dijeron tajantemente que ni hablar de activar SSH en sus máquinas, así que probamos el acceso por HTTP. Curiosamente, el primer día que lo probamos y estuvimos mandando commits en rápida sucesión, se corrompió el repositorio varias veces. Al siguiente día, no se corrompió en absoluto, y le estábamos mandando cosas incluso más rápido que antes. Pero entonces llegó uno de los asistentes que faltaba, y dicho y hecho: a los pocos minutos estaba corrompido. El origen del problema: la versión de Curl del asistente que había venido (único usuario de MacBook en la sala, jeje) era antigua. Cuando Git trabaja sobre WebDAV, el servidor HTTP sirve de poco más que de un área de subida de ficheros. Si la versión de la biblioteca curl instalada en el cliente tiene fallos, éstos repercutirán en el repositorio (como con Curl 7.16.0). Ah, y por supuesto no hay nada de atomicidad: si el usuario pulsa Ctrl+C en mitad de la actualización o se le va la conexión, puede que el repositorio también se quede en un estado inconsistente.

Por estas razones, descarté incluso HTTP/HTTPS, y no metí Git en la instalación actual de Neptuno. Todo se quedó en una instalación de Gitosis en mi servidor doméstico. Sin embargo, Git 1.6.6 incluye “smart HTTP“, que arregla los problemas de rendimiento, llama a los “hooks”, evita la necesidad del trabajo cron con “git update-server-info” y proporciona las mismas garantías de atomicidad que el acceso por SSH. El “truco” es que ya el servidor HTTP no es una tonta área de almacenamiento WebDAV, sino un CGI que implementa los servicios que usualmente se invocan mediante SSH a través de HTTP. Lo bueno de todo esto es que además, al ser HTTP, podría integrarlo directamente con el esquema de autenticación de Redmine, con lo que un proyecto público admitiría fetch anónimo pero limitaría los push a los miembros con derecho a commit, y un proyecto privado exigiría los derechos apropiados para tanto fetch como push. La única “pega” es que hay que tener Git 1.6.6 como mínimo tanto en el cliente como en el servidor, pero bueno, los verdaderos usuarios de Git se lo compilan desde las fuentes, que no es tan difícil ;-).

Sin embargo, esta configuración de Apache que combina las instrucciones del CGI con una variación de la propuesta en la web de Redmine no sirve directamente:

SetEnv GIT_PROJECT_ROOT /var/www/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
PerlLoadModule Apache::Authn::Redmine
<Location /git>
  Order deny,allow
  Allow from all

  PerlAccessHandler Apache::Authn::Redmine::access_handler
  PerlAuthenHandler Apache::Authn::Redmine::authen_handler
  AuthType Basic
  AuthName "Redmine Git Repository"
  Require valid-user

  RedmineDSN "DBI:mysql:database=databasename;host=my.db.server"
  RedmineDbUser "usuario"
  RedmineDbPassword "contraseña"
</Location>

Cuando lo probé, no podía crear clones de forma anónima de un proyecto público: tenía siempre que introducir contraseña. Además, tampoco podía hacer push en un proyecto público, por mucho que pusiera la contraseña. La explicación es algo larga, pero es interesante (y me llevó unos buenos tirones de pelos y media mañana :-/). Está dividida en dos partes:

  • El hecho de que fallaran los clones anónimos es que el manejador de autenticación de Redmine, pensado para WebDAV como está, distingue las acciones de “sólo lectura” (las que pueden hacerse de forma anónima en proyectos públicos y que no requieren derechos de escritura para los miembros de proyectos privados) del resto a través de sus métodos HTTP. Por omisión, estos métodos son GET, PROPFIND, OPTIONS y REPORT: por definición, no deberían producir cambios en los recursos a los que acceden. Sin embargo, al hacer “fetch” con smart HTTP de Git se hace una petición POST al servicio git-upload-pack, y hace que pida contraseña: nos quedamos sin fetch anónimo.
  • El segundo problema se debe a que git-http-backend, el CGI necesario en el servidor para “smart HTTP”, obliga por omisión a que todos los push (peticiones al servicio git-receive-pack)  tengan algún tipo de autenticación. De lo contrario, los rechaza con un código de error 403 (Forbidden). Y aquí volvemos con el problema de distinguir las acciones por los métodos HTTP: el servicio git-receive-pack se utiliza en dos fases. La primera fase es un GET a /git/repositorio/info/refs?service=git-receive-pack: git-http-backend exige autenticación, pero el manejador de Redmine no se la pide al usuario, ya que es un método de sólo lectura. Resultado: un bonito Forbidden (403) para cualquiera que quiera hacer push. Los tirones de pelos en este lado vienen de que Git, al ver que el push por smart HTTP no ha ido, asume que el servidor es de tipo WebDAV, y hace más peticiones que hacen más difícil encontrar el problema. Actualización 14/03/2010: puede que en dentro de poco se deje de pedir contraseña para el GET.

¿Cómo corregir esto? Pues haciendo que el manejador de Redmine distinga las peticiones “de sólo lectura” del resto no por método HTTP, sino por dirección, tal y como viene en la página man del CGI (segundo ejemplo de configuración de Apache). Podría haber desarrollado un nuevo manejador de autenticación, pero duplicaría todo el código salvo en un par de sitios. He preferido añadir una nueva directiva que activa este comportamiento, que por omisión está deshabilitado: RedmineGitSmartHttp. Para usarla, pondríamos esta línea dentro del anterior <Location /git>:

RedmineGitSmartHttp yes

y ya todo debería ir sin problemas. Esto no afectará a los bloques <Location /svn> que tengamos en otra parte: se usan instancias distintas del manejador de autenticación, y esas instancias no tendrán esta opción activada, por lo que mantendrán el antiguo comportamiento. Bueno, por lo menos así me ha funcionado en mi servidor de pruebas y así lo indican sus registros :-D. He probado con proyectos públicos y no públicos en SVN y Git en el mismo Redmine y ha ido bien.

Para aquellos interesados en el código, he enviado un parche al proyecto Redmine, para que lo fusilen revisen más y mejores ojos que los míos. A ver qué tal lo reciben. Para aplicarlo, hay que descomprimir las fuentes de Redmine, poner el parche en su directorio principal, y ejecutar esto:

patch -p1 < 0001-Redmine.pm-add-Git-smart-HTTP-support.patch

Un último detalle: Git necesitará nuestro usuario y contraseña para autenticarse. Una opción es clonar con http://usuario@host/git/repositorio, poniendo el usuario en la URL y metiendo la contraseña cada vez que haga falta, pero es muy incómodo: por desgracia, no guarda las contraseñas automáticamente como hace SVN. Otra opción es crear un fichero ~/.netrc (¡sólo legible por nuestro usuario!) con nuestro usuario y contraseña:

machine mihost
login miusuario
password mipassword

No me termina de gustar eso de tener mi contraseña guardada en la máquina, pero bueno, ya pasaba con SVN, así que supongo que es el precio a pagar por no tirar de SSH :-/.

Written by bluezio

24 de febrero de 2010 at 9:50

Publicado en Desarrollo

Tagged with , , , ,

Mejorando mi comprensión de Git

leave a comment »

Aleluya, creo que ya entiendo mejor Git, gracias a la fantástica charla “Getting Git” en RailsConf 2008 de Scott Chacon. En ella explica (y muy bien) los detalles internos de Git, y qué le diferencia de Subversion: cuando me fijé en que podía borrar commits y cosas del estilo, que las revisiones no eran secuenciales sino que usaban hashes SHA1 y que podía cambiar “mágicamente” de rama me quedé tan sorprendido en su momento que no llegué a entender un pimiento del resto :-D, y eso que me miré los dos Google TechTalks de Git.

Ahora que veo que se trata de un sistema basado en una base de datos de objetos agrupados en un grafo, y que los tags, ramas y etiquetas son sólo punteros a nodos raíz de subgrafos suyos lo entiendo mucho mejor. Bueno, supongo que a alguien que no conociera Subversion y fuera directamente a Git no le chocaría, pero no me gusta usar una herramienta sin entender por lo menos la idea general.

Lo siguiente en la lista es git-svn: la verdad, me daría pena dejar la forja de RedIris para el desarrollo de XMLEye. Podría usar el espacio de github.com, pero entonces ya no tengo el área de ficheros, y todo el tema de tickets. Me pregunto si hay algo parecido a Trac para Git, sería el remate. También quiero curiosear sobre la orden cherry-pick de Git.

Written by bluezio

10 de julio de 2008 at 20:12

Publicado en Desarrollo

Usando PAR::Packer y Strawberry Perl en Windows

with 2 comments

Todos los días se aprende algo. Hoy he aprendido que tirarme hasta las 5 de la mañana peleándome con camelbox, ActivePerl, y Strawberry Perl para que funcionara PAR::Packer como $DEITY manda ha sido una gran pérdida de tiempo, y que habría sido mucho más productivo simplemente dormir :-D.

Como ya dije en el post de ayer, estuve mirando cómo mejorar la distribución de los conversores, para que el “usuario medio” no tuviera que ser “usuario que sabe instalar un entorno Perl, tirar de CPAN y llevarse un dolor de cabeza con los fallos que le salgan”. En los entornos UNIX está todo muy depurado y PAR::Packer y PAR funcionan de maravilla a la primera, pero en Windows la cosa no está tan clara.

Primero probé con ActivePerl, que con los repositorios PPM de Uwinnipeg y Bribes quedaba bastante completo. Pero por alguna razón, no incluía bien un fichero que instalaba con install_share. Con ActivePerl me pasé varias horas, y luego probé con Strawberry Perl, en sus versiones 5.8 y 5.10 de Perl, y tenía fallos al instalar desde CPAN. Otras tantas horas. Y luego, cómo no, probé con camelbox, y una vez más con Strawberry Perl. Ya me caía de sueño y harto de mirar en listas de correo y bug trackers, me fui a dormir. (Por cierto, el nombre de Strawberry Perl viene por que es una mejora sobre el Vanilla Perl. Un batido fresquito no vendría mal ahora, no señor…)

Hoy me levanto y me acuerdo de un post de ayer que decía algo de que el fallo que yo encontraba “estaba arreglado en trunk”. Trunk, ¿de qué? Pues trunk del SVN de PAR::Packer, que aunque en el $VERSION de Packer.pm decía 0.980, no era el 0.980 de CPAN que me había dado tantos dolores de cabeza. Strawberry Perl 5.10, PAR::Packer del SVN, sin problemas. Todo instalado y funcionando como la seda.

Qué momento más agridulce de mi vida :-D. Bueno, para la próxima me voy a dormir y consulto con la almohada.

Una cosa: al llamar a pp para generar un EXE en Strawberry Perl, no hace falta darle el –gui para evitar que aparezca una ventana de consola. De hecho, si se lo damos nos quedamos sin stdout y stderr :-/. Es buena idea usar ‘-r’ para pruebas, y con la opción ‘-I blib/lib’ nos aseguramos que los ficheros que instala File::ShareDir aparezcan en los PAR. También es buena idea, y no hace daño, añadir “-M PerlIO”: en ActivePerl daba problemas si no se incluía. Dejo esto apuntado por si alguien con mis problemas busca por Google :-D.

Written by bluezio

24 de junio de 2008 at 11:05

Publicado en Desarrollo

Tagged with , , ,

Mejorando la distribución de los guiones Perl

leave a comment »

Estos días he estado curioseando sobre la forma de facilitar un poco la distribución de los conversores ACL2->XML y YAML->XML. Es cierto que ACL2::Procesador está mucho mejor que antes del Concurso, ya que al cambiar a una estructura basada en los módulos de CPAN, con un instalador creado mediante Module::Install, ahora se instalan todas las dependencias automáticamente al seguir estos pasos:

perl Makefile.PL
sudo make
make test
sudo make install

Esto le resultará muy familiar a cualquiera que haya compilado e instalado un proyecto de las autotools, pero hay un problema: CPAN no es a prueba de bomba, y el “sudo make” instalará no sólo los paquetes necesarios para ejecutar ACL2::Procesador, sino también los que hacen falta para compilar y depurar el módulo. Además, dos de estas dependencias de compilación son módulos XS, con lo que necesitan un compilador C, además de las bibliotecas y cabeceras que utilizan: libxml2 y libexpat. Para un desarrollador tampoco es gran cosa, pero pedir esto a un usuario medio… pues como que no es muy realista.

Con los paquetes Debian se facilita mucho la cosa, claro, pero ¿y si no estamos bajo una distribución basada en Debian, como openSUSE? ¿O si estamos en Windows? Algún usuario potencial en Windows habrá: al fin y al cabo, estoy usando Perl y Java, que por ir tendrían que ir como mínimo en Mac OS X también. No es cosa de cerrarme en banda, tampoco.

No tengo tiempo de hacer paquetes para todo lo habido y por haber, eso está claro. Pero simplificar se puede simplificar. Module::Install tiene dos módulos llamados Module::Install::Bundle y Module::Install::Include que supuestamente permiten incluir en las distribuciones de código las dependencias, pero no me funcionan en absoluto, la verdad.

Donde sí he tenido una grata sorpresa es con los módulos PAR y PAR::Packer. Cualquiera que haya utilizado Java y visto el acrónimo tendrá una idea (JAR = Java ARchive, PAR = Perl ARchive), me imagino. PAR permite crear ficheros .par que agrupan todos los módulos no estándar y bibliotecas necesarias para que nuestro program Perl funcione. Tras instalar PAR y PAR::Packer, ejecutaremos esta orden para crear el .par:

pp -p -o acl2-proc.par script/pprocACL2

Y ejecutarlo sólo requiere el módulo PAR (que es relativamente ligero, y en las Debian se halla disponible como libpar-perl) y Perl:

perl -MPAR acl2-proc.par (fichero Lisp raíz de la demostración)

Más fácil todavía: si no ponemos el -p, se crea no un .par, sino un ejecutable completamente autocontenido, que puede distribuirse sin necesidad de que el usuario instale nada previamente. El único problema es evidentemente el tamaño del ejecutable: pasamos de un .par de 75KB a un fichero de ~2.7MB. Esto es más interesante para la gente de Windows, sobre todo.

Obviamente, los .par son específicos de la plataforma en cuanto usemos un solo módulo que no sea Perl puro. Para ACL2::Procesador no es un problema, pero YAXML::Reverse sí que usa la biblioteca libyaml. Se pueden crear .par multiplataforma, acumulando los resultados de cada plataforma sobre el mismo .par, así:

pp -m -o yaxml.par script/yaml2xml

La verdad es que distribuir un fichero .par y poder olvidarte de CPAN es una alegría, qué más decir. Incluso existe la posibilidad de distribuir un único guión Perl y hacer que se “traiga” e instale el PAR de un repositorio bajo una URL, con el módulo PAR::Repository::Client, pero este módulo es bastante pesado: quizás sea conveniente para redistribuir código entre muchas máquinas que manejemos, pero no tanto para instalarlo en una máquina del usuario.

Mi idea es reunir en varios .tar.bz2 versiones de los conversores que puedan descomprimirse directamente sobre el directorio donde tengamos XMLEye, y que incluyan los .par o ejecutables monolíticos, los descriptores de formato y las hojas de estilo. Así resultará mucho más cómodo que como está ahora.

Written by bluezio

22 de junio de 2008 at 10:38

Publicado en Desarrollo

Tagged with , , , , , , ,

DokuWiki al poder

leave a comment »

Bueno, ya me he montado un DokuWiki en mi propio dominio, sobre el que intentaré ir dejando la suficiente documentación y manuales en inglés y/o español (según el tiempo que tenga) antes de empezar a rondar por listas de correo y tratar de picar el gusanillo de alguien, aunque sólo sea como usuarios.

Me gusta bastante por lo pronto: es muy sencillito pero muy flexible a la vez. Me ha dado algunos quebraderos de cabeza la instalación con el safe_mode de PHP y un bug de DokuWiki (¿alguien sabe para qué es esa función fullpath en PHP? ¿Existe, o sólo está realpath?), pero al final creo que ha quedado bastante bien.

El wiki está aquí: http://wiki.shoyusauce.org, por cierto. Ya lo iré rellenando durante estos días.

En fin, además de esto tengo aún pendiente terminar de traducir el código a inglés y buscarme un sponsor para mis paquetes, que habrá que pasar de Ubuntu a Debian. Hay trabajo de sobra para este verano :-D.

Written by bluezio

1 de junio de 2008 at 0:22

Publicado en Desarrollo

Tagged with , ,