Lo mínimo imprescindible para controlar código fuente con subversion

He realizado una presentación para ayudar a un pequeño cursito sobre subversion que voy a dar en breve. Así que publico aquí las transparencias que quizás pueden ser de utilidad para alguien. Está fuertemente inspirado en el manual Version Control with Subversion y concretamente en el apartado del ciclo básico de trabajo con svn con algunos añadidos de gráficos, buenas prácticas, programas auxiliares y algunos enlaces básicos. Por cierto, gracias a Juanjo que le ha echado un vistazo y ha detectado alguna carencia.

Sistemas de control de versiones. Introducción a svn

View more presentations from miguelolivan.

El título de la presentación es "Sistemas de control de versiones. Introducción a subversion" aunque me gustaría más haberlo titulado como este post, "Lo mínimo imprescindible para controlar código fuente con subversion" o como posibles títulos alternativos, dado el público al que va dirigido "Subversion para programadores ocasionales" o "Control de código fuente para científicos". A ver si entre todos podemos hacer que los científicos programen mejor. En beneficio de todos :)

El código fuente como documento definitivo del diseño

Se trata, cómo no, de Code as Design: Three Essays by Jack W. Reeves. Son unos ensayos muy ilustrativos de la naturaleza particular del desarrollo de software, que por usar la palabra diseño de un modo no usual acaban resultando muy polémicos, pero a mi me parecen más bien esclarecedores. Se recomienda leer enteros antes de opinar :P

Suelo aprovechar cualquier mención para volver a enlazarlo y esta vez ha sido Ricardo Galli en "Los problemas derivados del abuso de las analogías" quien me da la oportunidad de volver a hacerlo :)

Se ha hablado de ellos por aquí en El código fuente visto como diseño y POO, el código como diseño y más cosas.

La misma entrada y más comentarios en El código fuente como documento definitivo del diseño en barrapunto

Un vistazo al código de chrome

Una de los aspectos que más me ha interesado de chrome es su arquitectura, aquello de ejecutar un proceso por pestaña para dejar que el sistema operativo haga unos de los trabajos para los que está diseñado: aislar procesos independientes y gestionar la memoria. Entonces he decidido a echarle un vistazo al código, que para eso está ahí ;)

Lo primero que hay que decir es que el IPC se hace mediante pipes con nombre, como parece que debería ser, aunque sea una de esas características de los SO en decadencia, o por ser más preciso, menos de moda. El documento que describe el IPC en chromium es escueto así que he hecho una inmersión en el código, aunque superficial, sobre todo para encontrar detalles de implementación. Los mensajes se gestionan con una clase ChannelProxy (definida en src/chrome/common/ipc_channel_proxy.h) Las pipes se gestionan con la clase Channel (mismo directorio, icp_channel.h) Curiosamente está implementada llamando directamente a la API de win32, ella misma hace de capa de abstracción y de interfaz a implementar.

Otro aspecto que me llamaba mi curiosidad es la serialización de los mensajes y lo hacen especializando Read, Write y Log de ParamTraits (en src/chrome/common/ipc_message_utils.h) a la estructura o tipo de dato en concreto. La serialización los tipos de datos primitivos están en Pickle (src/base/pickle.cc), que es base de Message (src/chrome/common/ipc_message.cc)

Como uno de mis intereses es la multiplataforma he buscado como solucionaban la gestión de threads y procesos. Acerca de los threads se han creado un interfaz sencillo en src/base/platform_thread.h con dos implementaciones, platform_thread_win.cc y platform_thread_posix.cc. Cabe destacar el siguiente comentario de este último fichero:

The POSIX standard does not provide for naming threads, and neither Linux
nor Mac OS X (our two POSIX targets) provide any non-portable way of doing
it either. (Some BSDs provide pthread_set_name_np but that isn't much of a
consolation prize.)

Que creo que dice algo de su política y no se si gustará mucho a los BSDros... El buceo por la gestión de procesos ha sido un poco decepcionante porque sólo existe un process_util::LaunchApp que básicamente llama a un CreateProcess de nuevo de la API de win32. Seguramente han ido pensado previamente en los interfaces y solo están a falta de la implementación en distintas plataformas, pero da una sensación de trabajo a medias, quizás reflejo de un proyecto real (en contraposición de una prueba de concepto) saliendo de su fase temprana. Cabe preguntarse cuanto les costará implementar y testear esas funcionalidades... Ah, calla, que somos millones los betatesters.

(Actualización) Un tímido buceo en src/net/base me dice que el código de red es muy windowscéntrico, con muchas inclusiones de winsock2.h, incluso en cabeceras :/ aún les queda trabajillo por delante. Los interfaces de las clases parecen bien definidos y eso les ahorrará trabajo, pero es bien sabido que un interfaz no es válido y está maduro hasta que no funciona en todas la plataformas a las que se dirige...

Uhmmm, acabo de ver un enlace de donde se baja las fuentes que se suponen del desarrollo en linux. Seguiremos informando, pero ya sólo esta distinción de obtención de fuentes no da buena espina...

(Actualización2)Ya lo he bajado pero es básicamente el mismo código. Me debo estar perdiendo algo, porque sino está muy verde...

(Actualización3) Leo en kriptópolis que Chrome usa CSP en lugar de PKCS :O No hay rastro de ningún PKCS (11 por ejemplo, el que usa El DNIe) ni de NSS (la librería criptográfica de Netscape que usa firefox) Me temo que la portabilidad no se la han tomado en serio o quieren que se la hagan otros... Alucino.(fin actualizaciones).

