Saltar al contenido

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript... y lo que venga ;)

17 años online

el blog de José M. Aguilar

Inicio El autor Contactar

Artículos, tutoriales, trucos, curiosidades, reflexiones y links sobre programación web
ASP.NET Core, MVC, Blazor, SignalR, Entity Framework, C#, Azure, Javascript...

¡Microsoft MVP!
Mostrando entradas con la etiqueta curiosidades. Mostrar todas las entradas
Mostrando entradas con la etiqueta curiosidades. Mostrar todas las entradas
martes, 14 de diciembre de 2021
Protocolo HTTP Como sabemos, en las peticiones HTTP se envían al servidor un conjunto de “parámetros” o encabezados que añaden información extra para que la solicitud pueda ser procesada correctamente. Ahí encontramos información sobre el lado cliente, como la cadena de agente de usuario (encabezado user-agent), información sobre la propia petición, como el host al que se dirige la petición (encabezado host) o los idiomas que se aceptan para el contenido (accept-language), e incluso información contextual como las cookies del usuario (cookie) o información de autorización (authorization), entre muchos otros.

Hoy vamos a detenernos en una curiosidad histórica sobre el protocolo HTTP y uno de sus más célebres encabezados :)
martes, 26 de octubre de 2021
.NET Core Hoy va un post rapidito sobre un curioso detalle sintáctico de C# que me llamó la atención hace algún tiempo, mientras leía el artículo How to Stress the C# Compiler, donde Henning Dieterichs comenta varias formas de estresar (¡literalmente!) al compilador de C# utilizando construcciones admitidas por el lenguaje.

La cuestión es: ¿por qué no compila el siguiente código?
class Program {
    public static void Main() {
        int f = 0; int x = 0; int y = 0;
        System.Console.WriteLine(
            "{0} {1}",
            f < x,   // is f smaller than x?
            y > (-1) // is y greater than -1?
        );
    }
}
martes, 28 de septiembre de 2021
Uppercases y lowercases, esos grandes desconocidos :D

Como en otras ocasiones, seguro que debía ser de los pocos que quedaban en este planeta sin saber esto, pero me lo he encontrado mientras pululaba por internet y me ha parecido de lo más curioso. Y como con toda probabilidad habrá por ahí algún despistado más, me ha parecido interesante comentar por aquí mi último gran descubrimiento ;)

La cuestión es que en nuestro mundillo solemos utilizar frecuentemente los términos uppercase y lowercase para referirnos a mayúsculas y minúsculas. Pensaba, erróneamente, que los prefijos upper y lower tenían que ver con el tamaño de los caracteres, y jamás me había dado por preguntarme el por qué de este sufijo "case" tan caprichoso que estas palabras comparten.

martes, 14 de abril de 2020
Enlaces interesantes Es increíble lo rápido que pasa el tiempo: aunque parezca que fue ayer, hace ya diez años que comencé a publicar enlaces interesantes en el blog, iniciando la serie con el post Enlaces interesantes 1... y en estos momentos estoy preparando la entrega semanal número 400 :)

Y para celebrarlo, he pensado que estaría bien hacer un recopilatorio de preguntas y curiosidades que los fieles seguidores de esta serie me habéis ido haciendo llegar, tanto en persona como a través de redes sociales o mails, a lo largo de estos años.
miércoles, 29 de marzo de 2017
Desarrollador volviéndose loco
Imagen original de Pixabay.
La llegada del próximo April Fool's day, algo parecido a lo que por aquí conocemos como el día de los Inocentes, me ha recordado una curiosidad con la que me topé hace algún tiempo que, si tenéis un poco de maldad reprimida, podéis utilizar para gastar una broma a algún compañero desarrollador y echar unas risas.

La historia consiste en abusar del amplio conjunto de caracteres soportado por UTF, sustituyendo el punto y coma de finalización de una línea de código (";") por el símbolo de interrogación griego (";", Unicode 037E), indistinguibles a simple vista, como en la siguiente línea:
public void HelloWorld()
{
    Console.WriteLine("Hello world!");
}
martes, 14 de julio de 2015
C#Desde luego, Stackoverflow, además de salvarnos la vida en numerosas ocasiones, es una fuente infinita de curiosidades, y hoy vamos a ver una que me ha llamado la atención últimamente, aunque sea un tema que lleva circulando por la red muchos años.

