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.
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.
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.
Algún día tendré que ponerme a jugar con Android y desarrollar un programita (o más) pero la pereza continúa pudiendo conmigo y retrasando este propósito. Mientras tanto, un recurso interesante. En A Deep Dive Into Location Reto Meier va mostrando diversas ideas y trucos para desarrollar una aplicación basada en localización con el objetivo de:
Rather than shaking my fist at the sky, I’ve written an open-source reference app that incorporates all of the tips, tricks, and cheats I know to reduce the time between opening an app and seeing an up-to-date list of nearby venues – as well as providing a reasonable level of offline support — all while keeping the impact on battery life to a minimum.
Definitivamente interesante.
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…
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.
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.
En Olores de código (Code Smells). Ya hablábamos antes de las metodologías ágiles de este tipo de problemas pero no hay que negar que la literatura con la que lo adornan los hacen todavía más atractivos.
Buscando, encuentro aquella entrada sobre la complejidad y la seguridad.
La respuesta en why GNU grep is fast y lo explica haciendo referencia a los aspectos técnicos pero sin meterse mucho en los detalles.
Esencialmente:
Se utiliza el algoritmo de Boyer-Moore, que tiene como ventaja que evita mirar los bytes uno a uno, porque es capaz de evitar algunos basándose en información sobre lo que se busca (letra final, tamaño y aprovechándolo para dar saltos más grandes).
Pocas operaciones sobre cada byte de los que realmente se miran.
Además, el bucle interno está ‘desenrollado‘, lo que le evita algunas operaciones extra (las de control del propio bucle, claro). También evita pensar en líneas (salvo cuando ‘cree’ que ha podido encontrar lo que buscaba y trata de gestionar mejor la memoria para que la lectura sea más eficiente.
¿Alguien se anima a echarle un ojo al código?
mbpfernand0
