Uno más con Google Chrome

Me faltó tiempo ayer para instalarme el famoso Chrome, como supongo que habrán hecho otras chorrocientasmil personas. A eso de las 22h ya estaba trasteándolo un poco; la verdad es que sólo fue un ratín porque Windows (sí, porque de momento sólo hay versión para Windows) decidió cascar al cabo de poco tiempo y me cortó el rollo.

Decenas de blogueros escribirán ríos de bits sobre el tema en plan técnico y no voy a ser uno más, sobre todo porque lo que más me ha llamado la atención inicialmente es el contenido del cómic con que han presentado en sociedad a esta criatura.

El formato, curioso.
El contenido, interesante, discutible y hasta inquietante.

Lo más interesante: el enfoque y la declaración de intenciones.

• La web no es aún lo que se pensó que sería cuando se ideó. Tampoco es ya aquel primer esbozo simple que permitieró la tecnología de los años 90. Las nuevas necesidades necesitan de nuevos diseños y no de parches sobre lo que teníamos.
• Es muy difícil hacer cosas libres de errores, y más cuando tienen que convivir con tecnologías cerradas de otros fabricantes. Los estándares abiertos simplifican y mejoran la fiabilidad de todo el sistema.
• Cuanto más simple, mejor.
  

Lo más discutible:
Pese al enorme respeto que le tengo a estos equipos de desarrollo, capaces de engendrar utilísimas herramientas en tiempo record, hay ideas que en ese cómic me han rechinado bastante.

Declaraciones del estilo "no pasa nada si hay un memory-leak en una pestaña porque, total, no pasará mucho tiempo hasta que la cierres" o "es normal que el recolector de basura no funcione bien, así que mejor matar el proceso entero y pista" no me han gustado nada. La forma de resolver los problemas a lo bruto es eficaz, pero no inteligente ni elegante. Tratándose de una megaempresa como Google no me atrevería a decir que no es eficiente porque si algo hacen bien esas moles empresariales es ahorrar y optimizar (en todos los sentidos).

Que hay que probar el software es algo obvio aunque muchas empresas se empeñen en intentar demostrar lo contrario. Sin embargo me parece una tanto salvaje basar el desarrollo en el resultado de una avalancha de pruebas. El que los programadores dejen de meter la pata a base de ver pifias en los resultados de las pruebas es como enseñar a un niño a escribir bien a base de darle collejas cuando se equivoca. Eso no es ingeniería. Eso no es diseño. Estamos hablando de ensayo-error en escalas mastodónticas, algo que no hay que confundir con pruebas mediante el método científico.

Tal vez me falte esa costumbre de solucionar la papeleta como sea y cuanto antes en vez de hacer las cosas bien. Puede que, realmente, haya que hacer las cosas a toda pastilla para que salgan algún dia y sean útiles aunque un tanto chapuceras en vez de ya desfasadas el dia que finalmente salen a la luz una vez absolutamente pulidas.

Actualización:
Por los primeros comentarios que veo creo que la gente no se ha terminado de darse cuenta de que Chrome es una beta bastante verde que según los primeros párrafos de su presentación han sacado únicamente porque alguien dejó ver su existencia antes de lo previsto. Además centran su comparación en características que no son el grueso de su innovación, típicas de otros navegadores, y que son triviales de implementar en caso necesario (como los marcadores o enviar páginas por correo electrónico).

Energía solar a gran escala o "no debíamos ser tan tontos entonces"

A raíz de una noticia de Barrapunto he ido a caer en la web de Abengoa Solar para ver los tipos de instalaciones que tienen. Me he quedado con una sensación extraña cuando he visto sus heliostatos parabólicos, orientables al sol, y provistos (en los prototipos) de motores Stirling. Se trata sólo de uno de los varios modelos de obtención sobre los que trabajan, pero me trae buenos recuerdos de mi último verano con vacaciones completas: tras 2º de bachillerato en 1999.

En aquellos tiempos un grupo de aguerridos estudiantes soplagaitas, a los que nos gusta más la ciencia que comer con los dedos, nos apuntamos a un concurso organizado por el colegio de licenciados en FyL y en Ciencias. El nombre del concurso era "Jóvenes Investigadores hacia el año 2000", que quedaba como muy futurista aun cuando restaba menos de un año para llegar a la citada fecha.

El caso es que para este evento nos decantamos por hacer un estudio del estado del arte del aprovechamiento de la energía solar y a partir de él definir y construir un prototipo de aparataje simple, barato y que reciclase materiales además de ¡producir energía útil! Así nació el Proyecto Helianto.

El caso es que durante ese último verano con unas vacaciones comme il faut conseguimos entre profesores-tutores e imberbes estudiantes construir un "parato" que busca la fuente de mayor energía, se orienta hacia ella, y concentra la luz que recibe en un punto; en aquel momento, por diversos motivos, nos limitamos a colocar un intercambiador de calor (una espiral de cobre negro, para entendernos) que ya nos permitía evaluar la cantidad de energía aprovechada. Un verano curioso aquel en materia solar, ya que se produjo el último eclipse total de sol visible en el hemisferio norte ese milenio; también participé de ese acontecimiento yendo hasta la zona de máxima ocultación, pero esa es otra historia.

Es probable que, de no ser por nuestra intención de reciclar materiales de forma simple, hubiesemos probado a colocar algún otro tipo de receptor de energía; sin ir más lejos un motor Stirling que ya habíamos visto en funcionamiento en la Escuela Politécnica adyacente a nuestro instituo. Si se hubiese dado el caso habríamos diseñado y construido en poco tiempo, hace casi una década, un equivalente barato de lo que hoy día presenta como explotable un gran grupo empresarial. Espero que lo lleven a ejecución y que los resultados sean satisfactorios. Eso me demostraría que no éramos tan tontos en aquella época.

