One of the tools I use to make figures for papers and books—if I need to make a graph, of course—is Graphviz. Graphviz is flexible, powerful, but also a rather finicky beast that will repeatedly bite your fingers. Today, I’ll share some of my tricks with you.
There are many reasons why you’d like to know if your user liked something or not. It can be used later for recommendation, for example, or to assess whether or not the users want the new feature you’ve just added. And it seems to me that not only the question but also the choices of answers offered matters a lot.
So, let’s say you add an (optional) survey to your application to collect feedback. You can ask a yes/no question like “do you like the new feature?”. The obvious yes/no answer isn’t so obvious. If the users select yes, it means yes, but what if they click no?
A friend of mine, Arthur, is developing a voxel-based game and found himself having to deal with large volumes of data. Unlike 2½D games where the map is essentially a 2D expanse with occasional relief, his game allows the definition of things in full (discrete) 3D.
To avoid loading the entire map in memory, he made the wise design decision of making his world tile-based, so that it can, simultaneously, reduce the working set as well as having an essentially open map, by loading only a small set of visible world blocks at all time. So together we took a look at compressing these world blocks, and it turned out that we can do a lot with fairly simple algorithms and VLCs.
Programmers aren’t always the very rational beings they please themselves to believe. Very often, we close our eyes and take decisions based on what we think we know, and based on what have been told by more or less reliable sources. Such as, for example, taking red-black trees rather than AVL trees because they are faster, while not being able to quite justify in the details why it must be so. Programming using this kind of decision I call cargo cult programming.
Originally, I wanted to talk about red-black vs. AVL trees and how they compare, but I’ll rather talk about the STL std::map that is implemented using red-black trees with G++ 4.2, and std::unordered_map, a hash-table based container introduced in TR1.
Frank Mittelbach, Michel Goossens, Johannes Braams, David Carlisle, Chris Rowley — The LATEX Companion — 2nd ed, Addison Wesley, 2006, 1090 pp. ISBN 0-201-36299-6
I should have told you about this book a long time ago. The LaTeX Companion is the definitive guide to LaTeX, ideal for anyone using it on a daily basis (or almost, as I do) or anyone wanting to learn LaTex. LaTeX is a complex and sophisticated mark-up language aimed at producing better typography for mathematics and scientific work—in which it totally succeeds. As for Linux, LaTeX (and TeX) comes in many distributions, some more geared toward the humanities, other for science, and still other for exquisite “art” typesetting.
A must read for graduate students.
On the web:
Donald A. Norman — The Design Of Everyday Things — Basic Books, 2002, 257 pp. ISBN 0-465-06710-7
In the same lineage than Machine Beauty, this books explores the fundamental rules of good design. Built around the following seven precepts, Norman lays out the problems (and solutions) to good design:
- Use both knowledge in the world and knowledge in the head
- Simplify the structure of tasks
- Make things visible: offer feedbacks for actions
- Get the mappings right
- Exploit the contraints, both natural and artificial
- Design for error
- When all else fail, standardize
The book is filled with examples of each principle. Fully annotated and with numerous references, this book (although a bit aged) will serve as a good introduction to the subject, especially for people interested in the design of user interfaces (while, however, the books is not very concerned about computers as the original edition was written in the late 80s).