Desde el punto de vista gráfico he visto que tiene muchas de dependencias de la WTL, lo que dice también poco de la portabilidad en primera instancia. Ya veremos a ver como solucionan ese temilla, aparentemente con lo que figura en src/base/gfx. No obstante hay pocos restos de WTL en los .h, así que quizás ya van bastante adelantados... Misma sensación de a medias.

Seguro que habría mucho más que decir, sobre todo del diseño e implementación de JavaScript, V8 pero creo que se escribirá de eso suficiente (ya se ha escrito mucho de su eficiencia, veremos cuanto hay de hype) y de temas relacionados como la ejecución de ruby sobre V8... Ains que bien se lo hace google ;)

La misma entrada y más comentarios en Un vistazo al código de chrome en barrapunto

Beautiful Code

El bloguerío de esto de la programación anda revuelto por la publicación de un libro que parece muy interesante Beautiful Code: Leading Programmers Explain How They Think. Y es extraño que ande tan revolucionado sin una causa económica (al parecer lo que se saque con este libro irá a AI) pero viendo los autores quizás sea para tanto; que me suenen: Brian Kernighan, Tim Bray, Charles Petzold, Diomidis Spinellis, Douglas C. Schmidt, Yukihiro Matsumoto... aunque seguro que me dejo a alguien importante :) Cinco de ellos han sido ya nombrados por aquí, que cosas...

El libro consta de 33 capítulos en los que otros tantos autores piensan en alto sobre la arquitectura de sus proyectos (o de los proyectos de otro) los compromisos que se tomaron en su construcción y cuando fue importante romper las reglas. Dado lo heterogéneo del grupo de autores seguro que hay de todo un poco, pero el tema me parece tan interesante que inmediatamente lo he puesto en mi lista de deseos de anobii, aunque creo que dentro de poco se caerá de la lista :)

Por hacerme eco de algunos de los los comentarios que ha generado, Bryan Cantrill reflexiona sobre la recursividad en el mundo real y recibe interesantes respuestas. Alberto Savoia, uno de los autores, en "Pardon My French, But This Code Is C.R.A.P." reflexiona sobre el código malo, que es mucho más abundante, parafraseando a Strurgeon ("90% of everything is crap." - Sturgeon’s Law (one of many variants) "When applied to software, Sturgeon’s Law is hopelessly optimistic." - Savoia’s Corollary to Sturgeon’s Law) y a Sartre ("Hell is other people." - J. P. Sartre "Hell is other people’s code." - T-Shirt seen recently in Mountain View, CA) :)

Beautiful Code en barrapunto

Copiar, pegar y código de producción

Hay veces que se juntan varias notas que lees por diversos sitios y te llevan al mismo lugar, al lugar en donde has llegado antes por tus propios medios...

En esta ocasión la moraleja es es Cuidado con el código que cortas/pegas de por ahí. Ya sé, es de lógica, de sentido común pero hay veces que la cosa es bastante sutil. Hay muchos motivos por los que analizarlo, pero entre otros:

• Puede ser código peligroso: Me acabo de encontrar con un ejemplo de código de "ayuda" en un grupo de noticias a través de Reflections on Trusting Example Code en donde se hace la pregunta ¿habrá muchos problemas de seguridad en código posteado por internet?
• Puede ser código simplificado: En exampleCode != productionCode se habla de código copiado directamente del ejemplo de los libros y la diferencia con un código eficiente y mantenible.
• Puede hacer asunciones peligrosas: Hace poco buscando ejemplos de uso de criptografía en .NET, para codificar y decodificar con AES concretamente, casi todos los ejemplos usaban PasswordDeriveBytes que tanto en la MSDN como en la documentación de mono: PasswordDeriveBytes dicen que es obsoleta y que produce problemas de interoperabilidad (no usa un algoritmo estándar) Para el framework 2.0 por cierto existe Rfc2898DeriveBytes.GetBytes que no tiene ese problema, porque, este si, usa un algoritmo estándar, PBKDF2 con HMACSHA1. Lo que asumía el código de ejemplo es que no nos importaba la interoperabilidad ni los estándares, cosa que en este caso por supuesto no es cierta ;)

En fín, que el mantra que me voy a repetir hoy es Trata el código de los demás como si fuese tuyo: debe pasar por la misma evaluación de tecnologías, los mismos test, por el mismo control de calidad, como mínimo...

Copiar, pegar y código de producción en Barrapunto

POO, el código como diseño, y más cosas

• "Coding Horror: Your Code: OOP or POO?" De porqué la programación orientada a objetos tampoco es la bala de plata, como se comentó también en BP en ¿Ha muerto la orientación a objetos?, que claro, por supuesto que no ha muerto... (y un poco más sobre el mismo tema: Ejecución en el Reino de los Nombres)
• Leo casi con sorpresa que se vuelve a hablar de El código fuente visto como diseño. En The Code is the Design se retoma la tesis del artículo de Jack W. Reeves y lo dice bien claro:

  No UML diagram is the essential and final output of the design process, the code is. And when you are coding, you are designing

• En Nuevo scheduler para el kernel Ricardo Galli comenta la propuesta de volver a cambiar el planificador de tareas de linux. Muy interesante
• "Pure Virtual Function Called": An Explanation De la teoría y de la implementación del polimorfismo en C++
• Esta me ha resultado curiosa: CodeShine™ A refactoring tool for Microsoft Visual Basic 6 Desde luego no será por falta de código en VB6 que necesita un repasito...

POO, el código como diseño, y más cosas en Barrapunto