Donnie’s Blog

Over a year ago I got a really nice set of kitchen knives from the Misono UX10 line. They are really nice; I really enjoy using them for cooking. (I even take them on trips when I expect to be cooking! I use this set of knife-safes to transport them safely.) However, over time they have gotten noticeably duller, so it was about time to get them sharpened. I could have taken them to someone to get them sharpened, but I decided it would be more fun to learn to sharpen them myself, so I went ahead and bought a couple of water stones.

There are a variety of different water stones available, and I really didn’t know what to pick. Here is one website that has a selection of water stones. The Chosera stones looked really appealing, but the ones I wanted were out of stock, so I went ahead with the Shapton professional line of water stones. I chose a 1000-grit stone and a 5000-grit stone, which hopefully will be good to start with.

I also need to learn the proper technique for sharpening my knives, which is complicated slightly by the fact that Misono knives have more of a bevel on one side of the knife than on the other. This aids in making very accurate cuts. I enjoyed this feature of the knife, so I want to preserve that in my sharpening efforts; some people restore this to a 50/50 bevel, but that’s just not for me. Here is one website that describes how to sharpen knives; I will have to look for more when I get my water stones.

I was pleased to note that South has recently been recommended as a good solution to the whole problem of database schema migration when using Django. I have been using South in csman for over a month now, and it has just been great. I still back up the database before applying a schema-migration to the production system (no sense in being a complete idiot), but so far every time I’ve had to make a schema change, the process has been completely flawless.

So, I can definitely recommend South too!

In general, it’s still very wise to try to change schemas as infrequently as possible, so I tend to batch up my changes, but South has almost completely removed my worries about making schema changes in my Django projects. It’s a great tool.

Using Django for csman has mostly been a positive experience, although there have been a few wrinkles along the way. I just ran into another one today, which is quite frustrating — one of my pages takes about ten seconds to render, and nobody wants to wait ten seconds! Fortunately it’s for the teachers and not the students; if it were for the students, there would be no end of whining!

This page includes a LOT of database queries, almost to the point where I should be embarrassed, except for the fact that I hacked this thing together as quickly as possible, so actually I’m proud that it has as many features as it has. But for 130 students and around 15 assignments, the server-side code issues around 2000 queries, and you don’t need to be a genius to know that this just won’t be very fast.

But surprisingly enough, only about half the time is spent in database land; the rest of the time is spent rendering the Django template. I was quite surprised by this! I thought it would be much faster than that, but evidently not. There are three nested loops in the template, iterating over a large amount of data, so in retrospect it’s no surprise, but an hour ago I was sure that I needed to optimize the database interactions, not the template rendering. Now I see that the database code is only half of the problem.

All I did to find this was to add a couple of print statements around my view code to see how much time was actually spent in the database queries. I’m glad I did; I would have been completely befuddled, otherwise. It just goes to prove that old bit of software engineering wisdom, that if you try to optimize a system before you’ve actually profiled it, you probably won’t fix the real bottleneck.

I think I can fix this issue by creating a custom template-tag that will move some of the rendering into Python code, instead of being run in the template engine. The more I can incorporate into Python, the better off I’ll probably be. This may also help with the database side of things, because if I have clever template tags, then I can do less preparation with the data, and therefore fetch larger amounts of data from the back-end in one shot.

I just wrote up a new programming note about how to do syntax-highlighted diff output using Pygments and Python’s difflib library, in a Django website. It’s available here.

I implemented this feature for csman, a homework submission and grading system I have been implementing for the last couple of months, to use with the CS1, CS4, and CS11 classes that Mike Vanier and I teach. All of these classes have a similar homework-submission model, much like the model in real software projects: you write the code, and if it’s not good enough, you have to fix it.

Of course, grading redos is always a little annoying, so if you have a tool that lets you view a diff of the old submission and the new submission, it becomes very simple to see if the student actually fixed everything you told them to fix. (Sometimes they don’t. It’s very annoying when this happens.)

Anyway, it’s a cool little feature, to be able to see syntax-highlighted diff output on csman, but it definitely still needs a lot of work. The main issue is that frequently the files are too wide to display side-by-side, unless you happen to have a nice large monitor like I do. So, the problem really requires the effective use of scrollbars, both horizontal scrollbars to allow the diff-output to be visible in a smaller window, and also vertical scrollbars since otherwise those horizontal scrollbars are going to be waaayy at the bottom of your web page.

