Encuesta y libro de Git

6 Septiembre, 2008 a 9:02 · Archivado en Uncategorized ·Etiquetado ,

Sigo con mi aprendizaje y enseñanza simultánea de Git :-) . Hace poco la gente de la lista de correo ha publicado la Git User’s Survey 2008, que está arrojando algunos resultados muy interesantes. Traduciendo del mensaje de la lista de correo con el resumen parcial de los resultados tras las primeras 1000 respuestas, parece ser que:

  • El 59% de la gente que usa Git sabe C, y el 52-53% saben Ruby y/o shell scripting. Le sigue la gente de Python y luego los de Perl. Java tiene un 42% (buenas noticias para los de JGit y EGit). Tcl/Tk está muy bajo, por lo que parece que conseguir contribuidores para gitk va a estar complicado. 12 respuestas no eran ni programadores.
  • Algunos usos interesantes de Git incluyeron:
    • Emplear Git para seguir otros proyectos que usan SVN (lo que hago yo ahora, y es muy cómodo).
    • Sistemas de ficheros versionados.
    • Distribución de materiales / colaboración al redactar documentos.
    • Creación de zonas de pruebas en las que ver exactamente qué hacen los instaladores binarios.
    • Almacenamiento de resultados de pruebas y compilaciones.
  • La mayoría de la gente usa paquetes binarios para conseguir Git (59%), y luego vienen los medio frikis con los paquetes fuente y tarballs (28%) y los muy muy frikis que lo sacan del repositorio directamente (22%).
  • La mayoría de los usuarios de Git trabajan sobre Linux, luego viene MacOS X, y luego Windows. Hay 2 usándolo en iPhone, supuestamente… :-/
  • En cuanto a porcelanas, la mayoría de la gente usa core-git, y si no, o usa sus propios scripts o Easy Git. Si se trata de sistemas de gestión de parches a la quilt, lo que se emplea más es StGIT.
  • En herramientas gráficas vence por goleada gitk y git-gui, pero QGit tiene un respetable 11%. GitNub está ahí, pero parece más un visor para MacOS X de las contribuciones a un repositorio alojado a GitHub que un visor de Git en general. Dicen que JGit y EGit están avanzando, así que a lo mejor vemos integración en condiciones con Git para la edición del año que viene. También se está implementando algo del estilo en KDevelop 4.
  • En interfaces Web, domina gitweb con un 80% (git instaweb y tachán, se entiende), y le sigue Gitorious (14%), que está muy bien si quieres algo estilo forja: es una web, y al mismo tiempo un proyecto de software libre (te puedes descargar su código e instalar tu propia versión, no como GitHub, cuyo código es cerrado). Está cgit por ahí, un CGI hecho entero en C que tiene pinta de ser muy limpio y ligero (6%). Mira, han mencionado Redmine, el que enseñé a la gente del curso de Git.
  • A la gente no le interesaría pagar por soporte comercial, con un rotundo “no” del 69% (y un 22% “no aplicable”).

De todas formas, esto irá cambiando un poco conforme se vayan recogiendo algunas respuestas. Ya hay una parte 2 y una parte 3 de ese resumen, pero no tengo tiempo para traducirlas :-D .

Por otro lado, Scott Chacon está trabajando en un libro de Git que recoge muchos gráficos de gran calidad y sus screencasts, y está pidiendo colaboración de la comunidad. Sólo he tenido tiempo de echarle un vistazo, pero tiene muy buena pinta.

Dejar un comentario

Saxon y XSLT2

6 Septiembre, 2008 a 8:31 · Archivado en Uncategorized ·Etiquetado , , ,

Últimamente estoy trabajando bastante con XLST 2 y XPath 2.0, empleando la biblioteca Saxon (que le da tropecientas vueltas a Xalan, y lo digo por experiencia). La verdad es que se pueden hacer cosas ahora que de otra forma me serían muy complicadas en XSLT 1.0, aunque tiene sus pequeños detalles molestos. El último día me tiré varias horas rascándome la cabeza de por qué una secuencia de elementos que creaba con xsl:for-each de XSLT acababa creando nuevos nodos en vez de utilizar los existentes, haciendo que fallara la prueba de identidad “. is $nodo” (sólo devuelve true si se trata exactamente de la misma copia del mismo nodo).

Es decir, si por ejemplo tengo este bucle que recorre una serie de elementos del árbol XML:

