Hace unos días Miguel de Icaza hablaba en su blog de la inminente posibilidad de hacer funcionar ASP.Net Ajax sobre Mono, incluso comenta un mensaje de Onur Gumus a la lista de programadores de la plataforma explicando cómo hacerlo en la actualidad con versiones internas.

Todavía tendremos que esperar un poco para poder incorporarlo en producción, pero sin duda es una buena noticia para los que ya disfrutábamos de estas librerías en el framework de Microsoft y esperábamos ansiosamente su implementación en Mono.

¡Y ya estamos de vuelta! Parece que fue ayer cuando me despedía con la alegría de ver un mes de descanso por delante, y casi sin darnos cuenta ha llegado Septiembre, con todo lo que ello implica.

¡Por fin llegaron! Salvo un par de maletas pendientes de repasar, todo está listo para comenzar nuestra gira veraniega.

Variable not found, por tanto, quedará a su libre albedrío hasta primeros de Septiembre, momento en el que volveré con más energía que nunca, muy motivado por la evolución del blog y sobre todo por este mes de Julio que ha terminado con una actividad y unas estadísticas de visitas que no habría podido imaginar hace unos meses (debido principalmente al efecto Menéame, todo sea dicho).

En cuanto a las vacas, aunque es posible que hagamos ciertos reajustes en la planificación (hasta en vacaciones hay de eso), tenemos previsto pasar unos cuantos días en El Portil, una pequeña localidad costera a caballo entre Cartaya y Punta Umbría, ambos en provincia de Huelva. Esto será a partir de hoy mismo, hasta finales de la semana que viene.

Después pasaremos unos días también en Sanlúcar de Barrameda, un pueblo de la costa de Cádiz que no tengo la fortuna de conocer, pero según cuentan es una maravilla.

Por último, también pretendemos ir de viaje familiar unos días. No sabemos cuándo. No sabemos a dónde. No sabemos cómo. Digamos que esta es la parte más emocionante del plan vacacional. ;-D.

Nos vemos por aquí a la vuelta.

El pasado miércoles 25 en el blog oficial de Google Analytics publicaban "Notice of Brief Processing Delay", un post donde comentaban que durante el día habría algunos retrasos. No sé si tendrá que ver con esto o con el jolgorio prevacacional, pero me encuentro en mi blog un total de cero visitantes desde hace un par de días... ¡como en los viejos tiempos! :-D

Y aunque sé que es consuelo de tontos, alegra saber que le ocurre a más gente:

• http://groups.google.com/group/analytics-help-troubleshoot/browse_thread/thread/94acb7f4f84fe168/
• http://www.slicksurface.com/blog/2007/07/google-analytics-down-for-nearly-two.html
• http://groups.google.com/group/analytics-help-troubleshoot/browse_thread/thread/e660e578964bfbbe
• http://groups.google.com/group/analytics-help-basics/browse_thread/thread/3f312ea50966a39d
• http://groups.google.com/group/analytics-help-troubleshoot/browse_thread/thread/105dea7423696537/d1649dd6cdbb8c79#d1649dd6cdbb8c79
• etc.

En fin, espero al menos que no borren los datos...


Actualización, martes 31 de Julio: ya hay noticias oficiales por parte de Google sobre este retraso:

• http://analytics.blogspot.com/2007/07/update-temporary-reporting-delay-since.html
• http://analytics.blogspot.com/2007/07/reporting-delay-update.html

Hoy seguimos con la serie inspirada por Phil Haack en su post "19 Eponymous Laws Of Software Development" donde estoy recogiendo leyes que se aplican en el mundo del desarrollo del software y muchos otros ámbitos. La particularidad de estas leyes y principios es que han hecho famosos a sus autores, pues tienen el mismo nombre que ellos.

Ley de Conway

Cualquier software refleja la estructura organizacional de quien lo produjo

A pesar de que suena a guasa, la ley de Melvin Conway no puede ser más cierta. Una empresa con tres grupos de desarrollo tenderá a generar software distribuido en tres subsistemas, reflejo fiel de las relaciones entre los grupos participantes. Y por cierto, ¿habéis pensado alguna vez que el software que se hace en vuestra empresa es un desastre? ¿creéis que con esta ley podríais obtener alguna conclusión? ;-D

Principio de Kerchkhoff

En términos de criptografía, un sistema debería ser seguro incluso si todo sobre el mismo se conoce públicamente, salvo una pequeña porción de información

Es increíble que Auguste Kerckhoffs critógrafo alemán, enunciara en el siglo XIX este principio, base de todos los sistemas de criptografía de clave pública actuales.

Ley de Linus

Dados suficientes ojos, todos los errores son obvios

Pues sí, Linus Torvalds, uno de los más famosos artífices de Linux tal y como es conocido hoy en día, no sólo desarrollaba software, también emitía este tipo de aseveraciones. Aunque la frase fue cosa de Linus, fue Eric S. Raymond, un hacker a la antigua usanza, el que la popularizó y le dio el nombre de su creador.

Ley de Reed

La utilidad de grandes redes, y en particular las sociales, crecen exponencialmente con el tamaño de la red

David P. Reed, científico americano, enunció esto que parece obvio en los tiempos actuales dado el tamaño y utilización de este tipo de redes. En esta entrada de la wikipedia podéis encontrar una introducción del soporte teórico en el que se basa.

Ley de Moore

La potencia de los ordenadores se duplica cada dos años, reduciendo además su coste

Repetida hasta la saciedad en revistas de cacharreo, y constatada desde hace décadas, fue promulgada por Gordon Earl Moore quien, por cierto, es co-fundador de Intel, fijaos si lo tenía claro el muchacho, en 1965 (!). No sé si entonces utilizó la bola de cristal o es simplemente un genio, pero desde luego su ley es una referencia de la medida del avance en los ordenadores y demás dispositivos basados en tecnología similar, y un objetivo mínimo a cumplir.