So, I have some work to do on that problem, but for now I’ll stick with what I have. It does the job, and one day when I learn more client-side JavaScript, maybe I’ll fix that kind of stuff up to be more snazzy.

Since I have a special guest coming into town tomorrow, I thought I should pull out all the stops and make some gourmet sandwich fodder, for a picnic on the beach. I settled on tri-tip steak, mainly because I’ve never tried cooking it before, but also because I have some good friends who serve tri-tip at their annual barbecue, and it always comes out good.

Read the rest of this entry »

Since I finally started playing the piano again after nearly two decades of not touching the thing, I decided that it was high time to finally get the thing tuned. (It was really out of tune…) Fortunately, the guy who used to tune our piano is still in business, so we called him up and scheduled an appointment. Tonight was the night, and right on time the doorbell rang.

Read the rest of this entry »

Today the Caltech CS department is getting rid of some old (very old) computer and electrical equipment, and it’s always fun and entertaining to go over it and see if anything interesting is being tossed out. Sometimes you find stuff that’s really useful for a personal project (say, a couple capacitors rated at 50KV for that Tesla Coil you are building), but sometimes you just find something awesome. That happened for me today, because I found this:

This happens to be a 64-processor parallel computer, called the MOSAIC, that I programmed for CS20 during the third term of my sophomore year. It was a crazy little computer. The processors were connected up into a 2D mesh, and they could send messages left, right, up, or down. They only had about 64KB of memory per node, if I remember correctly, so you had to be pretty careful with your programming.

Communication and parallel computation were even crazier, because the communication channels between the processors were slack 1. That means you could send one message, and then the next send would block until the receiving processor actually read the message off of the channel. And the processors weren’t very bright, so it was very easy to have your program lock up the entire MOSAIC if you didn’t route your messages properly.

In CS20, the project was to simulate all of the components of a processor on this parallel computer. So, a few processors would be assigned to simulating ALUs, a few processors would handle stack operations, one would handle instruction decoding, a few would simulate heap memory, and so forth. It was such a fun project to work on, unlike anything I had ever done before, and I still remember it with great fondness to this day. Peter Hofstee was the teacher for CS20 that year, and I’m glad he came up with that crazy project.

I think I’m going to have to frame one of those boards and put it up on the wall!

A long time ago I was watching an episode of Good Eats all about squash (or “pumpkin” for my friends down under), and Alton Brown made these very yummy looking butternut squash dumplings. Since it’s the season for squash and we have a bunch of them floating around, I decided to give this dumpling recipe a try. Instead of using butternut squash I decided to use acorn squash, since we have a few extra acorn squash that hadn’t been spoken for yet.

Read the rest of this entry »

Lately I have been tinkering with a simple little 3D graphics program in my spare time. To support my various graphics and math projects I have put together a simple C++ math library including matrices, vectors, and the like. My matrices are stored in row-major order, like most matrices in C/C++ programs, but OpenGL uses column-major order. “Simple,” I think, “I just need to transpose my orientation matrices before passing them to OpenGL!”

But it just wouldn’t work. See if you can figure out why:

  template<class T, int dim> class SquareMatrix {
    ...
    /** Transpose the matrix. **/
    void transpose() {
      for (int r = 0; r < dim; r++) {
        for (int c = 0; c < dim; c++) {
          // Diagonal elements don't need transposing!
          if (r == c) continue;

          T tmp = getElem(r, c);
          setElem(r, c, getElem(c, r));
          setElem(c, r, tmp);
        }
      }
    }
    ...
  };

Guess what I saw at the Sydney Airport:

That’s the new Airbus A380! It’s one big plane! It can seat more than 500 people. Fully loaded it takes ~9K feet to get off the runway - nearly two miles, which is a little disturbing because the LAX airport runways are between 10K and 12K feet long. Not a lot of leeway there!

Well, everybody who knows me knows I’m already afraid of flying, so it’s not a big surprise that this thing scares me. But it is still really cool to finally see one up close!