Por cierto, aquel año ganamos el primer premio nacional con ese proyecto.

Energías alternativas ¡NO!

¿Por qué "alternativas"? El adjetivo alternativa se suele aplicar a una posibilidad existente al margen de otra principal o comun; no es que sea el único matiz de su significado, pero me parece el más común.

Creo que una de las cosas que no ayudan nada a la promoción e investigación de fuentes energéticas distintas del petróleo es ese matiz de "no principal", "secundario" que se proyecta hacia un futuro. ¿Para qué invertir tantos recursos en algo marginal?
Quizá dar a las fuentes de energía un cariz general, tratarlas como algo único, dé un empujón al progreso en este área.

Hay formas y formas de hacer las cosas para llegar a lo mismo.
De un tiempo a esta parte varios gobiernos están tomando medidas para ahorrar energía en sus respectivos dominios. Una de las iniciativas ha sido deshacerse de las lámparas incandescentes. En algunos lugares directamente se ha prohibido esta centenaria tecnología por decreto, sin matices. En otros lugares, como Australia, lo que se ha hecho ha sido prohibir lo que no tenga cierta eficiencia. Este enfoque es mucho mejor ya que abarca las implementaciones no eficientes de las tecnologías actuales, las no eficientes de tecnologías futuras y permite implementaciones eficientes de tecnologías actuales.
Lo importante es dejar claro qué es lo que se pretende, y para esto hay que tenerlo claro previamente; exige pensar. Quizá sea pedir demasiado.

Percepción y realidad

El rendimiento [de lo que sea] es el que perciba la persona durante sus actividades cotidianas, no el que digan unos números.

Esta frase, o muy parecida, se la escuché a uno de mis profesores durante la carrera y cada dia me parece más cierta.
Hace unos minutos acabo de pensar "qué adelanta tener un ordenador biprocesador, más potente, con más memoria y mejores gráficos si la aplicacioncilla de gestión de todos los días va igual de lenta que en el cacharro que acabo de retirar (en realidad, en el cacharro, iba increíblemente un 20% más rápido).
Lo mismo se puede aplicar a casi todos los sistemas con los que interaccionamos. Me da igual lo que digan las estadísticas, mi salario rinde lo que me rinde a mí. El aprovechamiento de un cochazo supermotorizado cumpliendo las normas de tráfico es ridículo (y por ello es absurdo que se permita semejante despilfarro energético).

Si hay que gastar, se gasta, pero gastar pa' ná ye tontería.

Ingenieros, escojamos las palabras

Un proyecto de ingeniería, trate de lo que trate, es antes que nada eso, un proyecto. Nunca suficientemente valorado, este documento responde al qué, el cómo, el por qué, cuanto y quien realizará cada paso para llevar a cabo ese fin.
Quizá esté exagerando en eso de "nunca suficientemente valorado", excepto en el campo de la ingeniería del software, ese mundo lleno de vaguedades donde un prototipo es capaz de alcanzar el mercado a base de parches.

El caso es que leyendo este documento sobre XMPP me he fijado en la nota sobre el uso del lenguaje que se hace dentro del mismo documento. Viene a ser lo mismo que me explicó en clase el Sr. Castejón Limas, una de las pocas personas que hasta ahora he visto tomarse de verdad en serio un proyecto. Mis saludos desde aquí.

Uno de los pasos más importantes en cualquier proyecto es levantar correctamente las especificaciones; es decir ¿qué tenemos que cumplir para alcanzar nuestra meta?
Aquí entra en juego seriamente el lenguaje. No se trata de hacer una mera exposición de objetivos, sino en qué grado son importantes para el fin último.

Intentaré traducir brevemente el RFC 2119:

1. Debe: esta palabra junto con "tiene que" o "requiere" indica un requisito absoluto. Piensa antes de escribirlas porque TENDRÁS que cumplirlas.
2. No debe: indica una prohibición absoluta.
3. Debería: esta palabra junto con el adjetivo "recomendado" indican la posible existencia de razones válidas en circunstancias particulares para ignorar este ítem. Las implicaciones deben ser comprendidas y valoradas cuidadosamente antes de elegir un rumbo diferente.
   
4. No debería: esta locución, junto con "no recomendado" significa que puede haber razones válidas en circunstancias particulares en las que un comportamiento específico sea aceptable o incluso útil. Igualmente hay que comprender las implicaciones que esto conlleva y pensárselo bien antes de implementar algo etiquetado de esta manera.
   
5. Puede: al igual que el adjetivo "opcional" significa que un ítem es completamente opcional.
6. Imperativos: Deben ser utilizados únicamente cuando sea realmente necesario para interoperabilidad o para evitar daños. No deben, por ejemplo, usarse para imponer un método o implementación si no es necesario para interoperabilidad.
7. Consideraciones de seguridad: el autor del documento debe tomarse el tiempo necesario para mostrar las implicaciones de no seguir las recomendaciones y requisitos, ya que los efectos pueden ser inicialmente sutiles y que el implementador probablemente no tenga la experiencia del que escribe la especificación (que por algo la escribe).

Estos son, aproximadamente, los términos en que se expresa el citado RFC.

En resumidas cuentas: hay que pensar lo que se escribe en un proyecto, ya que luego hay que hacer lo que se ha escrito.