Recipe: Halloween Surprise Refried Beans

A surprisingly good post-Halloween variation on my regular refried beans.

Make refried beans with black beans, using the following modifications to give it a rich mole flavor.

  1. Add 0.5 tsp cinnamon when adding the oregano to the onion and cumin.
  2. Chop 3 fun-sized chocolate candy bars in the food processor along with the rest of the refried beans.

Serve in soft-shelled tacos or as burritos. This is rich enough that salsa and cheese shouldn’t be necessary, but fresh lettuce and tomatoes are a nice addition. For chocolate, I used two Nestle Crunch bars and one Milky Way.

Dennis Richie, RIP

Dennis Richie was one of the most important computer pioneers. His language, C, is at the foundation of all operating systems in common use today. If you want some code to run on every smartphone, every desktop, and every server, you write it in C. If you got rid of all the C compilers, Apple couldn’t build Mac OS or iOS, Microsoft couldn’t build Windows, and Google couldn’t build Android or their servers. It is no exaggeration to say that all the most important software in the world is written in C.

Apple aims for the low end

John Gruber writes:

Another new pattern: the expansion of the iPhone product line down to free-with-a-contract pricing. Apple did this not by creating a new “low-end” model, but by keeping the 3GS around for another year. This move seems so obvious that I’m disappointed in myself for not having predicted it. Operations wise, the 3GS doesn’t just use cheaper components, but because Apple has been making it for two and a half years, they’ve surely streamlined the manufacturing process.

The most important cost savings is the value of simply keeping the factory doors open. For technology components manufacturers, costs break down into two categories: fixed and operational. The fixed costs can be huge. A new chip fab (factory) costs over a billion dollars. Companies like Intel spend the first several years just paying for the R&D and the factory. An Intel processor doesn’t actually start making them any money until they have a newer high-end chip, and the “obsolete” chip gets sold at discount prices. Without the fixed costs, the discount prices have a healthy profit margin.

Video game consoles are built around this model. They keep roughly the same price and the same specs over their lifetime. For the first few years, consoles are a huge bargain: the manufacturers actually loose money on them. Near the end of their lifetime, the components are laughably obsolete, but the price is justified by the huge library of video games they run. This drives their design. Hard disks were added only reluctantly, since their platters don’t get cheaper. Chips are good. And custom anything (processors, controllers, cases) is the best, as R&D is a pure front-end cost which keeps the console distinctive in later years.

Apple knows streamlined manufacturing, and it shows in the iPhone 4′s design. Using an antenna and two panes of glass for the case minimizes materials costs. As does a small battery. Small and thin, few buttons: it’s not just for looks, it’s to maximize the factory’s lifetime. The iPhone 4 was designed to be a third-world discount product. But for now, it’s cheaper to keep making the 3GS in an old factory than to put old components in an iPhone 4.

Steve Jobs: the Perfectionist who Shipped

In thinking back on Steve Jobs, I remember an insight I had years ago, while he was at NeXT. Most people in the computer industry are either perfectionists or pragmatists. The perfectionists do well in academia, where it doesn’t matter that their big ideas take years to turn into practical products (think Donald Knuth.) The pragmatists do well in the private sector, where a steady stream of adequate hacks trump elegant designs. Think Microsoft under Bill Gates: they had a reputation for shipping a laughable 1.0, followed by a nearly respectable 2.0, and then kill the competition with 3.0. Compare the Mozilla Foundation, which disappeared and left MS Internet Explorer with a monopoly while they perfected their browser. Or think of well-designed but expensive SCSI disks, which got eaten alive by the inconvenient, cost-cutting ATA format. Or BSD vs. Linux. (Or both vs. GNU Herd, which never shipped.) And on and on.

Of all the paradoxes of Steve Jobs, this is perhaps the most important. He was a perfectionist who didn’t miss deadlines.

Letter to my grandchildren

Here is my letter to my grandchildren which I wrote this summer. I’ve scrambled it to discourage you, dear reader, from reading it. So why am I linking to it? So the Internet Archive and other spiders will find it and archive it permanently. That way, once leppik.net is long gone, my descendants will simply need to know that it was there, and that the URL was https://www.leppik.net/david/7gen/1_OtherGrandchildren.html in 2012. (I hope I’ll be able to entice the spider to archive it by 2012.)

IQ and genetics

Just watched an interesting lecture on IQ and genomics which makes a number of interesting claims. First, that IQ is as inheritable as height, which is to say that genes are 70% responsible. Second, that it appears to be the result of many different genes, each of which contributes a little bit. (With height, they’ve found 200 such genes.) And third, that although no IQ genes have been discovered, we’ll likely have discovered many of them within the next decade.

This raises many interesting questions, but from an evolutionary standpoint, I see one big one. If IQ is mostly genetic, and it is a major influence in life success (both of which are claimed), why isn’t everyone high-IQ? Is there an evolutionary advantage to a lower IQ (e.g. lower caloric requirements, thus more likely to survive a famine; or lower birthrate?)