El asunto era que un usuario que quería saber cuál era el nombre del operador “-->” existente en muchísimos lenguajes, como podéis comprobar en un código perfectamente válido y compilable en C# como el siguiente:
static void Main(string[] args)
{

    int x = 10;
    while (x --> 0) // while x goes to 0
    {
        Console.Write(x);
    }
    // Shows: 9876543210
}

¿Y cómo se llama ese operador? No puedo negar que al principio me quedé un poco descolocado, como probablemente os haya ocurrido a algún despistado más, pero al leer las respuestas el tema quedaba bien claro que es sólo una cuestión de legibilidad de código, o mejor dicho, de falta de ella, acompañado de un comentario algo desafortunado que incita a la confusión. Complejidad innecesaria en cualquier caso.

En realidad, se trata de dos operadores seguidos, autodecremento y comparación, utilizados de forma consecutiva y abusando de las reglas de precendencia. Sin duda habría quedado mucho más claro de cualquiera de estas formas:
// Mejor: usar los espacios apropiadamente
while (x-- > 0) 
{
    Console.Write(x);
}

// Mucho mejor: usar paréntesis para dejar explícitas las precendencias
while ((x--) > 0) 
{
    Console.Write(x);
}

// Lo más claro: no liarse con expresiones complejas
while (x > 0) 
{
    x--;
    Console.Write(x);
}
WFTs/minutoEste tema lo publicó también Eric Lippert hace algunos años como broma del fool’s day, anunciando un operador que habían añadido a última hora a C# 4.0, aunque al parecer es algo que ya circulaba antes por la red.

En fin, lo que me resultó curioso y quería mostraros en este post es cómo unos simples espacios pueden hacernos ver operadores donde no los hay, introducirnos dudas incluso en algo tan conocido como son los operadores de nuestro lenguaje de programación favorito, y hacer que de un vistazo no entendamos el código que tenemos delante.

Pero ya sabéis: si queréis parecer muy inteligentes y aumentar vuestro ratio de WTFs/minuto en la próxima revisión de código, no dudéis en usarlo ;)

Y si queréis ser ya los reyes de vuestro equipo, tampoco dudéis en usar el operador inverso “<--" que sube un peldaño adicional en el nivel de absurdo:
static void Main(string[] args)
{

    int x = 10;
    while (0 <-- x) // while 0 is approached by x
    {
        Console.Write(x);
    }
    // Shows: 987654321
}

Publicado en Variable not found.
martes, 14 de abril de 2015
PensandoSin duda, posts pertenecientes a la serie recopilatoria de citas célebres relacionadas con el mundo de la informática (primero, segundo, tercero y cuarto) siguen siendo, año tras año, los contenidos más populares de este blog, probablemente por la mezcla de conocimiento, humor, ingenio y realidad sobre nuestro día a día que incluyen estos mensajes.

Tras su última entrega, allá por septiembre de 2012, he continuado recopilando todas las citas que han caído en mis manos y me han resultado curiosas, hasta llegar por fin a las 101 que os traigo hoy. Espero que os iluminen de nuevo o, al menos, que os hagan pasar un rato tan bueno como los que paso yo mientras las voy seleccionando :)
miércoles, 15 de octubre de 2014
Parche informáticoSiempre he pensado que el término “parche” aplicado al desarrollo de software se utilizaba por analogía con el mundo real. Al fin y al cabo, poner un parche en una aplicación es conceptualmente bastante parecido a hacerlo en una rueda pinchada, ¿no?

Pero no, como en otras ocasiones que ya hemos visto por aquí, no es un tema nada conceptual. La realidad es bastante más pragmática, y el uso de la palabra “parche” es literal y simplemente responde a razones históricas.
martes, 25 de septiembre de 2012
PensadorMás de tres años hace ya desde la publicación en Variable not found de la última entrega de esta serie que tanto me divierte (entrega primera, segunda y tercera), y por fin he podido dedicar un poco de tiempo para organizar y seleccionar las citas que he ido anotando desde entonces.