Ley de Wirth

El software se ralentiza más deprisa de lo que se acelera el hardware

Brillante la frase de Niklaus Wirth, que allá por el año 1995, aún sin conocer Windows Vista, observó su entorno y predijo la situación actual: cada vez el software es más lento y pesado, a pesar de que según la Ley de Moore tendría que ser al contrario. Este señor, una eminencia, es conocido sobre todo por haber dirigido la creación de los lenguajes Pascal, Modula y algunos otros menos difundidos.

Ley de Zawinski

Todo programa intenta expandirse hasta que pueda leer emails. Aquél que no pueda ser expandido hasta ese punto, será sustituido por otro que sí tenga esa capacidad

Lo que más me ha llamado la atención de Jamie Zawinski aparte de su metafórica ley, es su página web personal. No os la perdáis, pues es bastante indicativa del tipo de individuo de que se trata, todo un friki. También es curioso que es propietario de un club nocturno en San Francisco, este sí que sabe.

Enlaces relacionados: leyes epónimas relacionadas con el desarrollo de software (I)

El siempre sorprendente Phil Haack nos regaló hace unos días un post sobre leyes relacionadas con el desarrollo de software en su post "19 Eponymous Laws Of Software Development". Del artículo me llamaron la atención dos cosas: primero, ¿qué diantres es un epónimo? y segundo, las leyes objeto del post; algunas eran muy conocidas, otras menos, pero en cualquier caso, son perlas dignas de tener en cuenta.

Un epónimo es el nombre de una persona o lugar que cede su nombre a una época, pueblo, unidad, ley, etc. Son epónimos por ejemplo "Diesel", cedido por Rudolf Diesel, inventor de este tipo de motores, o "Hamburguesa", infame trozo de carne picada cuyo nombre le fue cedido por su lugar de origen. Para los curiosos, en esta dirección encontraréis muchos más epónimos.

Solventada esta primera duda, pasamos a ver las leyes epónimas a las que Phil hace referencia. De las diecinueve originales he seleccionado las que me han resultado más interesantes y cercanas, añadiendo algo de información sobre sus autores, orígenes o curiosidades sobre las mismas. Me tendréis que perdonar por esto, pero voy a partir el post en dos entregas para no hacerlo demasiado largo.

Ley de Postel

Sé conservador en lo que hagas y liberal en lo que aceptes de los demás

Esta frase, de Jonathan Bruce Postel, también llamada Principio de Robustez, es la piedra filosofal del protocolo TCP, y está recogida en la RFC 793, sección 2.10, de septiembre de 1981.

Ley de Parkinson

El trabajo se extiende siempre hasta rellenar la totalidad del tiempo disponible para completarlo

Esta ley fue postulada inicialmente en 1955 por C. Northcote Parkinson en The Economist y más tarde entró a formar parte de su libro, basado principalmente en las experiencias de la administración británica.

Principio de Pareto

Para muchos fenómenos, el 80% de las consecuencias derivan del 20% de las causas

Wilfredo Pareto fue un estudioso de la economía y sociología del siglo XIX, y se fijó que el 80% de las propiedades y riqueza estaban repartidas entre el 20% de la población, enunciando su famoso principio. A partir de ahí, se piensa que esta proporción es cierta en múltiples ocasiones, hasta en el número de bugs en el código fuente de un software, o el tiempo de desarrollo de funcionalidades.

Revelación de Sturgeon

El noventa por ciento de cualquier cosa es una porquería

Theodore Sturgeon era un autor de ciencia ficción americano que escribió esta frase defendiendo a este tipo de literatura de críticos que opinaban que el 90% era basura. Hay un corolario que dice "La revelación de Sturgeon es cierta salvo para la porquería, donde el 100% es porquería".

El principio de Peter

En una jerarquía, todo individuo tiende a subir hasta alcanzar su nivel de incompetencia

Seguro que todos conocéis ejemplos de ello: un fabuloso desarrollador es ascendido a directivo en una empresa, la cual gana un gestor pésimo y pierde un programador excelente. Doble penalización. Lawrence J. Peter, pedagogo de profesión, ya lo enunció en 1968 en el libro El principio de Peter.

Ley de Hofstadter

La realización de un trabajo siempre dura más de lo esperado, incluso habiéndose tenido en cuenta la Ley de Hofstadter

Esta genial y recursiva Ley creada por el científico, filósofo y académico estadounidense Douglas Hofstadter es absolutamente cierta. Y si no, pensad un poco, ¿cuántas veces habéis estimado un desarrollo, lo habéis incrementado de forma considerable por los imprevistos y aún así os habéis quedado cortos?

Ley de Murphy

Si algo puede ir mal, lo hará

La famosa ley, también enunciada en forma de tostada que recurrentemente cae con la mantequilla hacia abajo, fue dictada por Edward A. Murphy, Jr., mientras trabajaba para la fuerza aérea americana como ingeniero, diseñando un sistema de cohetes experimental. Sería lógico pensar que el experimento acabó en tragedia, pero parece ser que la creación y consideración de esta ley les ayudó a evitar graves desastres en sus pruebas.

Ley de Brook

Incluir trabajadores a un proyecto retrasado hará que vaya aún más lento

Fred Brooks postuló esta ley en su famoso libro The Mythical Man-Month: Essays on Software Engineering como resultado de su experiencia en IBM. Existen variantes y corolarios como "Una señora es capaz de tener un hijo en nueve meses, pero este plazo no puede disminuir por muchas mujeres embarazadas que pongamos a ello". Simplemente genial.

Bueno, ya vale por hoy, pero amenazo con prometo seguir pronto.