<xsl:for-each select="a|b|c">
  <xsl:sequence select="."/>
</xsl:for-each>

Si queremos recoger los resultados en una variable, uno pensaría hacerlo así:

<xsl:variable name="x">
  <xsl:for-each select="a|b|c">
    <xsl:sequence select="."/>
  </xsl:for-each>
</xsl:variable>

Sin embargo, esto no funciona como es esperado: los a, b y c dentro de x son copias de los originales. Tras mucho rebuscar por San Google, no encontré nada, pero el estándar XSLT 2.0 incluye en su punto 5.7 lo siguiente:

The sequence may be used to construct the content of a new element or document node. This happens when the sequence constructor appears as the content of a literal result element, or of one of the instructions xsl:copy, xsl:element, xsl:document, xsl:result-document, or xsl:message. It also happens when the sequence constructor is contained in one of the elements xsl:variable, xsl:param, or xsl:with-param, when this instruction has no as attribute. For details, see 5.7.1 Constructing Complex Content.

Es decir, que con añadir una declaración de tipo de secuencia a la variable sirve:

<xsl:variable name="x" as="item()*">
  <xsl:for-each select="a|b|c">
    <xsl:sequence select="."/>
  </xsl:for-each>
</xsl:variable>

Para los que no lo sepan, “item()*” indica que tenemos cero o más (“*”) elementos de cualquier tipo (“item()”). Podríamos concretarlo más si nos preocuparan temas de tipado o quisiéramos forzar una cierta conversión (como de entero a cadena), pero en este caso no hace falta.

Dejo esto apuntado por si alguna otra persona tiene el mismo problema que yo (que no lo creo, pero bueno :-D ).

Dejar un comentario

Materiales del curso de Git

12 Agosto, 2008 a 17:53 · Archivado en Uncategorized

Este ha sido un mes muy ocupado :-D . Yendo un poco en secuencia, fui al curso de i-Math de Software Matemático Básico (conocía Octave, pero no Maxima ni SciPy), tuve la presentación de mi PFC (¡ya soy ingeniero!), di un curso de SVN y LaTeX, fui a la International Conference on e-Business 2008 en Oporto junto con Manuel Palomo Duarte para presentar nuestro progreso en Takuan (herramienta de testing de WS-BPEL basada en invariantes dinámicas), y la semana pasada di otro curso, esta vez de Git, en el CADE de Jerez.

En este curso no ha venido tanta gente como con el de SVN/LaTeX, aunque era de esperar, por el lugar en que se celebraba y por la temática: no es ninguna exageración decir que Git es más complejo que SVN :-D . La potencia viene a un precio, evidentemente, aunque parece haber mejorado mucho desde sus versiones anteriores en usabilidad (y lo sigue haciendo).

He preparado algunos materiales, con un guión de ejercicios para los conceptos básicos, apuntes para las operaciones básicas, uso de ramas y colaboración con Git y algunos ficheros de configuración de ejemplo para Apache, reuniendo un pococ lo que he visto aquí y allá. Los he colgado en forma de un repositorio Git en el servicio gratuito de hosting Gitorious. Cualquiera es libre de usarlo como le plazca, siempre que respete la licencia CC 3.0 BY-SA del trabajo: ha de mencionarme como contribuidor y mantener la misma licencia, nada demasiado complicado. Lo podéis clonar con:

git clone git://gitorious.org/curso-git-osluca/mainline.git

Se aceptan críticas constructivas y parches, como siempre :-D . Lo gracioso de Gitorious es que el propio código de la web es también un proyecto de software libre, a diferencia del caso de Github. La experiencia con el segundo quizás sea algo mejor, pero tampoco creo que Gitorious se desmerezca demasiado, y tiene la ventaja ideológica.

Dejar un comentario

Mejorando mi comprensión de Git

10 Julio, 2008 a 20:12 · Archivado en Desarrollo

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.

Dejar un comentario

Usando PAR::Packer y Strawberry Perl en Windows

24 Junio, 2008 a 11:05 · Archivado en Desarrollo ·Etiquetado , , ,

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 .

Comentarios (2)

Mejorando la distribución de los guiones Perl

22 Junio, 2008 a 10:38 · Archivado en Desarrollo ·Etiquetado , , , , , , ,

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.

Dejar un comentario

Vídeo de la entrevista en Onda Cádiz