Y aquí está el resultado, 101 nuevas frases célebres relacionadas con nuestro mundillo, que espero que os gusten tanto como las anteriores.

Este es el cuatro post de la serie compuesta por:
¡Que aproveche!
miércoles, 20 de junio de 2012
Barra invertidaDesde los tiempos de MS-DOS llevamos utilizando la barra invertida para separar los nombres de directorio cuando indicamos una ruta hacia un archivo o carpeta, pero, ¿os habéis preguntado alguna vez por qué esto es así?

Como siempre ocurre, nada es fruto del azar.

miércoles, 8 de febrero de 2012
Errores y usuariosSeguro que todos sabéis lo que es tratar con los usuarios de vuestro software: son lentos, patosos, inconscientes, atrevidos, inseguros, ignorantes, y no consiguen entender la belleza de la herramienta que con tanto esmero hemos creado. Y lo que más rabia da es que muchas veces tienen razón en los problemas que reportan de nuestras aplicaciones.

Pero afortunadamente otras veces no es así, y los problemas no son nuestros sino suyos, momento en el que pone a disposición de la dulce venganza la genial creatividad característica de nuestro gremio.

Lo que vamos a ver a continuación son siete de las formas existentes, conocidas y documentadas de cargar las culpas sobre el usuario, o simplemente llamarlo torpe, sin que éste se dé cuenta. Algo muy socorrido si, por ejemplo, debemos contarle a un compañero lo que ocurre en presencia del implicado.

Por supuesto, a partir de aquí todo es secreto, no dejéis que caiga en manos de algún desalmado ;-)

martes, 25 de octubre de 2011
The Tao of ProgrammingHace unos días charlaba con un colega sobre aspectos filosóficos del desarrollo de software, y me pareció curioso que no conociera “The Tao of Programming”, todo un clásico de la literatura friki, y lectura indispensable para los que nos dedicamos a esto.

Este libro, escrito en el año 1987 por Geoffrey James, recoge, en un humorístico tono de misticismo oriental, distintas historias y parábolas con geniales mensajes de fondo sobre calidad en la programación, gestión de proyectos y otros temas que siguen siendo válidos veinticinco años después.

Como probablemente habrá más lectores que no lo conozcan, me ha parecido interesante reproducirlo aquí traducido en su totalidad, por supuesto contando previamente con el permiso expreso del Sr. James.

¡Que aproveche!
Warning: Post largo. Muy largo ;-)
jueves, 26 de mayo de 2011
El veloz murciélago hindú comía feliz cardillo y kiwi. La cigüeña tocaba el saxofón detrás del palenque de paja. 1234567890.
El veloz murciélago hindú...Seguro que, como un servidor, lleváis años sin dormir intentando descifrar este misterioso mensaje con el que nos hemos topado innumerables veces a la hora de instalar fuentes tipográficas en Windows. ¿Por qué un murciélago hindú? ¿Existen realmente los cardillos? ¿Y las cigüeñas saxofonistas? ¿Sería posible construir un palenque de paja?

Pues hoy debe ser mi día de suerte: me he topado casualmente con una entrada de la Wikipedia donde desentrañan el significado de tan inquietante frase, que parece haber sido creada por un perturbado mental o bien por los mismísimos guionistas de Lost (o ambas cosas al mismo tiempo) ;-)

Y la explicación es bien simple: se trata de un pangrama, también llamado frase holoalfabética, que es una frase que contiene todas las letras que componen el alfabeto de un idioma.

Explicado esto, seguro que ya cobra algo de sentido que sistemas operativos como Windows o Linux la utilicen a la hora de mostrar cómo lucen las distintas tipografías. Dado que los pangramas incluyen todas las letras, permiten que el consumidor de las mismas se haga una idea de cómo queda la fuente en un texto. El hecho de incluir al final el número es también por el mismo motivo, así como suele ser frecuente verlo acompañado de la misma frase utilizando exclusivamente mayúsculas.

También suelen utilizarse para practicar mecanografía con objeto de ejercitar todos los dedos de las manos.

