|Ned Batchelder : Blog | Code | Text | Site|
» Home : Blog
The Greater Boston Walk Now for Autism fundraising walk will be in two weeks, and my family and I will be walking.
It's a really good cause: advancing and accelerating autism research. I won't beat you over the head with the latest figures and alarming factoids — if you want more info about autism, the Autism Speaks site has all of it. For more personal views of the condition, look at my autism posts or my wife Susan's blog.
I'd appreciate any support you can give, either by donating or even joining in on the day of the walk (October 14). In the past, I've been enormously touched by the number and variety of people who gave even a small amount, so thank you.
I have long been confused by the super() function in Python. It's used to call a method on the base class of an object. Why not simply invoke the base class directly, like we used to?
And shouldn't the argument to super be Base, not Derived? It doesn't seem to make any sense. I finally was truly confused when deriving a class from two base classes. If I only have one call to super, how do I make sure that both base class methods get called? Poking around for an answer, I finally found a good explanation of what super() is for. Ironically, it is a polemic about why super() is no good: Python's Super Considered Harmful. Skip the part about Dylan, and read about the Python, and finally understand...
It turns out multiple inheritance is where everything is cleared up, and where the problems are that super() is actually solving. In a strictly single-inheritance world, the old style of calling the base class methods works fine. In multiple inheritance, you can't actually predict what class you'll call.
Many adult engineers used to be child engineers, working in Lego and other building toys. Many adult engineers have not abandoned their love of those toys. A few of those engineers combine their childhood and adult passions to build computing devices out of toys:
Star Simpson wore a lighted circuit board to Logan airport, carried Play-Doh, and didn't answer questions about them. As a result, police arrested her at machine-gun-point, and she is out on $750 bail. She is charged with possession of a hoax device.
As it happens, I've met Star Simpson. She was one of the hosts at an Instructables event at MIT in March. Here she is in her natural habitat, the MIT Electronics Research Society:
She seemed intelligent and happy and naive, a description not contradicted by any of the news reports of the event at Logan. And she's definitely a geek. To many people, the room in the photo would be a dangerous and sinister place. To Simpson and her friends, it is a garden of creativity.
This is not a case of someone trying to perpetrate a hoax. This is a geek out of touch with the way the rest of society perceives her and her handiwork. An MIT student with a circuit board attached to her clothing and a fidgeting toy in her hand? Hardly out of the ordinary. The most unusual thing in that sentence is "her". But showing up like that at Logan, and then acting spacey when questioned about it is just dumb.
Of course that doesn't keep some people from judging her differently. Lots of people seem willing to call her circuit board a "fake bomb" or a hoax. Apparently being mistaken isn't an option. If someone thinks you're carrying a bomb, but it turns out not to be a bomb, then it's a hoax.
To me, this is less a story about terrorism than it is about spectrum kids (nerds, Aspergers, Autism, etc) not understanding how they don't fit in.
Everything I know about this leads me to believe that Star was not trying to scare anyone. Let's hope it all ends equitably.
Brian Dettmer takes old books, and cuts away parts of them to reveal a 3D landscape of words and images. It's like an instantaneous visual summary of the book. They are beautiful and evocative. There are links to the galleries that display them, but no clue what it would cost to acquire one of these.
When cubicle workers vacate a cube, they often leave behind trivial office supplies in the desk drawers: push pins, post-its, undesirable mugs, and so on. I'm an inveterate explorer of my surroundings, so I've seen plenty of this sort of detritus. Once though, in a cubicle farm long ago, I found a real treasure.
It was a ruler, printed on flexible translucent plastic, with very fine gradations. The design was clean and modern, both utilitarian and beautiful. I kept the ruler, and when the time came at Tabblo to get the precise details right about our printed products, it was invaluable. By now, it was scratched and dinged, but it held up to the years of neglect and abuse, and still was the best ruler I owned.
As much as I liked the ruler, I never much thought about where it came from. But when our graphic designer showed up at the office, and pulled out an identical though much newer ruler, I knew that I was not the only one who thought highly of them.
The ruler is a Schaedler Precision Rule, and they are still made. They are expensive, but worth it.
And if their status in the graphic designers' world is in doubt, know that in some eyes, they have risen from humble tool to the center of attention: How to: Turn a Schaedler Precision Rule into a bracelet (scroll to near the end).
A recent thread on Django Users, Visual recognition of Django website is about the need for a favicon for the Django web site. The thread follows a typical path, starting with a reasonable request, followed by a smattering of debate about whether it is in fact a good idea. A few people posted proposed favicon files based on the d in the Django logo (including one with a Makefile!)
Making a good 16×16 pixel icon is tough. Here's how I made one that avoids some of the smearing. I started with the Django logo, took the Dj (in honor of DJ Ango!) from it, and placed them in a square. The color is a very dark green that would look black at such small sizes, so I lightened it to a green borrowed from one of the Django badges:
If I simply scale this image down to 16×16, it looks like this:
The letters here are blurred, and we can do better. To see why the letters are blurred, go back to the full-size square, and turn on the grid, setting it to one-sixteenth the width of the square. The grid now represents the 16×16 pixels of the final actual-size icon:
Most of the edges of the letters don't fall neatly onto the pixels defined by the grid. As a result, when the image is scaled down, the edges are blurred. To prevent this, we have to move the letters' edges so that they line up better with the grid. This is what font renderers do for you, and a great deal of work has gone into type hinting that can automatically adjust the curves of letters to align with whatever pixel grid they are being rendered onto.
To improve the icon, I did this by hand. Using the grid as a guide, I used the lasso tool to select parts of letters and move them until they fit better onto the grid:
This changed all sorts of details of the letters, including the height, the thickness of the stems, and so on, but kept the overall feel of the logo. (here it is if you want it.) Generally, I haven't worried too much about the curvy parts: remember we're going to be scaling down to 16×16 at the end anyway, so all the mistakes will be fuzzed away. I added the white dots in the corner pixels to get a slight rounded look to the corners when they get rendered down. The final icon:
The two favicons side-by-side, old and new:
Is it better? I think so.
I had need to read Gimp gradient .ggr files today, so I hacked together a Python module to do it. There was enough niggling detail that I think this may save someone else some work: I give you ggr.py.
Also, I found cpt-city, J. J. Green's collection of gradients collected from around the web and presented in a variety of file formats, including .ggr.
Devizen has an essay he (she? there's no author's name there) titled Programming Can Ruin Your Life, but I think it should be called An Owner's Guide To Programmers, and should be required reading for significant others of people engaged in writing software. Some choice bits:
He does a good job breezily covering the pitfalls of extending a digital mindset to the analog world. The lack of undo is particularly unfortunate.
Antonio claims that blog readers don't care about archives: the last 10 posts are where all of the interest is. Generally, this is true, but when I find a new blog, and those latest posts seem really interesting, I'll take a quick scan through the archives to get an idea of what else I can expect. Every once in a while, that scan through the archives turns into an hour-long exploration, similar to what happens to me in book stores when time permits: browsing turns to reading turns to learning.
Connelly Barnes has one of those blogs. He posts sporadically, but each post is a meaty nugget of Python in academia. For example, I wish I could understand the code behind the real-time hair animation, and I'd never heard of the Burrows-Wheeler transform before (it's a miraculously reversible transform that rearranges data to move repeated bytes closer together to get better compressibility).
Discussion of what size external disk drive to buy (I'm thinking of a 500Gb model to put an end to data squeeze for a good long time) lead to a question about the meaning of the SI prefix tera-. Wikipedia's SI prefix page explains that the prefixes started from Greek roots for large things, then switched over to numbers as sources:
The official Bureau International de Poids et Mesures page about the prefixes is interesting because of its links to the actual resolutions that created the prefixes. Unlike ISO, BIPM manages to make their official output refreshingly brief: their resolutions are only a few paragraphs at most.
One aspect of this I don't understand: why the BIPM approves new prefixes in such small increments. Peta- and exa- appeared in 1975, and zetta- and yotta- in 1991. Why dole them out so slowly? Of course, there are proposals, including one that goes all the way to 1063 (luma-).
The scientists take exception to the computer geeks using their decimal prefixes for binary amounts. 220 is not 106, and the inaccuracy gets quite large by the time you are discussing exabytes of data. There is a system of binary prefixes (gibibytes, anyone?), but they have not caught on yet, and sound silly, so I don't think they ever will.
Semapedia is one of those cool things you can build by assembling existing technology in new ways: URLs from Wikipedia are turned into 2D barcodes, which are printed on stickers and then affixed to physical objects. This links the real world to the Wikipedia articles that discuss them. By scanning the barcode with your cell phone, you can read about a place or thing on the spot. Very clever.
But like many of these sorts of "wouldn't it be cool" kinds of tech projects, this one is kind of dumb. First of all, what are the chances of getting enough of the physical world barcoded for this to be interesting? And if we did, what would it look like to have these stickers all over everything?
And something about this smacks of people not understanding the real world. One "thing" in the world does not correspond to one article on Wikipedia. For example, here's a barcoded book with a link to its author, William Gibson. But why not link to the title, Spook Country? Or science fiction or cyberpunk? Or even book or paper? (This is not so far-fetched: a recent barcode at Semapedia is to the Dutch article Koffie about coffee: where did that barcode go?).
The real world is too richly faceted to be able to plaster it with 3×4-inch stickers to discrete articles on Wikipedia. Semapedia a cute hack, but hardly a realistic solution to an actual problem.
I've been on vacation for the last week or 10 days, at the beach:
I swam a lot (but safely), spent a lot of time in the sun, played with my kids, fiddled with Mandelbrot code, and just generally relaxed. I also bought a surfboard (new hobby or midlife crisis? you decide!) which I do not know how to use yet. It was a great week on Cape Cod.
Now we are back, and it is time to dig into fall: work, school, leaves, snow, etc.