03.28.08
Posted in programmer productivity at 9:35 am by ducky
I finally got my hands on the dead-trees (i.e. uncorrupted) version of the Klahr/Dunbar article that I posted about earlier, and it didn’t say anywhere how long people in the hypothesizing group spent on coming up with hypotheses. However, I was able to track down David Klahr, and emailed to ask him how long they hypothesizing group spent hypothesizing. He graciously and quickly replied that it was only a few minutes. So if we make a wild guess that “a few” works out to an average of about four minutes, then the hypothesizing group took an average of about 10.2 minutes, while the non-hypothesizing group took an average of 19.4 minutes — so the hypothesizing group is still twice as fast as the non-hypothesizing group.
Note that the experimental conditions between the two groups were not exactly the same: the non-hypothesizing (slow) group all had at least one programming course, and pushed the buttons on the toy’s controller themselves. In the hypothesizing (fast) group, only half of them had prior programming experience. If those make a difference, I would have guessed that both of those differences would make the hypothesizing group slower than the non-hypothesizing group, but instead that group was twice as fast.
Wow.
Permalink
03.22.08
Posted in Canadian life, Married life, Random thoughts at 9:26 am by ducky
My beloved husband has been wanting to try snowboarding for a while. When I realized late on Thursday that Good Friday was a statutory holiday, we made very quick plans to go to Grouse Mountain, a local ski area. Jim and I talked by phone briefly, and later in the day, when I was in the midst of something, got a message from him, asking me to to confirm that I wanted him to go ahead and buy tickets etc. Sure, sure, go ahead.
Um. I didn’t read the email carefully. He asked if he should buy snowboard rental and lessons for both of us. And I said yes. Oooooops.
I took one snowboarding lesson seventeen years ago that was a total disaster. I was up at Tahoe for a M-F trip, and took the lesson on Monday. I was so sore that I couldn’t ski on Tuesday. Or Wednesday. Or Thursday. Friday, I gave up and came home.
I was thus quite nervous about another lesson, especially since I am seventeen years older now. However, the instructor was better, and I am seventeen years wiser. I didn’t try to push it, and took frequent rest breaks. The snow was also nice and soft yesterday — there had been about 11 cm of new snow in the past 24 hours, and so I fell into nice fluffy stuff and not onto ice. (A ski patrol guy we sat next to at lunch told us that he was not allowed to ever say that the snow conditions were “icy”. He was required to say that the snow was “hard”.)
Looking at the lesson from a distance, you wouldn’t think it would be so strenuous. After all, I would simply slide down a little hill, sit down, rest, take off my board, stand up, walk up the hill, sit down, rest, put on my board, stand up, repeat. So it would be sort of like walking up a hill carrying a relatively light board, sitting down and resting every five minutes. Not so hard, right?
Wellllll…
- While you are sliding down, you have to have your knees bent and springy. This takes some exertion.
- There are two ways to go down: facing down the hill and facing up the hill. In both cases, you have to lean into the uphill edge. I found going down while facing up the hill enormously physically strenuous for my feet. I found pulling my toes up (to dig in my heels) much easier than pushing them down. I could pull up my toes by pulling up my whole foot. It didn’t seem to be adequate to push my foot (e.g. the balls of my feet) down with my calf; it seemed I also needed to push with my toes e.g. tense the muscles in my arch. I happen to have a very very narrow foot with a very high arch, so it felt like I didn’t have a lot of muscle mass in my arch to point my toes down. It was actually painful to go down the hill pushing with my toes. I suspect that I was doing something wrong.
- Standing up on the board from a sitting position when facing down the mountain, is really difficult, and takes quite an exertion of strength. Your feet and board are way in front of your center of gravity. You have to get your center of gravity above the board — while still keeping pressure on the uphill edge of the board. What I learned to do was to grab the downhill edge with my right hand and pulling while pushing myself up with my left hand. Jim’s physical geometry and flexibility are such that he was not able to grab the downhill edge of the board like I could.
- While standing up, if you let the pressure off of the back edge of the board, the board will start to slide. Having the board slide while you are shifting weight is a really easy way to cause you to immediately re-enter a sitting position. Thus, the number of standing-ups probably averaged four or five per trip down.
Note: It is much easier to stand up if you are facing uphill with your board downhill from you because you can get your center of gravity several feet off the ground just by kneeling. However, then you are facing up the mountain, which is difficult. Once I learn how to do turns reliably (shifting from looking uphill to looking downhill), my life will be much better.
Jim wants to do three or four more snowboarding lessons. Ulp. I guess the exercise will be good for me.
Permalink
03.17.08
Posted in Eclipse, robobait at 2:34 pm by ducky
I’ve got two cool tricks for you today. Control-O opens up a “quick” view of the Outline View. Instead of looking in a separate pane, you can do it right inline. Furthermore, it has incremental search built in, so you can type a few letters to find methods that start with those letters. If you type in the normal Outline View, it will find the first method that starts with those letters but will continue to show you all the methods.
In the Quick Outline View, it will show only the methods that start with what you typed, so if you type “set”, the quick outline view will only show you setFoo(), setBar(), etc.
But wait, it gets cooler: you can use wildcards in the Quick Outline View and you can’t in the Outline View. For example, in the Quick Outline View, you can type “*Foo” to find getFoo(), setFoo(), etc.
But wait! It gets even cooler! If you have the Quick Outline View up and type control-O again, then it will show you the inherited methods as well as the ones in this class. Totally sweet.
Permalink
03.14.08
Posted in Eclipse, robobait at 9:35 pm by ducky
Several of the users in my study have complained about “tab spam” in Eclipse — having so many files open (at one tab per file) that they can’t keep track of them all.
If you want to limit the number of tabs in Eclipse that you have open at any one time, you can do this:
- go to Window->Preferences->General->Editors,
- put a check in the Close Editors automatically
- and select the number of editors (tabs) that you want open at once.
If you don’t want a tab to be reused, you can “pin” it. (On my toolbar, the “pin this” icon is at the far right, just to the right of the forward arrow, and has a little white-window-with-blue-taskbar underneath a green pushpin.)
This still cycles through editors, eliminating the least-recently-used, but at least you won’t get tab spam.
If you reuse editors, it is handy to use the Auto-Pin Editor Tabs Tweaklet. With that tweaklet installed, Eclipse will not reuse an editor (i.e. a tab) if the file within is dirty. (This will save you a bunch of annoying messages about needing to save files.) If all of the tabs are pinned, it will open a new one.
Permalink
03.13.08
Posted in Eclipse, robobait at 4:27 pm by ducky
One of my user study subjects pulled out a keyboard shortcut that I had never seen before: control-shift-u.
I didn’t get to talk to him about it much, but it pops up a menu with Identifier, Implementing Methods, and Throwing Exception options.
The Identifier seems to find occurrences of that Java element in this file. I guess you could do almost the same thing if you do a FileSearch for a element’s name in one particular file, but that would be a lot more work.
For the Implementing Methods selection, it appears to tell you which methods in this file override/implement methods in the type you had selected. (Note that the type needs to be something right after the keywords “extends” or “implements”. If not, you will get an error message “Cannot search for current selection. Please select a type behind ‘implements’ or ‘extends’.”
You can select an exception (e.g. IOException), press control-shift-u, and select Throwing Exception in order to see which lines of source cause that exception to be thrown. Maybe you knew that read() threw an IOException, but if you didn’t realize that skip() also throws an IOException; this would show you not just that skip() was what was throwing the exception, but the exact line where it was doing so.
Permalink
03.12.08
Posted in Eclipse, programmer productivity, robobait at 10:38 pm by ducky
Cool!
I am doing a observational study of people using Eclipse, and I saw one of the users doing something that looked really useful.
If you hover over a Java element (type, method, or field), then you see the Javadocs for that element. Yeah, old news. You do that seventy times per day already.
If you shift-hover over a Java element, then it shows you the method’s source intead of the Javadocs!
This is a great way to get a peek down a navigation path before commiting to it.
Permalink
03.11.08
Posted in Random thoughts at 10:52 pm by ducky
A post by Scott Rosenberg took me to a NY Times article that included this nugget:
Another ingenious bit of research, conducted in Germany, demonstrated that within a brief time frame the brain can shift events forward or backward. Subjects were asked to play a video game that involved steering airplanes, but the joystick was programmed to react only after a brief delay. After playing a while, the players stopped being aware of the time lag. But when the scientists eliminated the delay, the subjects suddenly felt as though they were staring into the future. It was as though the airplanes were moving on their own before the subjects had directed them to do so.
I have heard people be spooked about dreams where it would make logical sense for something to happen, and then that event would happen in real life (waking them). For example, someone saying, “answer the phone” in the dream, followed by the real-life phone ringing. I have wondered for a long time about whether the brain shuffles the perception of time in order for the ringing phone to make more sense; the joystick experiment gives my theory some more plausibility.
When I was in college, two guys I knew messed with people’s perception of time. They took a sequence of photos something like this:
- Dave at the top of a well-known 12-story dorm with a patio on the roof.
- Dave standing next to the railing and waving at the camera.
- Dave with one leg over the railing.
- Dave standing on the roof but on the opposite side of the railing, holding on to the railing.
- Closer-in shot of Dave with his hands off the railing (and his feet not visible).
- Closer-in shot of the railing with no Dave.
- Shot taken from above of Dave sprawled on the sidewalk below.
A perfectly healthy-looking Dave would show this sequence to people, who would be completely flabbergasted. (The way Dave told the story, it seemed like a little TILT light would flash over their heads.) How could he possibly be hale after a twelve-story fall? And the photos proved that he fell! Some people quickly came to the conclusion that he must have a twin who committed suicide, and refused to budge from that conclusion.
In fact, the truth was much simpler. After shot #5, Dave climbed back over the railing and went downstairs. His buddy took shot #6 of the bare railing, and then waited for Dave to get down to the sidewalk. When Dave got downstairs, he sprawled on the sidewalk and his buddy took shot #7.
People really wanted to stitch the images together into a continuous story, but anything could happen in between the photos. All you knew was what happened at those discrete points in time when the photos were taken; everything in between was up for grabs.
This relates to how I understand wave-particle duality. (Stick with me for a second!) In the classic wave-particle duality experiment, you have two slits in a wall, a particle (e.g. photon) gun on one side of the wall, and a sensor on the other side of the wall (e.g. film). You send the particles through the slits one at a time, as slowly as you like, and you will get a diffraction pattern on the film. How is this possible? What are the particles interfering with — you’re only sending the particles through one at a time!
Well, where do you know what is happening with the particle? Where there is some sort of measurement event — at the gun and at the film. What the particle does in between is its own business. Just as you can’t see Dave going down the stairs from the photos, you can’t see what the particle does in between the gun and the film.
Furthermore, the only entropic events are at the gun and at the film. Entropy is important because it is what determines the direction of time.
My mental model of what happens in the two-slit experiment is that the particle is free to move backwards and forwards in time in between the gun and the film and so it interferes with itself. I also imagine the particle as being a three-dimensional string in four-dimensional space-time; the string is stapled at the gun and at the film, but in between it is loose to wiggle around as much as it feels like. (I have no idea how this relates to how “real” physicists think of it, but it is a mental model that makes me happy.)
Okay, now back to the phone ringing in the dream. We sense that A happened before B because our brain essentially “tags” entropic events as happening “before” and “after”. But I suspect that there is nothing that forces our brain to tell us the truth. Dave’s buddy might have taken picture #7 first, then #6, then #2-5, then #1, but when Dave presented them in the order 1-7, he caused our brain to come to a conclusion that was entirely false. Similarly, I bet our brains can do a little bit of rearranging when the phone rings.
And just like I couldn’t tell if Dave presented the photos out of order, I will never be able to tell if my brain presents impressions of the world out of order.
P.S. Props to the late Larry Rubin, who explained to me the idea of photons interfering with themselves.
P.P.S. Sorry this post was so long; I didn’t have time to make it shorter.
Permalink
Posted in Hacking, robobait at 9:24 am by ducky
To turn off the sound on a ThinkPad running Windows XP:
Start->
Control Panel->
Adjust the system volume ->
In the Device volume area in the middle of the Volume tab, click on Advanced. I know, I know, it looks like you are adjusting speaker volume, but go ahead and do it.
If the microphone doesn’t show up as one of the devices, select the menu item Options->Properties and put a check in the Microphone box.
In the microphone sub-panel, put a check in the Mute box.
(I am soooo not a Windows person…)
Permalink