Pero la gracia y mérito de los pangramas consiste en construir frases con sentido que incluyan el mayor número de letras del alfabeto en el menor espacio, como las siguientes:
  • Cada vez que me trabo, Félix paga un whisky añejo (39 letras, 100% del alfabeto)
  • ¡Ávida cigüeña floja!, pibonazo quemó whisky extra (41 letras, 100% del alfabeto)
  • Incluso en otros idiomas:
    • The quick brown fox jumps over the lazy dog (Inglés; El veloz zorro marrón salta sobre el perro perezoso)
    • Pa's wijze lynx bezag vroom het fikse aquaduct (Holandés; El sabio lince de papá observó devotamente el formidable acueducto)
    • Um pequeno jabuti xereta viu dez cegonhas felizes (Portugués; Una curiosa tortuguita vio diez felices cigüeñas)
    • Portez ce whisky au vieux juge blond qui fume (Francés; Lleve este whisky al viejo juez rubio que fuma)
  • (puedes ver muchas más en el artículo de la wikipedia)
Y no es nada fácil crear uno; si tenéis afición por las letras podéis echar un buen rato intentándolo ayudándoos de este pangramador.

En fin, cosas curiosas que hay por el mundo…

Publicado en: Variable not found.
domingo, 7 de febrero de 2010
Este post es la tercera y última entrega de la serie 30 Leyes epónimas relacionadas con el desarrollo de software. Puedes encontrar la segunda parte aquí.

Tim Bryce

21. Las leyes de Bryce

Así las llama él, aunque algunas encajarían mejor en una recopilación de frases célebres. Ahí van algunas, aunque pueden encontrarse más de 150 aquí.


Tal y como el uso de la tecnología va aumentando, disminuyen las habilidades sociales

El 85% del trabajo de desarrollo de todos los sistemas consiste en introducir modificaciones y mejoras

A la vez que la capacidad del hardware incrementa, el software se vuelve más pesado

Olvidar al ser humano durante el diseño del sistema provocará que el ser humano se olvide del sistema en el momento de echarlo a andar

[...]

Tim Bryce es un controvertido escritor y consultor de gestión de recursos de información (IRM), famoso entre otras cosas por sus aseveraciones sobre el ego, las manías y extrañezas de los desarrolladores, y sus consejos para manejarlos apropiadamente. Aparte de su habilidad para hacer amigos entre los programadores, es sin duda un gran experto en el mundo de las compañías de desarrollo de software, con más de 30 años a sus espaldas en este campo.

Eugene Spafford

22. Primer principio de Spaf

Si eres responsable de seguridad pero no tienes autoridad para establecer reglas y castigar sus incumplimientos, tu cargo real en la organización es asumir la culpa cuando ocurra algo grave

Eugene Spafford, más conocido como "Spaff", es un reputado experto en seguridad informática y profesor de la Purdue Univertity. Según parece, fue uno de los primeros en escribir un libro sobre virus informáticos en 1989, utilizar el término autopsia software para referirse al análisis de aplicaciones para intentar localizar a sus autores, y un sinfín de aportaciones al mundo de la seguridad en sistemas informáticos.

Además, es tan prolífico creando frases y analogías a la hora de explicar conceptos de informáticos que Mahesh V. Tripunitara, uno de sus estudiantes, mantiene una página donde las recoge: "The Page of Spaf's Analogies".

Aloysius Alzheimer

23. Ley de Alzheimer de la programación

Si lees un código que escribiste hace más de dos semanas es como si lo vieras por primera vez
Efectivamente, el psiquiatra y neurólogo alemán Aloysius Alzheimer no enunció esta ley a primeros del siglo pasado, pues estaba muy ocupado estudiando las enfermedades mentales de sus pacientes. Sin embargo, el síntoma de pérdida de memoria tan habitual en ellos propició la utilización de su nombre en esta Ley tan ligada a la escritura de código limpio, documentado y sencillo.

Roy Amara

24. Ley de Amara

Tendemos a sobreestimar el efecto de la tecnología en el corto plazo y a subestimarla a largo plazo
Esta ley, causa de la existencia de problemas debidos a excesos de optimismo o de la formulación de predicciones disparatadas, fue enunciada por Roy Amara, que fue presidente del Instituto para el Futuro, un grupo de investigación sin ánimo de lucro dedicado al análisis de tendencias que ayuden a la toma de decisiones basándose en predicciones sobre el futuro.