7 Junio, 2008 a 20:17 · Archivado en Eventos ·Etiquetado , ,

Tal y como comenté en un post anterior, la semana pasada me hicieron una entrevista en Onda Cádiz, en la que sin duda metí la pata alguna que otra vez :-D . En fin, ya se ha transmitido, y lo he subido tan pronto como he podido. No está entero: tenía un cron con un script para grabar pero me falló =X, y tuve que tirar de la grabadora normal y corriente.

Perdón por la calidad, pero es que ha pasado por cuatro conversiones: TV->HD,HD->DVD, DVD->AVI, AVI->Google Video. No es de extrañar.

Comentarios (1)

DokuWiki al poder

1 Junio, 2008 a 0:22 · Archivado en Desarrollo ·Etiquetado , ,

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 .

Dejar un comentario

Entrevistas en Canal Sur y Onda Cádiz

29 Mayo, 2008 a 16:21 · Archivado en Eventos

La semana pasada recibí entre el miércoles y el jueves a través de mis profesores y la dirección de la Escuela Superior de Ingeniería llamadas para ir a entrevistas en Canal Sur y Onda Cádiz.

La entrevista a Canal Sur fue la semana pasada (jueves) y fue algo rápido e informal. Quedamos en el CASEM del campus de Puerto Real y fue cosa de 20-30 minutos. Creo que tiene que haber salido ya, pero estoy hasta arriba de exámenes y trabajos y me temo que he acabado perdiéndomelo. Tendré que llamarles :-X.

Por otro lado, hoy tuve la entrevista en Onda Cádiz. Tenía poco tiempo y tuve que atrasarla una semana, ya que perder una mañana para ir a la Zona Franca me habría supuesto un buen disgusto, con tanto trabajito y presentación :-D . Ha sido un placer, la verdad. He tenido cosa de 25-30 minutos para hablar del Concurso, de software libre, de estándares abiertos y (cómo no) de XMLEye. A ver si esta vez me he explicado lo bastante sencillo como para que alguien entienda para qué sirve en pocas palabras y sin muchos tecnicismos.

Seguramente habrá fallos e incorrecciones en más de una cosa: mencioné a los ganadores pero no a los finalistas por falta de tiempo, y me equivoqué al decir que Juan Pedro (autor de Psychosynth) era de la universidad de Sevilla y no de Granada. Espero que no os ofendáis :-X.

Bueno, estaré pendiente a ver si consigo grabar esta entrevista. Saldrá el 6 de junio alrededor de las 21:00 horas. Se puede ver Onda Cádiz por internet a través de esta dirección.

Comentarios (1)

¡Primer premio!

9 Mayo, 2008 a 22:20 · Archivado en Uncategorized

Bueno bueno, acabo de volver de la fase final del Concurso, donde he tenido el gustazo de recibir el Primer Premio en la categoría Educativa. Quitando que el dinero es bienvenido, cómo no :-D , me alegra mucho que se reconozcan los esfuerzos de todos nosotros, que es lo realmente importante.

Me gustaría agradecer a todos los demás finalistas, a los organizadores y a todos los involucrados por dejarme pasar unos dos días fantásticos con mucho frikeo ubuntero, debianero y demás. La visita a los jardines del Real Alcázar se aguó un poco, pero fue muy bonita de todas formas.

Felicidades a todos los demás, que todos somos premiados. Empezando por Psychosynth, que dan ganas de tontear con él sólo de verlo :-D , y que no me extraña que sea el premiado en absoluto. Y siguiendo con el robotito R4P (espero que resolváis el problema con los horns de los servos, y poned fotos de la versión negra), Minirok (Dato, eres de GNOME en el fondo, lo sé ;-) ), Pigmeo (sigo pensando que aunque no es prioritario, se debería poner la creación de un simulador en un documento por si alguien se siente dispuesto a echar el rato), y Zenphp (se nota de dónde viene el nombre al hablar con el autor).

Un recuerdo también a las menciones, en particular Pleim, de mi misma universidad, que por desgracia no se pudo pasar, y a los de Pro Evolution Chapping, con un juego peligrosamente adictivo. Pero por favor, entrenad un poco más y no os metáis tantos goles en propia puerta :-D .

¡Suerte a todos en vuestros proyectos a partir de ahora!

Comentarios (3)

« Entradas más recientes · Entradas más antiguas »