Esta semana (26 al 28 de Noviembre) he asistido a un curso de bioinformática organizado por el IRB (Institute for Research in Biomedicine) en donde se presentaron e hicieron tutoriales prácticos sobre las herramientas bioinformáticas del EBI (European Bioinformatics Institute) y del INB (Instituto Nacional de Bioinformática)
El temario con los enlaces para descargar el material lo he dejado aquí
En los últimos años se han ido construyendo sobre HTTP (que no fue diseñado para hacer aplicaciones, si no para ver documentos) una serie de tecnologías que permiten la creación de aplicaciones sobre este protocolo. En una primera fase, estas soluciones se han basado en dotar al servidor de la capacidad de ejecutar programas en diferentes lenguajes (CGi, Perl, PHP, JSP, etc…) a partir de los parámetros enviados desde el navegador cliente (normalmente a través de formularios HTML). Esta aproximación que, si bien ha permitido la creación de todo tipo de software basado en web, con mayor o menor esfuerzo, no ha evitado el hecho de que la brecha HTTP siguiese vigente (a través de las famosas “recargas” del navegador cada vez que se hacía clic o se enviaban datos).
Con posterioridad, ha surgido el concepto AJAX: una unión de varias tecnologías que dan la posibilidad de comunicar a cliente (navegador) y servidor (servidor web) de una manera más fina, de forma que la respuesta desde el servidor no fuese un documento entero, sino sólo lo que se pide de forma asíncrona desde el navegador, al más puro estilo de una llamada remota.
Con la aparición de AJAX, están surgiendo gran cantidad de herramientas y frameworks de programación para agilizar la creación de aplicaciones bajo este “paradigma”. La idea es que, debido a que la brecha HTTP es más pequeña.
Hoy me he encontrado con un proyecto de Eclipse: RAP (Rich Ajax Platform). La idea es muy simple, es la que persiguen todos: programar las aplicaciones Web como si fuesen aplicaciones de escritorio. El arquipiélago Eclipse ya disponía de un Toolkit para el desarrollo de aplicaciones de escritorio (SWT, Standard Widget Toolkit y, sobre él, JFace) que, junto con otras tecnologías, formaba parte de la RCP (Rich Client Plaform), una plataforma para la creación de aplicaciones de escritorio. A ella se une ahora RAP, que implementa un subconjunto de SWT y que permite abstraer al programador hasta el punto de trabajar con componentes JFace que por debajo terminan generando una aplicación web basada en Servlets y Javascript-Ajax. Suena muy muy bien.
Figura. Comparación entre RCP y RAP
 |
