sábado, 27 de junio de 2009

Consejos para APIs

Leo en el blog de lightsleeper unos consejos para hacer APIs.

  • Deben ser intuitivas. Los nombres han de ser significativos y deben dar una idea de lo que hacen las funciones sin tener que leer los documentos.
  • Deben ser simples. Es decir, seguir el principio KISS y si pueden hacer sólo una cosa en vez de dos, mejor. Cuantos menos parámetros mejor, cuantas menos funciones mejor, cuantos menos tipos mejor.
  • Debe ser difícil equivocarse. Con pocos estados, pocos errores y con un tipado que evite que compile si se intentan hacer cosas mal. Los fallos se deben detectar en compilación y no en ejecución.
  • No deben tener efectos secundarios. Realmente esto es parte de la simplicidad. Tener estados ocultos, variables globales perdidas y demás complica la cosa.
  • Debe ser consistente. En el nombrado de funciones y parámetros, en el orden de las mismas, en la nomenclatura de tipos, variables y demás opciones estilísticas. También deben usarse las convenciones conocidas ("ptr" es puntero y no "poi", etc.)

Hay un par de puntos relativos a la hora de revisar las API que no voy a incluir porque prefiero este punto que leí en algún otro lado:

  • La regla del tres: Haz tres programas que usen la API. Si usas uno, seguro que luego te van a faltar o sobrar cosas. Si usas dos te quedarán bugs y sutilezas. Con tres también, pero serán menos y la API será usable.

Finalmente, otro consejo que leí por ahí tiempo ha:

  • Una API es un lenguaje. Cada palabra debe ser un concepto. Cuando dos desarrolladores hablen de tu API deben hacerlo en ese lenguaje especial que has inventado.

martes, 23 de junio de 2009

¿Recolección de basura?

Leyendo barrapunto he llegado a una página donde muestran una gráfica sobre el consumo de memoria de los navegadores. La gráfica en cuestión es esta:


Lo primero que sorprende es la forma de diente de sierra del consumo de memoria. Rápidamente se me viene a la cabeza que se esté usando un recolector de basura y las caídas bruscas son cuando se realiza la limpieza. Por esa misma regla de tres, parece que el navegador Opera no realiza recolección de basura o que, incluso, pueda tener algún escape de memoria.

Es una pena que no tengamos información sobre el comportamiento de los programas cuando están en fase de limpieza. ¿Algún usuario de estos navegadores ha notado cuándo se ejecuta el recolector de basura? Y, otra cosa, ¿no había por ahí un navegador que se llamaba Explorer o algo así?

jueves, 18 de junio de 2009

De bits y binits

Estudiar y aprender es llevarse sopresas. Una de las sorpresas que nos llevamos al aprender teoría de la información es que un bit no es lo que crees que es un bit. Algo que está a uno o a cero, encendido o apagado, pasando corriente o cortándola, ¿no? Pues no. Un bit es algo que está a uno o a cero el 50% de las veces. Si no, no llega a bit. Será medio bit o un cuarto de bit.

La siguiente gráfica indica cuál es la entropía (información en bits) de un binit según la probabilidad de estar a uno o a cero. (Tomada de Wikipedia)

La idea es que el bit es una unidad de información y no de almacenamiento. La unidad de almacenamiento es el binit. Es un hueco donde poder guardar un uno o un cero. Si siempre se guarda un cero o siempre se guarda un uno la información es nula y por tanto ese binit guarda cero bits de información.

Hoy por hoy el concepto de binit se ha fusionado con el concepto de bit y hablamos de megabits por segundo en vez de megabinits por segundo lo cual permite a algunos hacer trampa y "comprimir la información" como si eso fuera posible. En todo caso comprimes la representación de la información. Los binits, no los bits. Pero eso ya son otras divagaciones de las que no vamos a hablar hoy.