Thursday, August 28, 2008

Someone else agrees with me: learning styles don't exist!

So I've often said in an off-the-cuff way that I don't really believe in learning styles. More concretely, I've often said in my Spanish classes that I don't believe in visual language learners, because, well, language is auditory. I particularly hate diagrams like this, which are supposed to cater to visual language learners:

The reason I so hate that diagram is that it tries to use a visual clue to organize supposedly arbitrary information, disguising what is in fact a very simple auditory pattern (a pattern called dipthongization, which in fact exists in English as well as Spanish).

Anyway, today I noticed in a post on Tom Hoffman's blog that he linked to a video called Learning Styles Don't Exist. It's a little simplistic, but entertaining and, I think, right.

So, has anyone heard of this guy before? Is he right? Does anyone outside of the world of education take learning styles seriously? Is there any research to support them?

Or is the reason that the "different learning styles" line is so common in educational circles really that many teachers are (or are imagined to be) simply uncreative, and it's easier to tell them "cater to different learning styles" than to say, "be less boring", or "try out something new"?

Wednesday, August 20, 2008

Sysadmins are not programmers

In my new life as a technology liason/sometimes sysadmin, I've had occasion to watch a Windows Systems Administrator at work, and to marvel at the ways in which the mind of such a person is not the same as the mind of a programmer. This is, to me, rather shocking: after all, the great thing about computers is that they're programmable, right? So someone who spends their lives working with computers... well, you'd expect them to know how to automate things.

I've always assumed that being a computer type means that you follow a very simple axiom: never repeat manually what could be done by a program for you.

In other words, automate the automatable, whenever possible, and, when it's not possible, whine like hell.

It turns out that our SysAdmin consultant does not think this way. Or perhaps it's simply that his definition of "possible" is extremely limited. At any rate, as a result of his ignorance in this matter, I've been reading up on scripting, trying to get myself the requisite literacy in Windows programming that, staggeringly, the Windows expert lacks. In this case, I have a very simple, very tedious task to do:

1. Collect a list of student users from our online student information database.
2. Create Active Directory accounts for those students that don't already have accounts.
3. Delete Active Directory student accounts for students not on our list.