Barbara Liskov

26. Principio de Liskov

Los subtipos deben ser sustituibles por sus clases bases
O en otras palabras, que un subtipo no debe modificar el comportamiento esperado de la clase de la que hereda; de esta forma, si el subtipo puede sustituir a su clase base sin causar daños, la herencia será correcta. Citando a Enrique Place en PHPSenior, "No basta con ser hay que comportarse como tal".

Barbara Liskov es profesora del Massachusetts Institute of Technology (MIT) y fue la primera mujer en conseguir el doctorado en informática de Estados Unidos.

Hick no se dejó hacer la foto ;-)

25. Ley de Hick

El tiempo que se tarda en tomar una decisión aumenta a medida que se incrementa el número de alternativas
Puede sonar a obvio, pero la cuestión es que William Edmund Hick, pionero en psicología experimental y ergonomía, fue capaz de idear, a mediados del siglo pasado, la fórmula que explica por qué tardamos tanto tiempo en responder a un cuadro de diálogo con botones para Aceptar, Cancelar, Reintentar, Ignorar y Omitir:
T = blog2(n + 1)
Cosas de las matemáticas, seguro. :-D

Robert A. Heinlein, uno de los posibles padres del principio de Hanlon

27. Principio de Hanlon

Nunca le atribuya a la maldad lo que puede ser explicado por la estupidez
A pesar de su nombre, no está claro quién definió con tanta claridad su confianza en la capacidad del ser humano. Bill Clarke, Goethe, William James, Napoleón Bonaparte, Richard Feynmann, Einstein, Robert A. Heinlein (cuyo apellido podría haber degenerado en "Hanlon"), o un desconocido Robert J. Hanlon del que no existen demasiadas referencias podrían ser los padres de esta Ley tan utilizada por los hackers para definir situaciones creadas como consecuencia del trabajo de incompetentes sin mala intención.

Bill Joy

28. Ley de Joy

El número de empleados inteligentes en una empresa es una función logarítmica del número de empleados totales
También formulada como "no importa quien seas, la mayoría de la gente inteligente trabaja para otro", la Ley dictada por Bill Joy ofrece una visión un tanto pesimista (¿realista?) de nosotros mismos y nuestro entorno de trabajo. Pero ojo, que no lo decía cualquiera, que este señor es co-fundador de Sun y, probablemente, estuviera describiendo lo que veía.

Tim Lister

29. Ley de Lister

La gente bajo presión no piensa más rápido
Bonita frase para escribir en un post-it y pegárselo en la frente a alguien a ver si se da por aludido. Y es que efectivamente, la presión y la velocidad de pensamiento no son magnitudes proporcionales, pero es Tim Lister, un consultor, formador y escritor experto en gestión de riesgos en procesos de desarrollo de software, el que lo enunció de esta forma tan tajante y certera.



William of Ockham

30. La navaja de Occam

En igualdad de condiciones la solución más sencilla es probablemente la correcta
En el siglo XIV, Guillermo de Ockham, fraile franciscano y filósofo, postulaba de esta forma el principio de economía, utilizada en disciplinas tan dispares como la teología, informática o lingüística. De hecho, podríamos considerarlo la base de principios como KISS (Keep It Simple, Stupid), o YAGNI (You ain't gonna need it), asociados habitualmente a la programación extrema pero válidos en cualquier tipo de desarrollo.

Una curiosidad, el tercer episodio de la primera temporada de la serie House tenía este título, haciendo referencia a la solución del caso médico propuesto.




Fuentes:

Publicado en: Variable not found.
Este post es una continuación de 30 Leyes epónimas relacionadas con el desarrollo de software.

Linus Torvalds

11. 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 en las que exponía las ventajas del modelo de desarrollo cooperativo y abierto frente al propietario; otros simplemente ven esta teoría como una barbaridad desde el punto de vista de la seguridad y mantenimiento de los sistemas.

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.

David P. Reed

12. 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, que explica en esencia la facilidad con la que crece el número de subgrupos posibles entre usuarios en relación al número de usuarios o de pares.

Gordon Earl Moore

13. 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, era una declaración de intenciones, o simplemente es 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.

Niklaus Wirth

14. 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.

¿Será coincidencia que en ese mismo año, 1995, fue el lanzamiento oficial de Java? ;-P

Jamie Zawinski

15. 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 que critica el crecimiento, a veces sin sentido, del software, 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, padre entre otros de una versión de Netscape, Grendel, Netscape Mail & News, Lucid Emacs, etc. También es curioso que es propietario de un club nocturno en San Francisco, este sí que sabe ;-)

