Algunas ideas sobre nombres en programas

Los nombres son importantes; sobre todo cuando tenemos que usarlos más veces después de hacer un programa. En On Naming se discuten algunas ideas y lo traigo aquí porque hacía tiempo que no veía mucha discusión sobre esto. Supongo que se da por hecho que hay que tener cuidado, pero nunca viene mal recordarlo.

Anuncios

¿Seguro que es el mejor algoritmo?

Cambiamos un poco de tema. En Think you’ve mastered the art of server performance? Think again. el análisis del coste de una solución cuando empiezan a entrar diversos factores que afectan a cómo la teoría interpreta los resultados.

Por ejemplo, algunas suposiciones puede ser importante:

A quick browse of the mental catalog flipped up the binary-heap card, which not only sports an O(log2(n)) transaction performance, but also has a meta-data overhead of only a pointer to each object—which is important if you have 10 million+ objects.

La memoria virtual:

It took quite some time before virtual memory took hold, but today all general-purpose, most embedded, and many specialist operating systems use VM to present a standardized virtual machine model (i.e., POSIX) to the processes they herd.

Y como seguimos ignorándola a la hora de medir teóricamente algunas cosas:

The fact is, however, 46 years later most CS-educated professionals still ignore VM as a matter of routine. This is an embarrassment for CS as a discipline and profession, not to mention wasting enormous amounts of hardware and electricity.

Por eso,

What good is an O(log2(n)) algorithm if those operations cause page faults and slow disk operations? For most relevant datasets an O(n) or even an O(n^2) algorithm, which avoids page faults, will run circles around it.

Por eso, nosotros siempre recomendamos medir teóricamente para tener una idea de por donde van los tiros. Pero luego probar con nuestros sistemas reales y con los datos de verdad, para estar seguros de que los resultados teóricos se mantienen.
Y, por supuesto, esto nos da pistas de por qué es importante saber de hardware, del sistema y tratar de estar al día en muchos de estos temas.

Divertido, ¿no?

Siete recomendaciones sobre vim

No se si es cosa mía o realmente está habiendo un resurgir del conocido editor vim pero el caso es que últimamente veo más referencias por ahí.

En una de ellas encontré el Seven habits of effective text editing que puede ser un buen repaso para los más expertos y descubrirle alguna novedad a los que no lo sean tanto.

Como decía, no es lo único que he visto y otra lectura recomendable podría ser el Vim: revisited sobre las configuraciones del ‘bicho’.
Interesante pero ya algo más técnico.

Siempre hay sitio para la optimización

La optimización del código que se ejecuta en nuestros programas es un tema clave (y con el que hay que tener cuidado sobre todo antes de tiempo).
Por eso me gustó leer A Python Optimization Anecdote donde nos cuentan los pasos seguidos para mejorar una función para evitar Cross-Sie scripting en Dropbox.

En resumen: probar, medir (y para eso hay que tener casos de prueba *nuestras pruebas, nuestros datos*) y ver cómo afecta a nuestro código con nuestros datos los cambios que hagamos:

Conclusions
The first, most basic conclusion is that the basic facts of Python
optimization inline functions, use implicit loops, move computation into C
if possible are perfectly valid. Another fact: Python dictionaries are
*fast*. The WHITELIST set and the CACHE_HTML_ESCAPES dict both rely on the
superb hash table implementation for their performance gains.

Other “common wisdom”, like using locals instead of globals, yields
relatively little gain.

Optimizing inner loops in a high-level loops requires lots of trial and
error. It was absolutely amazing that moving to string concatenation from
string interpolation gave such a huge boost to performance.

Finally, measurement is key. It was measurement that told us that HTML
escaping was slow to begin with; and without measuring performance, we
would never have guessed that string interpolation was so slow.

El tamaño (del código) importa

En Size is the best predictor of code quality un par de enlaces y punteros a estudios sobre el tema (cuando los lea tal vez volvamos sobre ello).
Comenta sobre las métricas de código y su impacto en la robustez y fiabilidad del código y cómo parece que el tamaño sigue siendo un buen predictor.

Creo que habíamos hablado del tema en algún momento, pero no lo encuentro.

Algunas particularidades de C que olvidamos

Estaba terminando de leer un recomendado de Mig 21, concretamente Deep C (and C++) cuando me encuentro en la pila dependientes de publicar otro (que probablemente también encontré gracias a él): [PDF] Finding and Understanding Bugs in C Compilers que trata justamente de eso: el estándar de C es complicado y tiene sus cosillas indefinidas, intedeterminadas y (de vez en cuando) malinterpretadas. Los autores han creado Csmith, que genera programas aleatorios en C acordes con el estándar C99 y les sirve para comprobar que los compiladores (y otras herramientas) efectivamente hacen lo que tienen que hacer.

A mi, en su día cuando lo lei me recordó aquel clásico Reflections on Trusting Trust de Ken Thompson; también me sirvió para desempolvar un poco el C y recordar cosillas (en la línea que sugiere la primera presentación).

Siguiendo en esta línea, en Lo que todo programador de C debería saber sobre el “comportamiento indefinido” (se ve que es un tema que le gusta) podíamos acceder a más información en esta línea:

A Guide to Undefined Behavior in C and C++, Part 1.
A Guide to Undefined Behavior in C and C++, Part 2. Y, finalmente:
A Guide to Undefined Behavior in C and C++, Part 3.

Y, otra serie de 3:

What Every C Programmer Should Know About Undefined Behavior #1/3,
What Every C Programmer Should Know About Undefined Behavior #2/3 y, finalmente:
What Every C Programmer Should Know About Undefined Behavior #3/3.

Definitivamente, buenas lecturas para entretenerse en esta semana en la que, tal vez, tengan algún festivo más que en otras…

Matriz de competencias para programadores

En Programmer Competence Matrix publican una serie de competencias que deberían tener distintos tipos de informáticos a lo largo de su carrera y experiencia profesional. Sobre ello comenta Greg Wilson en Competence y encuentra paralelismos con otra tabla, en esta ocasión relacionada con la enfermería.

Fortalecimiento de PHP

Algunas generalidades sobre la configuración de PHP (siempre que podamos tocarla) en Hardening PHP mediante php.ini. Los lenguajes van ofreciendo estas medidas para remediar fallos detectados a un nivel más profundo. No es la panacea (e, insisto, a lo mejor ni siquiera podemos tocarlo, o los programas no funcionan) pero puede ser una buena idea echar un vistazo.

La recursividad no es difícil

En Stop Telling Students Recursion is Hard hacen un elogio de la recursividad y la explican com método de razonamiento para desarrollar programas y el pensamiento computacional.

Yo tampoco creo que sea difícil (es más, como dice el autor, ayuda a comprender algunas cosas y a hacerlas mejor aunque luego no se utilice) pero muchas veces chocamos con el pensamiento de los que están acostumbrados a otros paradigmas y la habitual resistencia a los cambios y novedades.

Fallos frecuentes con Javascript

En la bitácora de desarrolladores de Tuenti una nota sobre las Top 13 JavaScript Mistakes.
Es muy interesante que gente que desarrolla aplicaciones del ‘mundo real’ proporcione esta realimentación a otros.