New Kindle DX annoyances
Jul/100
I just don’t get it. Amazon has introduced the new Kindle DX. I have a Kindle DX and use it. It’s pretty great. I’ve kept my oath for some months now not to buy another printed book, so my DX and the library have been wonderful helps.
But the new DX . . . Greater contrast is a good thing. But where is the left-side button for turning the page? Every DX user I’ve talked to who has also used a regular Kindle has complained about this. It is really great to be able to turn the page with either the left hand or right hand. Meanwhile, the DX still has the crappy squeezed keyboard, which is a step back from the keyboard on the newer 6″ Kindle. Maybe in user testing the squeezed keyboard was more effective. But it sure isn’t for me.
And, still, the web browser is “experimental.”
I am a believer in separate reader devices (that is, separate from reading on your computer, phone, or tablet) but this device is not making headway.
Running the gem doc server at startup on OS/X
Jun/100
I’ve been traveling a fair bit lately, and have occasionally had spotty Internet access. So my access to documentation for gems and whatnot has been limited.
It would be nice to have all of my gem documentation available locally. But I’m lazy. I don’t want to be typing “gem server” all the time.
So here’s what you do. Locate your appropriate gem command with “which gem”; I’m using rvm to run Ruby 1.9.1, so my answer is: /Users/jgn/.rvm/rubies/ruby-1.9.1-p376/bin/gem
Then create a gemserver.plist file like so, replacing the path to my gem with the path to yours:
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>localhost.gem.server</string> <key>ProgramArguments</key> <array> <string>/Users/jgn/.rvm/rubies/ruby-1.9.1-p376/bin/gem</string> <string>server</string> </array> <key>RunAtLoad</key> <true/> </dict> </plist>
Now copy to /Library/LaunchDaemons
The next type you reboot, you’ll have your gem docs at http://localhost:8808/
Bruegger’s free wifi terms of service — Usenet?
Jun/100
Bruegger’s (in Porter Sq., Cambridge, at least) has some words regarding Usenet (!) in their free wifi terms of service:
Usenet News in Particular.
With respect to Usenet news, you understand that we are providing you with unfiltered access to Usenet. You should be aware that we cannot, nor do we try to, control the content available via Usenet. By their very nature, some Usenet groups may carry offensive, harmful or inaccurate material, in some cases in postings that have been mislabeled or are otherwise deceptive. Use caution and common sense when using Usenet. Notwithstanding the foregoing, Bruegger’s may adjust the Usenet groups it carries at any time for any reason in its sole discretion.
Gosh.
ATT still hasn’t figured out what business it’s in
Jun/100
It is comical to me when I read the fine print regarding ATT’s data plans for the iPhone. They are so dedicated to a “connection” model for billing, that they just can’t understand that they sell bytes.
In the olden days, you paid for a land line connection, and could make all of the calls you wanted. The SLA was rather robust, allowing for you to “just make calls” whenever. The agony of the phone company then was in switching: Did they have enough capacity to manage enough calls from a particular zone, through other zones, and then on to the other end of the call? Your bill was paying for switching capacity, amortized over time.
But now, of course, they just sell bytes. If only they would just bill me per byte (e.g., for the 2GB/month plan, around $0.000000011641532 / byte).
But no, we have all of this craziness regarding how many bytes you get for how much money; that I have to pay extra for tethering (even though I get no extra bytes); and that if I’m using an ATT hotspot for iPhone Wifi, I can’t tether my laptop through that (tethering is only through 3G).
Inane.
I just want my bytes. Give me my bytes. And let me monitor my own behavior (and conserve bytes, if I want to). And bill talk time as bytes, too. I think if we paid for bytes, maybe our calls would be shorter because we’d realize the cost of our own breath.
favicon at ruby-doc.org the wrong size? And what is it?
Jun/100
Here’s the favicon (the image that should show up next to the URL in the browser) for ruby-doc.org:
What IS that? Some kind of stylized “R” + “D”? And why is it the wrong size? Sheesh.
Bonoff / Squeeze?
May/100
Karla Bonoff’s “I Can’t Hold On” is co-written with Difford and Tilbrook (Squeeze)!? Who knew?
I think this is just allmusic.com being confused about two songs with the same name.
Ruby GData API, Google Calendar, and redirects
May/100
The Ruby GData API provides for accessing a number of Google data sources: Google Apps, Analytics, YouTube, you name it (http://code.google.com/apis/gdata/docs/directory.html).
When you access a Google Calendar that is managed through a Google Apps username (e.g., you@example.com, as opposed to you@gmail.com), the standard lookup feed (example: http://www.google.com/calendar/feeds/default/owncalendars/full) redirects after you access it. (Not the case for calendars owned by gmail.com addresses, it would seem.)
Well, bizarrely, in the Ruby implementation (which you can find here: http://code.google.com/p/gdata-ruby-util/ Ruby 1.9 version here: http://code.google.com/u/hoanga/), redirects are not handled properly.
Handling a redirect is a “must have” to get into the Calendar data for a Google Apps user.
The master code repository is hosted on code.google.com, so since it doesn’t provide for submitting patches as easily as Github, I’ll just lob a monkeypatch fix here . . .
# Fix for GData::Client::Calendar failure to follow redirects
module GData
module Client
class Calendar
def make_request(method, url, body = '', retries = 4)
response = super(method, url, body)
if response.status_code == 302 and retries > 0
@session_cookie = response.headers['set-cookie']
# original wasn't capturing the redirect location
redirect_url = response.headers['location']
return self.make_request(method, redirect_url, body, retries - 1)
else
return response
end
end
end
end
end
For Rails, you can put this into a file in config/initializers
Default params for POST in HTTParty
May/101
So I was looking at the API for ping.fm (http://groups.google.com/group/pingfm-developers/web/api-documentation?_done=%2Fgroup%2Fpingfm-developers%3F), and thought: Ah, this would be easy to wrap with HTTParty (http://github.com/jnunemaker/httparty).
For ping.fm, all requests must be POSTs, and each request much include a couple of keys. But in HTTParty, you can’t specify default params that should be used every time for POST.
So I fixed that. See below. I’m too lazy to fork, add my code, write tests, and create a pull request, so I’ll just have it here for posterity.
Then I realized that there is probably a gem for ping.fm — and there is! So I won’t be using HTTParty after all!
But here’s the code. For a Rails app, just put this in a file in config/initializers.
# Provide means for HTTParty to allow for default body parameters
module HTTParty
module ClassMethods
def default_body_params(h={})
raise ArgumentError, 'Default body params must be a hash' unless h.is_a?(Hash)
default_options[:default_body_params] ||= {}
default_options[:default_body_params].merge!(h)
end
end
class Request
def body
if options[:default_body_params]
if options[:body]
if options[:body].is_a?(Hash)
options[:body] = options[:default_body_params].merge(options[:body])
end
else
options[:body] = options[:default_body_params]
end
end
# original:
options[:body].is_a?(Hash) ? options[:body].to_params : options[:body]
end
end
end
Goodbye, Alex Chilton; 1950-2010
Mar/100
Some time around 1979, I was DJ’s at the college radio station, and someone pointed out to me a scuffed-up album called “Radio City” by a group I’d never heard of called Big Star. The album had come out in 1974. I listened to it, liked it, played it a bit, and forgot about it. About all I really understood at that point was that they sounded a lot like the Raspberries. Meanwhile, a lot of my friends were getting into this guy who had connections to groups like the dB’s. His name was Alex Chilton, and the discovery of the moment was his 1978 “Bangkok” single. About this time, I realized that Chilton had been a co-lead of Big Star, and that he had also sung with the Box Tops, singing the estimable song “The Letter” when he was 16.
After college I started to rediscover that material, and bought everything I could find, including vinyl copies of Big Star’s first two albums, “#1 Record” and “Radio City.” When CDs came out, I didn’t buy any until the release of both of these albums came out on a double-CD on England’s Big Beat label.
It’s a great pair of albums. They were recently remastered — you safely ignore the negative comments on the Amazon page after clicking on the image:
For a good while, Chilton was my favorite songwriter. I listened to those two Big Star albums countless times. I saw Chilton play live in a number of forms, including some really godawful shows in the mid-80s. People complained about his solo material after 1985, but I liked it, and I liked his highly ironic shows.
I read today that Alex Chilton died in a hospital in Memphis of heart problems. What a loss.
The iPad and the classroom
Mar/100
I’ve been thinking some about the iPad and the classroom. My bet is that it would be a better book reader than the Amazon Kindle for two reasons:
- it seems likely that books will be delivered to the platform as PDFs, which typically means that the page numbers will correspond to the printed editions. In my view, a major flaw of the Kindle is that it gives page locations in “locations,” which can vary depending on the size of the font. Therefore, a teacher can’t assume that the locations match page numbers, nor can the teacher tell everyone to go to the same location and be assured that all students are in the same place.
- Color. Many course texts have illustrations that truly require color. In computer science, it is common for diagrams and charts to differentiate information based on color. When the page is shown in black and white, this is lost. (To be sure, the diagrams should probably be rendered so that they look good in black and white — students still use black and white photocopiers, and need the information to be preserved, rather than washed out.)
But the other aspect of the computer-in-the-classroom is student usage during a lecture or seminar. Laptops are highly problematic. As a teacher, the “screen up” position blocks my ability to observe student faces, and those faces are focused on their laptop screens, not on me, my slides, or the board. In other words, students may not be paying attention. Students will tell you that they can multitask, but my experience has been that students who pay attention do better. Computer science, like the teaching of literature, which I did for years and years, frequently requires high-speed “checking” between the lecturer and the students to verify that people are “getting it.” With the laptop screen up, this channel is somewhat blocked; it’s lower bandwidth.
So, at first blush, the iPad might be an improvement. Because it’s flat, students are more likely to keep them down on their desks. They may still be focusing on the screen, but at least I can see their faces.
Now that the iPad is down on the desk, how will students interact with it? Apple’s promotional material makes much of the virtual keyboard, but I’m skeptical of this user interface for the classroom. It’s hard to touch type on a virtual display. Again, the student’s eyes are drawn to the screen.
And what if students want to draw a copy of a diagram from the screen? Use their fingers? I don’t think the capture resolution will be precise enough. This is a place where pen input can be a godsend. On my ThinkPad tablet, the pen really works. Indeed, on the ThinkPad, it is possible to switch dynamically between pen and voice input, which is surprising effective. Some students will say that they don’t need to take such notes, because they can always re-watch the recorded lecture. But this is problematic, because now they have to go through the lecture twice. It’s not as efficient. This is why I’m always skeptical of students who want to do audio recording. Audio for what? Re-listening to the lecture? What about paying attention, and taking great notes. It can be done. (To be sure, students with language deficits in English may need the audio copy, but I digress.)
So, in sum: My prediction is that the iPad will be a good reader device in high education; I’m not so sanguine about it as a note-taking machine.