Sir Arthur C. Clarke

16. Las tres Leyes de Clarke

Primera Ley de Clarke

Cuando un anciano y distinguido científico afirma que algo es posible, probablemente está en lo correcto. Cuando afirma que algo es imposible, probablemente está equivocado.

Segunda Ley de Clarke

La única manera de descubrir los límites de lo posible es aventurarse hacia lo imposible.

Tercera Ley de Clarke

Cualquier tecnología lo suficientemente avanzada es indistinguible de la magia.
El conocido científico y escritor británico Sir Arthur Charles Clarke enunció estas tres leyes porque, según comentaba, "si tres leyes fueron suficientes para Newton, modestamente decido parar aquí".

Arthur C. Clarke fue autor de un gran número de libros, relatos y obras de divulgación, destacando su novela y participación en el guión de 2001: Una odisea en el espacio.

Scott AdamsDilbert

17. El principio de Dilbert

Las compañías tienden a ascender sistemáticamente a sus empleados menos competentes a cargos directivos para limitar así la cantidad de daño que son capaces de provocar
Este complemento perfecto para el Principio de Peter fue observado por Scott Adams, autor de Dilbert, una popular tira cómica sobre el mundo de la empresa que se publica en 1200 periódicos de todo el mundo.

Scott Adams es considerado uno de los 50 pensadores más influyentes en el mundo de la empresa, incluso por encima de personajes como Steve Jobs o Al Gore. Se trata, además, de un epónimo curioso en cuanto a que su nombre no proviene directamente de su autor, sino de la obra de su autor.

George Gilder

18. Ley de Gilder

El ancho de banda aumenta a un ritmo tres veces superior a la potencia de los ordenadores
Pues sí, cualquiera lo hubiera dicho hace unos años... pero la verdad es que hoy en día la velocidad en las conexiones a la red son increíbles. Y por suerte, sin subir proporcionalmente el coste ;-)

George Gilder es un controvertido escritor e intelectual americano, entusiasta de la tecnología e internet, que en la actualidad dirige el Gilder Technology Report, un sitio exclusivo de información de ámbito económico y tecnológico. Según comentan, "sus hijos no estudian español, sino C++" (visto en Wikiquote).

Gene Amdahl

19. Ley de Amdahl

El incremento de velocidad de un programa utilizando múltiples procesadores en computación distribuida está limitada por la fracción secuencial del programa

Esta ley, de gran aplicación en el cálculo de rendimiento de sistemas cuando uno de sus componentes es mejorado o en contextos de procesamiento en paralelo, fue enunciada por Gene Myron Amdahl en 1967, en sus tiempos como trabajador de IBM Corporation, que abandonó varias veces por disconformidad con el escaso trato humano en esta empresa, muy encorsetada y llena de burocracia.

Según demuestra matemáticamente, llegados a un punto el rendimiento de un sistema no está relacionado con el número de procesadores instalados, sino con la eficiencia de los algoritmos empleados.

Nathan Myhrvold

20. Ley de Myhrvold

El software es un gas; se expande hasta rellenar su contenedor
Claro, esto explica por qué da igual la potencia y capacidad del ordenador que tengamos: nuestro software lo llenará como si se tratara de un globo, hasta ponerlo a reventar.

Y lo dijo ni más ni menos que Nathan Myhrvold, ex-director de tecnología de Microsoft y fundador de Intellectual Ventures, una empresa dedicada crear y patentar, pero curiosamente no a poner en explotación, inventos para sectores como el software, semiconductores, redes, lásers, biotecnología y otros dispositivos.

Continuar en 30 Leyes épónimas relacionadas con el desarrollo de software (y III).

