Category: programming

Kludge

Según Wikipedia, un “…kludge (or kluge) is a workaround, a quick-and-dirty solution, a clumsy or inelegant, yet effective solution to a problem, typically using parts that are cobbled together.” Esta palabra la encontré por primera vez en un libro de Andrew Tanenbaum, hace ya muchos años. El contexto, no lo recuerdo. En todo caso, la computación es una de las disciplinas donde abundan los kludges, y a veces, o muchas veces, pueden tolerarse con cariño. La experiencia profesional me ha permitido ver cualquier cantidad de éstos, y también, humildemente, contribuir con su perpetuación. Por cierto, para las decisiones post-kludge, no olvidar nunca que si un sistema está funcionando perfectamente, lo mejor es dejar las cosas como están, no alterar nada.

Resizing multiple image files

For the Ponyo post I had a bunch of PNG 853×480 screenshots. At first, the post used 300×168 images, resized by the blog’s engine, such as the below one:

However, the ideal width for images in this blog is about 600 pixels:

For resizing multiple files I recurred to ImageMagick command line tools (here are some Windows Binary Releases). On Windows command prompt, it’s enough to type:

forfiles /M *.png /C “cmd /c convert -resize 70% @file resized_@file”

That way all of the images will have resized versions, at 70% their original size, yielding a 597-pixels width.

The Hobgoblin

Without a doubt, performance is a cornerstone of a great user experience. Like security, it is the most misunderstood and oft-used scapegoat of the software developer. It’s not uncommon to hear developers reject ideas with a flippant, “We can’t do that, it will negatively impact performance.” Rarely quantified and frequently cited, performance is the hobgoblin of software development. How do we quantify performance? Latency is a form of performance. Execution, the time an operation takes to perform, is another.

Andre Charland and Brian Leroux (Mobile Application Development: Web vs. Native, Communications of the ACM, May 2011)

Note: They are discussing about mobile applications. On such context, latency is related to the time required by an application to start executing (which involves download rates and code initialization). Execution, in turn, comprises interpretation of code. Any downside in execution, they argue, is paid off by the ease of writing and mantaining a high-level, interpreted code. And indeed, “we can’t do that, it will negatively impact performance”. Right now I’m floating on the delusion of smooth particle effects and video rendering.

Jouer avec le feu

Quelques faits semblent établis. Les auteurs de ce virus ont disposé de temps (environ dix « années-ingénieur » de travail) et de connaissances rares. « L’analyse de son code indique clairement que Stuxnet n’a pas pour but d’envoyer un message ou de démontrer un concept, écrit Langner. Il s’agit de détruire [des] cibles. »

Cyber-attaque contre Téhéran (article par Philippe Rivièr,
dans Le Monde Diplomatique, Paris, mars 2011, p. 10)

 

Note: Il est vraiment important, mais Stuxnet est un ver, pas un virus.

Why adding people to a late software project makes it later?

That statement is known as Brooks’s Law, and it was coined by the renowned computer scientist and software engineer Frederick P. Brooks. Concretely, the original statement found in his 1975 classic The Mythical Man-Month is “adding manpower to a late software project makes it later”. Basically, the idea is that adding more analysts, designers or programmers to a project running behind the original schedule will delay it even more.

Broadly speaking, the rationale of Brooks’s law is related to knowledge management. First, when new personnel is added to the project, some resources have to be diverted into training or informing the newcomers about the project’s status, vision and philosophy. That will delay the project. Further, when the number of people participating in a project increases, so does the number of communication paths. Thereby, more resources (including time) are required in order to distribute the information. Regarding this point, you may be interested in reading my entry on “Knowledge Sharing” in Software Design, Trials and Errors.

An E(x)tern Newbie Question

I want to know how to declare a const variable in one file and access it from other files? (C++). It’s a fairly basic question, and reveals that you have to study more C++. What you want is to define a const variable at global scope. Unlike non-const variables (which are extern by default), const variables are local to the file in which they are defined. Therefore, you cannot access them from other files unless you specify that the variable is extern. For instance, if you specify extern when defining the variable

bufferSize in file1.ccextern const int bufferSize = 512;

you can access bufferSize from any other file, say, file2.cc

extern const int bufferSize; // we are using bufferSize from file1.cc

And that’s it.

Reentrant Routine

A routine or procedure P is reentrant (or pure code) if it can be “re-entered” after it is already in execution. Basically, it means that P can be executed two or more times simultaneously, or alternatively, that P can be safely executed concurrently. There are some conditions P must follow in order to be reentrant, and we may check them in the Wikipedia entry for reentrant functions.

Some programs necessarily have to be reentrant. For instance, device drivers. A device driver has to be reentrant because another interrupt may be raised while the driver is running. This means that reentrancy allows for code sharing. For example, if a program consists of 600 KB of code and 200 KB of data, and n users are simultaneously using the program, we would require n x 600 KB of physical memory for the code if the program is not reentrant. But if the code is reentrant we can share it among the n users, saving a lot of memory.

The Nightmare before Christmas

Improbable que unos días antes de Navidad se encuentre usted inmerso en los ajustes finales de un salvapantallas (protector de pantallas/screensaver). Su salvapantallas utiliza OpenGL para el renderizado, y corre en Windows. Flujos lógicos perfectamente sincronizados, compiladores felices, arte gráfico hermoso. Prueba A superada. Prueba B superada. El problema apareció en la prueba N. En específico, que su salvapantallas funcionó perfectamente en todas las máquinas, menos en aquella laptop con gráficos Intel. En esa máquina, triste e inexplicablemente, su salvapantallas no dispone de aceleración 3D. La máquina es capaz de aceleración 3D -mil veces comprobado-, y sin embargo, su lindo salvapantallas no puede aprovechar dicha aceleración. En esa laptop, su salvapantallas se ejecuta con una lentitud intolerable, parece un aborto en software. ¿Por qué todos los otros programas corren con aceleración 3D en esa laptop, pero su salvapantallas no? ¿Por qué? ¿Razones esotéricas? Después de todo, a nivel de ejecución, un salvapantallas es simplemente un ejecutable con extensión “scr” (obviemos, por innecesarios, los detalles sobre el procesamiento de la línea de comandos, el enlace con scrnsave.lib -si elige esa vía-, y algún otro escarmiento propio de los salvapantallas). Deseo que no pierda vitales minutos de su vida prisionero de dicha pesadilla. La razón -o sinrazón- del fiasco está aquí. Si observamos con cuidado, la única diferencia entre su salvapantallas y el resto de ejecutables que sí reciben aceleración 3D es la extensión del archivo. Alguien, en alguna parte del sistema, está detectando la extensión “scr” de nuestra aplicación y le niega la aceleración 3D. Bueno, cambie la extensión. En vez de “scr”, use “sCr” o algo así. Parece tonto -y lo es- pero funciona. De nada.