This is the kind of task that any lover of computers should refuse to believe must be done by hand. (Note that I also had to create google-based e-mail accounts for these people — that was a no-brainer because google is not designed by idiots (there's a defined csv file and all I have to do is massage the data into that format and upload it).)

Lo and behold, after much fruitless searching, I have at long last found instructions for creating Active Directory accounts from information in a spreadsheet (or, if they were more sane, a csv file) (hopefully that link will help future googlers).

As I began to read those instructions, though, I was struck by the following strange prose, which so confused me, and so revealed the weirdness of the category of "System Administrator", that I had to stop reading and write this blog post. Here goes:
System administrators, or so we are often told, are the last of the rugged individualists. System administrators don't use mice and dropdown lists; they type their commands at the command line. System administrators don't bother with graphical user interfaces; they like their data displayed in the command window. System administrators don't pull up to the drive-through window at a fast-food restaurant, they actually get out of the car and... well, okay, even rugged individualists have to draw the line somewhere. The point is, you can run a script by starting it from the command prompt and passing it a bunch of command-line arguments; in addition, you can output data to the command window or to a text file. What more could you possibly need?

The truth is, there are lots of times you don't need anything else. On the other hand, sometimes—just sometimes, mind you—system administrators look at applications like Microsoft® Excel and think about how nice it would be to harness some of the capabilities Excel for their own use. Consider, for example, the need to create a bunch of new user accounts in Microsoft® Active Directory®. Could you do that by passing command-line parameters to a script? Sure, if you don't mind typing in command strings similar to this:

cscript new_user.vbs /cn="Myer Ken" /sAMAccountName="kenmyer" /givenName="Ken" /SN="Myer"

Okay, maybe that's not such a good idea. But couldn't you read in all the information from a text file? You bet you could. Of course, the text file would have to look something like this:

"Myer Ken","kenmyer","Ken","Myer"
"Jones TiAnna","TiAnnajones","TiAnna","Jones"
"Smith Ben","Bensmith","Ben","Smith"

That works, too, but good luck getting your HR department to supply you with a text file that looks like that. Can you use these techniques? If you want to. But think about how easy it would be for your HR department (or whoever) to type all this information in Excel; in fact, there's a good chance that's what they already do. Yes, Excel is a graphical utility, and, yes, you're a rugged individualist, but just this once, wouldn't it be nice to be able to take an Excel spreadsheet, run a script against it, and then use the information gleaned from the spreadsheet to create a whole bunch of user accounts, all in one fell swoop?

Okay, sure, not for you. But maybe you have a friend who isn't as rugged an individualist as you are. If so, tell your friend that he or she is in luck. This month we're going to tell you—um, we're going to tell them how to use a script to read data directly from an Excel spreadsheet, and then use that data to create a bunch of new user accounts in Active Directory. And then next month we'll show them how to go the opposite route: How to grab data out of Active Directory (or some other location) and display it in a nicely-formatted spreadsheet. And listen: If you decide to try these scripts, we promise not to tell your fellow system administrators. Promise

Ok, let's look at the crazy assumptions in the above:
  1. The point of the commandline is that you can do things with lots of parameters, which shows you're knowledgable.
    Actually, the point is that you can chain various commands together, and save useful combinations thereof in scripts. No one prefers typing long chains of obscure switches to pressing a few buttons; it's just that there's no way to program button-presses, so programmers prefer the commandline. It appears that sysadmins (as imagined by the above prose) try to imitate programmers by typing everything into a commandline, but don't actually understand it).
  2. A CSV text file is scary
    WTF? Is there any decent programming language that doesn't have simple libraries for handling CSV files?
  3. An Excel file is different from a csv file
    Again, WTF? Is there any person sufficiently computer literate to be reading this document who couldn't turn a given excel file into a csv file easily (Save As...)? And is there any HR department that could be trusted to get column headers etc. exactly right so you could run a script using their Excel file? Or is it actually true that all the crap excel adds to data to make the HR department happy (like formatting, for example) just gets in the way of the programmer, which is why you'd convert to CSV in the first place. I assume in this example we'll massage it into a predetermined format of Excel file instead, but if that's the case, there's really no difference between the Excel solution and the CSV solution.
  4. Rugged individualists wouldn't run scripts against spreadsheets
    Huh? I frankly can't imagine how any thinking person (and I assume these straw-man rugged individualists would style themselves thinking people) could possibly consider creating users doing anything other than running a script against something like a spreadsheet (assuming, that is, that one is copying a list of users from elsewhere, such as HR).

Of course the ultimate WTF is that this functionality isn't built into AD at a more basic level.
Anyway, I'll be reading the rest of the article soon. The odd thing about the article is that it seems to posit a commandline-using sysadmin in opposition to someone with a modicum of programming knowledge. And that, I must say, is very strange.

Saturday, August 16, 2008

Pronunciation snobbery and Beijing

The other day the radio, I heard an NPR reporter doing explicitly something that has always implicitly bothered me about NPR reporters. She was talking with their China correspondent and asked him how to pronounce "Beijing". He explained that it's actually (in Chinese) pronounced [beʤɪŋ] (with a "j" as in "juice") and not [bejʒɪŋ] (with a "j" as the "s" in "vision" or "treasure"). An article I found here at goes so far as to make this hyperbolic claim:

Television networks should be setting a higher standard of pronunciation and fulfilling their role of informing and educating the viewing public," he said. "Mispronunciations are misinformation. The casual attitude of the networks towards this matter is, at best, negligent and, at worst, bordering on disrespect for China and the Chinese."

This is absurd of course. No one is recommending we actually try to reproduce the Chinese pronunciation of "Beijing", in which nearly every sound would be foreign to us (I believe it begins with an unvoiced non-aspirated bilabial -- not a voiced bilabial like we use) and in which we'd have to make sure we got the tones right. In no way does not speaking Chinese border on disrespect for the Chinese.

This is a more widespread phenomenon. I see it when the NPR folks try to spanishify their pronunciations of Latin American countries, (saying "chee - lay" instead of "chilly" for "Chile", for example). Have they forgotten that they're speaking English? It also reminds me of a habit of a certain acquaintance-who-will-go-unnamed who always strikes me as terribly pretentious in pronouncing all foreign words with faux-correctness, taking care to avoid flapping the "t" in words like "risotto", for example.

It strikes me that the NPR version of this has something to do with not wanting to offend people, or with the belief that Americans generally are woefully, shamefully ignorant. But isn't it obvious that all over the world people speak a handful of languages at best, and frequently just one or two (as we do), and that when they refer to other people's words, they follow the sound patterns of their own languages? I of course can pronounce Spanish place names just fine when I speak Spanish, but I find it awkward to try to pronounce them in Spanish when I'm speaking English -- that's why we warp pronunciations to fit our own sound patterns in the first place.

All of this rant is premised on my assumption the Beijing is always pronounced [bejʒɪŋ]. That does the beg question of whether I'm wrong and [bejʒɪŋ] and [beʤɪŋ] have existed as variants for some time. Is that the case? Has anyone ever heard the [beʤɪŋ] pronunciation used commonly? Is it common in Britain or other English-speaking countries? (note: pronunciations by Chinese speakers and hyper-self-conscious broadcasters don't count as common use).

Saturday, August 9, 2008

Grrr... I hate closed source software

So in my new life as a tech administrator, I've gotten to play with OS X server and client machines. It turns out that OSX includes more or less the equivalent of Norton Ghost for free — that's a good thing. Our school hadn't configured or used this functionality in the past — that's a bad thing. Enter me to save the day!

Anyway, long story short, our previous tech guy had upgraded our server to 10.5 in order to fix some now-forgotten-about bug (grrr #1: paying to get upgrades that are really bugfixes). So, long story short, after a long time today setting up an image and setting up the server to use it, I had a problem: for some reason Mac's System Image program wasn't seeing my source disk as a valid image. I couldn't figure out what was going on for the longest time, until finally on Mac's website I discovered it: with the 10.5 version of the System Image program, you can only create images of System 10.5 and later. Our client machines all have 10.4.x on them.


It's funny what you end up taking for granted in the open source world I'd been living in. Here are the things that would normally be unimaginable:
#1. That I can't update without making a big expenditure (and in this case, it would not just be one new client license but many)
#2. That I can't downgrade if an updated piece of software isn't any good (i.e. I can't get or run the 10.4 System Image program on my 10.5 server).

To solve this, I'll have to downgrade everything to the 10.4 server and hope that whatever bug bugged our last tech guy won't affect our new environment.

It's also quite puzzling to me that the System Image software cares about what kind of volume it's installing. I'd think with the base infrastructure in place, you'd be able to distribute images of any kind -- Window, Linux, Mac, what have you. I can understand that their might be some value-added stuff the System Image software can do that's specific to the OS, but it seems strange that they couldn't support at least a base functionality for any old system disk.

Lazy web programmers (or are they just stupid?)

I'm setting up some online auto-billing to save the pain-in-the-ass of stamps and checks here... this always gives me a chance to see some fine web programming on display. Here's an error message I just got that, unfortunately, is not at all uncommon:
Please enter 10 digits, leaving out characters such as "-" or "/".

My first response is: you lazy piece-of-crap programmer, how hard is it to strip out the character.

But then I realized something — the programmer isn't exactly lazy, they're stupid, because they took the time to write the code that generates the error message, but didn't take the time to just do what the user wants.

Here's some pythonic pseudo-code to illustrate:

To do it the right way
inputstring = get_idno_from_webform()
inputstring = inputstring.replace('-','').replace('/','')

To do it the wrong way...
inputstring = get_idno_from_webform()
def confirm_idno ()
inputstring = get_string_from_webform()

Grrr... makes you wonder -- who hires these people and how much do they make?

(Note: I realize that even in the ideal code you'd need an error message for cases where the user typed something totally invalid, so maybe they're just lazy after all. Still, the error code that handles things like a user typing "!)(*@!$#KJ" should pretty much never run, whereas the code that handles dashes (which are printed on the bill as part of the number) is really much more important and will be called for more often than not.)

Friday, August 8, 2008

D.A.R.E. Update

Today K was accosted by the same D.A.R.E. identity-card selling people in Arlington center that I wrote about a few weeks ago. In her case, they told her that next year ID cards would be required for children and cost a mere $65, making their price ($40) much more reasonable. They also helpfully suggested that if she didn't have cash she could give them a credit card number! So, it looks like this is an out and out scam and I should take back anything I implied about D.A.R.E. itself.

Except that the scam is based on an actual D.A.R.E. fundraiser, which, on second look, I was able to find on their website here. The description of the actual fundraiser is quite perplexing. Here are some choice quotes...
As part of the Child Safety I.D. Program representatives will offer D.A.R.E. Medical Emergency ID all-FREE of charge. During these events products including D.A.R.E. t-shirts, ID cards, DNA kits, safety videos and other child-oriented products, will be displayed and available for purchase...
This campaign is a great way to introduce and remind children about safety information. If children are made familiar with these techniques through reminders and role-playing with parents, they are less likely to find themselves in dangerous situations. We hope that no child or family ever has to use the emergency/medical D.A.R.E. ID card.

The above really doesn't get any better if you read the full context -- it's incoherent, at least to me. What, for example, is the referent of "these techniques"? In what sense are DNA kits child-oriented products? I still have no idea why I would be motivated to get this card, whether for free or (in the case of our local scam-artists) for $40 (although if they got my credit card number, I'm guessing it would come to much more than that...)

Wednesday, August 6, 2008

Tomatoes worth eating have finally arrived

I just finished a few weeks vacation in the Adirondacks. I returned to Arlington just in time for the farmer's market. The difference between what the market was when I left and what it was today was staggering: summer came out while I was gone. Tonight's dinner absolutely blew my mind — it's amazing how every year I forget just how good peak flavors are. In true farm market fashion, the foods that came out the best tonight were those I did the least to. The heirloom tomatoes sliced and sprinkled with basil and salt were the kicker. I had intended to do something else with them, but after making my first cut into one and tasting it, I knew anything else would be a waste.

These were the first tomatoes I bought this year — I've been letting my nose be my guide above all else, and it hasn't disappointed; you have to wait for tomatoes with that knock-your-socks-off fragrance, but it really is worth it. It makes me wonder whether it's worth buying fresh tomatoes the rest of the year at all (if you can't have the good stuff, it seems better just to go with canned, which pack more flavor than off-season fresh tomatoes anyway).

The corn was also fabulous — so much so I didn't adulterate it at all, just grilled it in its husk and ate it straight. I don't know why I ever bother trying to eat corn before August.