Publicado en: Variable not found
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 procede de su lugar de origen.

Hace unos años, el gran Phil Haack posteó sobre leyes epónimas relacionadas con el desarrollo de software en "19 Eponymous Laws Of Software Development", y seleccioné las que me resultaron más interesantes en un par de posts.

Ahora los he vuelto a maquetar y les he añadido un nuevo conjunto de leyes muy interesantes para todos los que nos dedicamos al mundo del desarrollo de software, y muchas de ellas incluso aplicables a otros ámbitos.

John Postel

1. 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.

C. Northcote Parkinson

2. 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.


Vilfredo Pareto

3. Principio de Pareto

Para muchos fenómenos, el 80% de las consecuencias derivan del 20% de las causas
Vilfredo 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.



Ted Sturgeon

4. Revelación de Sturgeon

El noventa por ciento de cualquier cosa es basura
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 una porquería.

Hay un corolario que dice "La revelación de Sturgeon es cierta salvo para la basura, donde el 100% es basura".

Lawrence J. Peter

5. 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.

Douglas Hofstadter

6. 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 plazos en un desarrollo, lo habéis incrementado de forma considerable por los imprevistos y aún así os habéis quedado cortos?


Edward A. Murphy

7. 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.

Frederick Brooks

8. Ley de Brooks

Incluir trabajadores en un proyecto retrasado hará que éste avance aún más lentamente
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.

No se dejó hacer la foto ;-) Este es uno de los diagramas usados en el paper 'How Do Committees Invent?' donde presentaba sus ideas

9. 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, extrapolando un poco... ¿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

Auguste Kerckhoffs

10. Principio de Kerckhoffs

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 lingüista y criptógrafo alemán, enunciara en el siglo XIX este principio, base de todos los sistemas de criptografía de clave pública actuales.



Publicado en: http://www.variablenotfound.com/.
lunes, 18 de mayo de 2009
PensadorHa transcurrido un año desde que publiqué mi recopilación de citas célebres del mundo de la informática, como continuación de la serie iniciada originalmente por el amigo Timm Martin en DevTopics. Desde entonces he ido anotando todas las citas que me llamaban la atención, hasta que por fin he llegado al número mágico y puedo publicar el tercer post de la serie que tanto me divierte. Que aproveche.

Este es el tercer post de la serie compuesta por:
domingo, 26 de abril de 2009

David J. Bradley (Fotografía: Charles Harris)

La combinación de teclas Control-Alt-Suprimir lleva con nosotros prácticamente desde el principio de los tiempos ayudándonos a escapar de callejones sin salida. Y como muchas otras pequeñas cosas de la vida, tiene su curiosa historia por detrás.

David Bradley era uno de los doce ingenieros que trabajaron en el diseño del IBM PC original a principios de los años 80, implementando el código de la ROM BIOS.

El objetivo inicial era crear una combinación de teclas exclusivamente para que los desarrolladores y escritores técnicos pudieran resetear el ordenador en caliente, de forma rápida, puesto que el apagado manual requería la espera de algunos segundos antes de volver a encenderlo para evitar daños a la fuente de alimentación, y cuando esto había que repetirlo muchas veces al día, como era el caso, la pérdida de tiempo era considerable.

De hecho, al principio ni siquiera se pensaba en trasladar esta función a los usuarios finales de estos ordenadores, pero finalmente resultó tan útil y ahorraba tanto tiempo que difundió y popularizó rápidamente entre los usuarios.

image La combinación original de teclas era Control-Alt-Escape, pero pensaron que de esa forma alguien podía pulsarlas accidentalmente al encontrarse todas en el lado izquierdo del teclado. Por ello, finalmente se decantaron por una secuencia que era imposible, en los teclados de entonces, reproducir con una única mano. Había nacido el Control-Alt-Suprimir, y para muchos, un icono cultural de nuestros tiempos.

David Bradley también es famoso por la frase que tanto hizo reír a casi todos durante la celebración del 20 aniversario del IBM PC:

“Yo lo inventé, pero Bill lo hizo famoso”

Bradley se retiró en 2004, tras cerca de 29 años trabajando en IBM.

Publicado en: www.variablenotfound.com