Según leo en Phoronix la nueva versión de los drivers propietarios de ATI para Linux (“fglrx”) ya incluye soporte para AIGLX, una de las características más esperadas ya que nos permite ejecutar de forma “más estable” los gestores de ventanas 3D Compiz, Beryl y Compiz Fusion. Hasta ahora, únicamente se podía ejecutar con XGL y con el driver propietario. Para AIGLX era necesario utilizar el driver open-source “radeon” que, por desgracia, tenía menos prestaciones y menor número de tarjetas compatibles que la versión propietaria, que a su vez, era bastante inferior que su versión para Windows.
Al fin, el tiempo de sequía terminó. Lástima que ya me haya cambiado a NVidia hace un par de meses, la cual tiene soporte para AIGLX en su driver propietario desde hace 11 meses. |
Tengo una opinión positiva acerca de la recolección de basura (garbage collection) como técnica para la gestión de memoria en los programas. Creo sinceramente que llega a ser imprescindible para hacer un buen diseño software en los lenguajes orientados a objetos.
Recuerdo una práctica en 5º de carrera, de la asignatura Tecnología de Objetos, hecha en C++ (lenguaje sin recolección de basura) en la que tenía que hacer un pequeño programa, ya no recuerdo exactamente sobre qué. Sí recuerdo sin embargo, la imposiblidad de llegar a un diseño “correcto” debido a la obligación de gestionar la memoria dinámica “manualmente”. El problema es muy simple: Cuando se pide la liberación de un objeto, ¿cómo sabes que ese objeto no está siendo referenciado desde otra parte/módulo? Derivado de esto es que habría que crear una dependencia gravísima entre los diferentes módulos que, en algún momento, compartiesen una referencia a un objeto. Tendrían que ponerse de acuerdo los programadores de ambos módulos en quién libera finalmente el objeto. Inadmisible.
Tratando de satisfacer mi ego personal, hoy he buscado por la red alguna documentación que corroborase mi desencanto con los lenguajes sin recolección de basura (Ojo, en C++ siempre estás a tiempo de create tu recolector, yo lo que quiero indicar es que de un modo u otro es prácticamente imprescindible).
Pues aquí va lo que he encontrado. Una reflexión de Paul Johnson. Destaco en negrilla lo que va en la misma línea de lo que he dicho.
Garbage collection (GC) is a facility in the run-time system associated with a language which will automatically reclaim objects which are no longer used. OO Languages which require garbage collection include Eiffel, Smalltalk and CLOS. C and C++ can have garbage collection retrofitted
Without GC programmers must explicitly deallocate dynamic storage when
it is no longer needed (in C this is done by a call to free(3)).
There are a number of problems with this:
1: Bugs due to errors in storage deallocation are very hard to find,
although products are available which can help.
2: In some circumstances the decision about whether to deallocate
storage cannot be made by the programmer. Drawing editors and
interpreters often suffer from this. The usual result is that the
programmer has to write an application-specific garbage collector.
3: An object which is responsible for deallocating storage must be
certain that no other object still needs that storage. Thus many
modules must co-operate closely. This leads to a tight binding
between supposedly independent modules.
4: Libraries with different deallocation strategies are often
incompatible, hindering reuse.
5: In order to avoid problems 3 and 4, programmers may end up copying
and comparing whole objects rather than just references. This is a
particular problem with temporary values produced by C++ overloaded
operators.
6: Because keeping track of storage is extra work, programmers often
resort to statically allocated arrays. This in turn leads to
arbitrary restrictions on input data which can cause failure when
the assumptions behind the chosen limits no longer apply. For
instance many C compilers limit expression nesting, identifier
length, include file nesting and macro stack depth. This causes
problems for programs that generate C.
Las trayectorias de desplazamiento personalizadas permiten mover un objeto de un punto a otro durante una animación. Son imprescindibles si queremos que el objeto pase por cierto lugar o que el desplazamiento tenga mayor o menor distancia. Este recurso es básico para hacer animaciones que ayuden a explicar conceptos de una forma intuitiva.
El problema es que esta era una de las grandes carencias de Impress a mi modo de ver, que dificultaba la migración desde PowerPoint. Realmente esta función estuvo disponible en versiones antiguas, pero había desaparecido en la serie 2.x de Open Office. Ahora en la 2.3 ha vuelto! Genial!
Más info en:
http://openoffice.blogs.com/openoffice/2007/10/welcome-back-us.html
Hoy leo en Ingenieros de Primera una noticia muy simpática sobre un exámen de Inteligencia Artificial realizado este mes de Septiembre en la Escuela Universitaria de Informática de la Universidad Politécnica de Madrid. La verdad es que el profesor está muy concienciado con la Regulación de nuestra profesión.
Hace unos días vi una noticia en barrapunto sobre un nuevo algoritmo de redimensionado de imágenes inteligente. No le di mayor importancia, hasta que salió una segunda noticia de una implementación libre. Esta vez quise saber más del algoritmo, cuyos autores son Shai Avidan y Ariel Shamir (el primero ya contratado por Adobe), y me encontré un vídeo sobre su funcionamiento: Increíble.
Utilizo digikam para administrar las fotos personales. Este software, al igual que los de su estilo, es capaz de organizar las fotos de una jerarquía de directorios de múltiples formas, entre ellas, por fecha.
Un problema que me he encontrado es que unas fotos sacadas con una cámara con la fecha mal, se clasificaban, obviamente, mal. En los ficheros jpg, digikam no utiliza la fecha de creación o modificación del fichero, sino que usa la fecha incrustada en la información EXIF, dentro del propio formato JPEG.
Solución: Para corregir la fecha, se puede usar jhead (apt-get install jhead en kubuntu).
Un ejemplo:
jhead -ts2006:04:22-00:00:00 *.jpg
Este ejemplo pone la fecha de creación a 22 de Abril de 2006, a las 00:00 horas. Una vez realizado el cambio, digikam clasificó las fotos modificadas en su nueva fecha.
Esto es un documento de Linus Torvalds traducido que me encanta, ahí va:
“Este breve documento describe el estilo de gestión preferido (o
inventado, según a quién le preguntes) para el kernel Linux. En teoría
debería seguir el formato del documento CodingStyle [EstiloProgramacion]
hasta cierto punto, y se ha escrito sobre todo para evitar responder (*)
a las mismas preguntas (o parecidas) una y otra vez.
El estilo de gestión es muy personal y mucho más difícil de cuantificar
que las reglas de estilo de programación, así que este documento puede
tener o no que ver con el mundo real. Empezó como un divertimento, pero
eso no quiere decir que no pueda ser verdad. Tendrás que decidir por ti
mismo.
Por cierto, cuando se habla de “gestor del kernel”, es sobre las
personas que llevan el liderazgo técnico, no la gente que hace gestión
tradicional en las empresas. Si firmas órdenes de compra o tienes alguna
idea sobre el presupuesto de tu grupo, casi seguro que no eres un gestor
del kernel. Estas sugerencias pueden o no aplicarse a tu caso.
Primero de todo, sugiero comprar “Siete Hábitos de Gente Exitosa”, y NO
leerlo. Quémalo, es un gesto simbólico estupendo.
(*) Este documento lo consigue no tanto respondiendo a la pregunta, sino
haciendo insufriblemente obvio para el que la hace que no tenemos ni la
más remota idea de cuál es la respuesta.
Bueno, pues ahí va:
Todo el mundo piensa que los gestores toman decisiones, y que tomar
decisiones es importante. Cuanto mayor sea la decisión y más penas
provoque, más grande debe ser el gestor que la tome. Esto es muy
profundo y muy obvio, pero resulta que no es cierto.
La gracia del juego es _evitar_ tener que tomar decisiones. En
particular, si alguien te dice: “elige (a) o (b), necesitamos que tú
decidas esto”, estás en un lío. La gente que gestionas debería conocer
los detalles mejor que tú, así que si vienen a ti para que tomes una
decisión técnica, estás jodido. Está claro que no eres competente para
tomar la decisión por ellos.
(Corolario: si la gente que gestionas no conoce los detalles mejor que
tú, también estás jodido, aunque por una razón completamente diferente.
En este caso es que estás en el trabajo equivocado, y son más bien
_ellos_ los que deberían estar gestionando tu brillantez.)
Así que la gracia del negocio está en _evitar_ las decisiones, por lo
menos las más gordas y penosas. Tomar decisiones pequeñas y sin
consecuencias está bien, y hace que parezca que sabes lo que haces, así
que lo que un gestor del kernel tiene que hacer es convertir las
decisiones gordas y penosas en cosas pequeñas que a nadie le importan.
Hay que darse cuenta de que la diferencia crucial entre una decisión
gorda y una pequeña es que puedas cambiar de decisión más adelante.
Cualquier decisión puede hacerse pequeña si te aseguras de que si te
equivocas (y te vas a equivocar _seguro_), siempre puedes deshacer el
daño más tarde volviendo sobre tus pasos. De repente, eres el doble de
gestor por tomar _dos_ decisiones sin importancia: la errónea _y_ la
correcta.
Y la gente hasta verá eso como liderazgo puro (*cof cof* y una mierda
*cof cof*).
Así que la clave para evitar las grandes decisiones es evitar hacer
cosas que no tengan remedio. No dejes que te arrinconen sin escapatoria
posible. Una rata arrinconada puede que sea peligrosa — pero un gestor
arrinconado es patético.
Resulta que, ya que nadie va a darle a un gestor del kernel mucha
responsabilidad financiera en _ningún_ caso, echar atrás suele ser
fácil. Dado que no vas a ser capaz de gastar ingentes cantidades de
dinero que luego no puedas recuperar, la única cosa en la que puedes
tener que echar atrás es en una decisión técnica, y ahí lo tienes fácil:
sólo tienes que decirles a todos que eres un cretinazo incompetente, que
lo sientes, y deshacer todo el trabajo inútil que por tu culpa han
tenido que hacer durante el último año. De repente la decisión que
tomaste hace un año no es tan gorda como parecía, porque se ha podido
deshacer fácilmente.
Resulta que hay gente a la que no le gusta este enfoque, por dos
motivos:
– admitir que has sido un idiota es más difícil de lo que parece. A
todo el mundo le gusta mantener las apariencias, y salir en público a
decir que te has equivocado puede resultar dificilillo.
– que alguien te diga que aquéllo en lo que has trabajado durante el
último año no sirve para nada, después de todo, puede ser duro para
los pobres ingenieros de a pie, y mientras que el _trabajo_ se puede
deshacer fácilmente con sólo borrarlo, puede que hayas perdido sin
remedio la confianza de este ingeniero. Y recuerda: las cosas
“irrevocables” son justo lo que intentábamos evitar desde el
principio, así que tu decisión sí que era gorda después de todo.
Por suerte, ambos puntos se pueden mitigar bastante: basta admitir de
primeras que no tienes ni puñetera idea, y diciéndole a la gente antes
de empezar que la decisión es preliminar, y podría ser un error.
Deberías reservarte siempre el derecho a cambiar de idea, y que la gente
sea _muy_ consciente de ello. Además de que es más fácil admitir que
eres estúpido cuando no has hecho _todavía_ la cosa estúpida de verdad.
Después, cuando resulta que sí que era estúpida, la gente pone los ojos
en blanco y dice: “Vaya, lo ha vuelto a hacer”, y listo.
Esta admisión preventiva de incompetencia puede que sirva también para
que la gente que tiene que hacer el trabajo se piense dos veces si vale
la pena hacerlo. Después de todo, si _ellos_ no están seguros de si es
una buena idea, está claro que tú no deberías animarlos prometiendo que
su trabajo se va a incluir. Haz que al menos se lo piensen dos veces
antes de embarcarse en una misión de envergadura.
Recuerda: más les vale conocer los detalles mejor que tú, y normalmente
ya piensan que se saben todas las respuestas. La mejor cosa que puedes
hacer como gestor no es inspirarles confianza, sino más bien inyectarles
una buena dosis de pensamiento crítico sobre su trabajo.
Por cierto, otra forma de evitar una decisión es lloriquear: “¿no
podemos hacer las dos cosas?” y poner aspecto patético. Hazme caso, eso
funciona. Si no está claro cuál de las dos formas es la buena, ya se
darán cuenta. La respuesta puede ser que los dos equipos acaben tan
frustrados por la situación que abandonen.
Esto podría sonar a fracaso, pero en realidad suele ser un signo de que
ninguno de los proyectos iba bien, y la razón de que la gente implicada
no pudiera tomar una decisión es que los dos estaban mal. Sales de la
situación oliendo a rosas, y de paso has evitado otra decisión donde
podías cagarla.
La mayoría de la gente es idiota, y ser un gestor quiere decir que
tendrás que tratar con ellos, y más importante todavía: que _ellos_
tendrán que tratar _contigo_.
Resulta que, aunque sea fácil deshacer errores técnicos, no es tan fácil
deshacer los trastornos de la personalidad. Tendrás que vivir con los
suyos — y con los tuyos.
Sin embargo, para prepararte como gestor del kernel, lo mejor es no
quemar los puentes, no bombardear a la población civil ni alienar a
demasiados desarrolladores del kernel. Alienar a la gente es
sorprendentemente fácil, y des-alienarlos es complicado. De forma que
“alienar” inmediatamente entra en la categoría de “no reversible”, y por
tanto cae en la región tabú que vimos en el capítulo 1.
Sólo hay que seguir unas reglas sencillitas:
(1) no llames a la gente gilip*llas (al menos no en público)
(2) aprende a pedir perdón cuando se te olvide la regla (1)
El problema con (1) es que es muy fácil caer en ello, porque hay un
millón de formas distintas de decir “eres un gilip*llas” (*), a veces
sin darte cuenta, y casi siempre con una convicción férrea de que tienes
razón.
Y cuanto más convencido estés de que tienes razón (y reconozcámoslo,
puedes llamar casi a _cualquiera_ gilip*llas, y muchas veces con razón),
más difícil es tener que pedir perdón luego.
Para resolver este problema, sólo hay dos opciones:
– volverte bueno de verdad en pedir disculpas
– ser tan generoso con tu “amor” que nadie sienta que se le tiene
enfilado injustamente. Si aplicas la inventiva suficiente, puede
hasta que se se lo tomen bien.
La opción de ser educado en extremo no existe realmente. Nadie confiará
en alguien que oculta de forma tan palmaria su carácter verdadero.
(*) Paul Simon cantó “Cincuenta Formas de Perder a Tu Amante”, porque
francamente: “Un Millón de Formas de Decir a un Desarrollador que Es Un
Gilip*llas” no tiene la misma sonoridad. Pero seguro que lo pensó.
Si aceptamos que la mayoría de la gente es idiota, el corolario es que
por desgracia tú también lo eres, y que mientras podemos recrearnos con
la certeza de que somos mejores que la media (porque seamos francos,
nadie piensa que sea peor que la media o ni siquiera igual a la media),
también tendríamos que admitir que no somos tampoco la pajita más larga,
y que siempre habrá por ahí gente que es menos idiota que tú.
Hay gente que no reacciona bien ante las personas inteligentes. Otros se
aprovechan de ellas.
Asegúrate de que tú, como mantenedor del kernel, estás en el segundo
grupo. Hazles la pelota, porque son los que te facilitarán tu trabajo.
En particular, tomarán las decisiones por ti, que es lo que buscamos
desde el principio.
Así que, cuando encuentres a alguien más listo que tú, síguele. Tus
responsabilidades como gestor se limitarán a decir: “Parece buena idea -
dale caña”, o “Suena bien, pero ¿qué pasa con xxx?”. La segunda versión
en particular es una forma estupenda de o bien aprender algo nuevo sobre
“xxx”, o bien parecer _extra_ gestor por señalar algo que la persona más
lista no había pensado. En ambos casos sales ganando.
También es importante darse cuenta de que la grandeza en un área no
siempre se traslada a otras. Así que puedes espolear a la gente en
direcciones específicas, pero reconozcámoslo, pueden ser buenos en lo
que hacen, y malos en todo lo demás. Las buenas noticias son que la
gente tiende naturalmente hacia lo que hace bien, así que no estás
haciendo nada irreversible cuando les espoleas en cierta dirección; pero
no aprietes demasiado.
Las cosas saldrán mal, y la gente querrá tener alguien a quien echar la
culpa. Zas, te la quedas tú.
No es tan difícil aceptar la culpa, sobre todo si la gente se da más o
menos cuenta de que no es _todo_ culpa tuya. Lo que nos trae a la mejor
forma de aceptar culpas: hacerlo por otro. Te sentirás bien por
cargártela, él se sentirá bien por que no le culpen, y el colega que
perdió sus 36 GB de porno por tu incompetencia tendrá que admitir que
por lo menos no has intentado escaparte.
Después encuentra al desarrollador que la ha cagado y hazle saber _en
privado_ que la ha cagado. No sólo para que no lo haga más, sino para
que sepa que te debe una. Y, más importante todavía, seguramente sea la
persona que sabe arreglarlo. Porque, seamos francos, tú seguro que no
eres.
Aceptar culpas es también lo que te hace gestor, para empezar. Es parte
de lo que hace que la gente confíe en ti, y te concede la gloria
potencial, porque eres el que dice “La cagué”. Y, si has seguido las
otras reglas, a estas alturas seguro que eres bastante bueno diciéndolo.
Hay algo que la gente odia más todavía que que los llamen “gilip*llas”,
y es que los llamen “gilip*llas” con voz santurrona. Por lo primero
puedes pedir perdón, por lo segundo seguramente ni te dejen. Lo más
probable es que no lleguen ni a escucharte, aunque por lo demás hagas
bien tu trabajo.
Todos pensamos que somos mejores que los demás, lo que quiere decir que
cuando alguien se da aires de grandeza, puede llegar a ser irritante _de
verdad_. Puedes ser moral e intelectualmente superior a todos los que te
rodean, pero no intentes que sea demasiado obvio a no ser que _quieras_
irritar a alguien (*).
Por las mismas, no seas demasiado educado o sutil sobre las cosas. La
educación puede fácilmente terminar ocultando los problemas, y como se
suele decir, “En internet, nadie puede oírte ser sutil”. Usa un objeto
contundente para machacar bien la idea, porque si no será difícil
estar seguro de que la gente lo haya comprendido.
El humor puede ayudar a suavizar la contundencia y las moralinas.
Pasarse de rosca hasta llegar a ser ridículo puede hacer ver alguna cosa
sin que sea dolorosa para el que la recibe, que piensa que eres un
payaso. Así puedes traspasar la barrera mental que todos tenemos hacia
las críticas.
(*) Truco: los foros de internet que no están relacionados directamente
con tu trabajo son una forma estupenda de ventilar tus frustraciones con
otra gente. Escribe mensajes insultantes llenos de sarcasmo de vez en
cuando, para meterte en una buena pelea dialéctica de vez en cuando, y
te sentirás renovado. Eso sí, ten cuidado de no cagarte demasiado cerca
de tu puerta.
Dado que tu mayor responsabilidad parece ser aceptar las culpas de los
demás, y que se vea bien claro que eres un incompetente, la pregunta
obvia es ¿por qué meterse en este fregado?
Lo primero, tengas o no legiones de chicas (o chicos, no vamos a
ponernos sentenciosos ni sexistas ahora) adolescentes gritando a la
puerta de tu camerino, lo que sí tendrás es un sentimiento inmenso de
realización personal por estar “al mando”. Da igual que en realidad no
estés liderando sino intentando estar a la altura de los demás y
corriendo tras ellos todo lo rápido que puedes. Todo el mundo pensará
que estás al mando.
Es un trabajo estupendo si te lo sabes currar.”
Existe un problema de integración entre Beryl y el paginador de escritorio por defecto de KDE que, entre otras cosas, impide que se vean las miniaturas de las ventanas.
He encontrado un mod en www.kde-apps.org
Salud!