This also raises some interesting quandaries. It’s standard practice to do genetic testing on fetuses, to screen for particularly nasty disorders. It’s possible to sequence the entire fetal genome. By the time my kids are grown up, there’s a good chance they’ll be able to do prenatal IQ testing which won’t be as accurate as a real IQ test, but will have decent predictive power.

Re-encoding media files

At work, we’re updating old audio files (uncompressed WAV format) into more modern audio formats. It takes about a second per recording, and we have several million recordings. This means our conversion process will take over a month. These files are big, and the output is on a distributed filesystem: they get copied to many of our servers. So we don’t want to speed the process up too much if it will strain our critical servers.

This gives me some insight into YouTube’s reluctance to embrace additional media formats, even Google’s pet project WebM. Like us, they are sensitive to hardware constraints. Even with virtually unlimited money and resources, it takes time to move gigabytes from one disk to another. Google gets around this by splitting data across many servers, so rather than touching a gigabyte on a single disk you move a few megabytes each across several servers. But when all their data needs to be updated, then every server needs to move gigabytes. So Google has no advantage over an average Joe trying to restore his hard disk from backup. Even if Google could build a new datacenter just for video processing, they’d still have to move all the data out of the existing datacenters into the new one and back.

My guess is that YouTube is using its existing video servers to create WebM versions of its videos, while continuing to serve those videos to users. But it will take months, if not years, to get to a point where they can serve WebM content to users.

RIP Michael S. Hart, E-books creator

Michael Hart is not exactly a celebrity. But as founder of Project Gutenberg, he’s an inspiration. He had a simple idea, digitizing and disseminating public-domain books. Perhaps it was inevitable that paper books would end up digitized, just as hand-copied ancient manuscripts were made into printed books. But he was the first. Often times the march of progress seems inevitable, especially in retrospect; just as often the appearance is misleading. When it comes to books online, the world doesn’t begin and end with Google and Amazon. Typically their source is Project Gutenberg, and it can be your source too. Thanks to Michael Hart.

Tax rates

I’d been wondering who those 46% who don’t pay federal income taxes are. Here’s a break-down. In short, 23% are at or below the poverty line, 7% get deductions related to cost-of-living (e.g. earned income tax credit, child credit) that push their taxable income below the line, 10% are retired. That leaves 6% in the “other” category.

I find it mind boggling that, here in the USA, 30% of people are struggling to make ends meet.

When AJAX is too slow

Back in the day, web pages were just web pages. What you see is (more or less) what you got. These days, we have web applications where there’s a lot of back-and-forth communication between the web browser and the web server. In essence, where you used to load a new page to get more data, your web browser just updates a portion of the page you’re already on. The new model is called AJAX.

That works great when you’re going to be interacting with a web application for a long time. But if you want to load the page quickly and then jump to a different page, AJAX can be a bad idea. I’ve got one of those situations at work right now. It’s a to-do list, where people choose a task to work on. Someone will eventually need to do all the tasks, but when the list is big they’ll either just click on the first one (to hurry) or look more carefully and do triage.

My first attempt was a single web page with all the tasks in an HTML table. When the table is moderately large (over 30 tasks), it took over a second to load. After a day of optimization, I got that down to 0.6 to 0.7 seconds. Not the 0.1 seconds that Google recommends, but reasonable. If it takes more than a second the user’s mind will wander while waiting for it.

Then I AJAXified it. Converted the simple HTML table to a YUI Datatable. My 0.6 seconds shot up to 1.7 seconds. Why? Instead of loading one web page and rendering it, it now (1) loads the web page, (2) loads the JavaScript program that displays the datatable, (3) waits for the web page to finish rendering before running that program, (4) the program calls the web server to get the column descriptions, and then (4) the program calls the web server to get the data. The column data (which takes 0.2 seconds to generate) is being generated in triplicate. The to-do tasks themselves take half a second (0.13 seconds each), but–and this is the real killer– we don’t even start on that until everything else is done.

So how do we make this quicker? We need to move as much as possible back into the original page: un-AJAXify it. In my case, that’s not easy. Behind the scenes, the web page is constructed with XHTML and then converted into HTML before being sent to the web browser. I’ve got a lot of helper code that assumes we’re doing XHTML, so that’s not negotiable. XHTML is a lot like HTML, except that we can’t just dump a block of JavaScript into it. Nor can we send it as XHTML and pretend it’s HTML. The web browser, upon seeing that, assumes we don’t know what we’re doing and tries to “fix” it in ways that break things. So to totally un-AJAXify it, I’ll need to go back to writing a simple (X)HTML table, and then write some JavaScript to convert that into the YUI DataTable.

Another option is to take the to-do list payload and treat it as a JavaScript script, so it gets loaded simultaneously with the other scripts and images on the page. This is what I call Poor-Man’s AJAX, because I used that trick back in the days when only Internet Explorer supported AJAX. It’s not quite as fast in my case as having the data in the page, but it should still be fairly fast, and it’s easier to program.

The moral of the story? Sometimes the new, fast way of doing things can slow you down, so it’s good to have some old-fashioned tricks up your sleeves. Though, this being computers, old-fashioned means circa 2004 or so. (When you’re really in trouble, that’s when you reach back to your circa-1980 performance tricks. But that’s a story for another day.)