drewp

Zooko pointed out RFC3339, which is a recommended date+time format for internet protocols (and more) based on ISO8601 standards. I wasn't aware of the RFC before, and I think it's super.

I wish the RFC3339 format were the easiest format for every programmer to generate. The state of popular libraries is pretty bad in this regard, unfortunately, such that it's often easier to emit awful formats like "Tue Sep 22 00:10:49 2009" or do-it-yourself disasters like "04_02_03".

Zooko likes how the RFC suggests that one might like to replace the T with a space, as in "2009-09-21 23:30:00-07:00". I am against this practice.

The RFC itself includes a relevant anecdote:

. . . the date format in [IMAIL] has resulted in interoperability problems when people assumed any text string was permitted and translated the three letter abbreviations to other languages or substituted date formats which were easier to generate (e.g. the format used by the C function ctime). 

The first problem I have with "2009-09-21 23:30:00-07:00" is that it looks too much like two pieces of data, and in particular, it looks like you could take the "2009-09-21" word and use it on its own. That would be throwing away the time zone, however, so it's lossy. Pretend we each received the same list of times and our tools rendered the times into our own timezones. If we each cut off the time+zone parts of the values, we'd end up with different lists of dates.

Less importantly but more practically, the one-word version with a T in the middle works better as a command-line argument to a program; it double-click-selects better in GUIs; and it doesn't accidentally break up when you import a log file into a spreadsheet.

The argument against the T is that humans can read the value more easily. I'm sure that's true in some situations, but in my experience, users of time values either don't mind the T version or they have much bigger problems with the format ("I want am/pms", "Why is the day-of-month on the right? I like it on the left", etc). The RFC explains:

Because no date and time format is readable according to the conventions of all countries, Internet clients SHOULD be prepared to transform dates into a display format suitable for the locality. This may include translating UTC to local time.

Hypothetically, replacing the T with a _ would probably help readability without making a word split, but I don't actually think you should use underscores since that's even less standard.

tl;dr - Please read and follow RFC3339; and please don't change the T to a space.

Seth Godin wrote a short piece about bad surveys, but there's one point that I think he fumbled, in that he didn't make it convincing enough to the audience that would benefit from it.

"a vague question with vague answers (extremely satisfied...acceptable...extremely dissatisfied and no scale to compare them to) is a total waste of time"

I fear people will read that part, recall their own silly reason for using a dumb scale on survey questions, and discount the rest of the post. Let me try to make it a bit louder: we all hate your grids of 15 questions with 10-choice answers, and they make us think worse of your current project and all your future projects.

Surveys are good when they get you data: noncalibrated scales (like 'very true - somewhat true - neither true nor false ...') barely measure anything. For starters, 10 response choices don't tell you more than 5.

Surveys are good when they make your customers feel like they've been listened to: long grid-style surveys don't do that at all.

Now it's possible that some obsessive customers actually enjoy picking between a 6 and a 7, because they've made up some reasons in their head why this answer should earn the extra point for a 7, or whatever. Learn those reasons! These obsessive customers already write multi-paragraph reviews on amazon and yelp-- why constrain them into giving you a contentless '7'?

All Seth's other points apply, and #5 ("let people compare things") is totally underused. Comparing things is fun and fast, and the response scale is already calibrated. You don't have to guess anything from the stats. That's a very winning combination of attributes for a survey question.

This is a response to Download SPARQL results directly into a spreadsheet

So far you've motivated seeing the results of a query in a table and making a graph from them. I'd like to have both of those capabilities in a webapp. E.g. I should be able to embed a live graph in my own page like this:

<img src="http://sparqlgrapher.com/svg/example.com/query=SELECT+?date+?price+{...}">

Visiting my hypothetical sparqlgrapher.com directly would give you a UI to layout and customize the graph. When you're done, you'd take that url and embed it elsewhere (or just take a copy of the image, if you want a one-off).

So I read that google chrome shows the positions of in-page search results on the page's scrollbar:

(image from usabilitypost)

This is something David McClosky and I put into skim 5 years ago. Our version enlarged up the scrollbar so it was wide enough to show the horizontal positions of the matches too. Then we made multiple matches appear at once, and let the user click any word to add it to the search. You'd often type one word, jump around to the neighborhoods where it matched, and then click a few more relevant words to make the preview denser.

Ironically, I described it back then as looking like a Google cached page with search terms highlighted in different colors, but zoomed out. In the code, the widget is called "birdseye".

Greg at Raizlabs has two more variations: ABC and heatmap

Blogger wouldn't format this right, so I'm putting my response here.

Original post

Here's a version using the file iterator capabilities on stdin, enumerate for the line number, all the logic combined into one if-statement, and a different strategy for printing the highlights.

#!/usr/bin/python -u

import sys

try:
   pat = sys.argv[1]
except IndexError:
   pat = None

for lineno, line in enumerate(sys.stdin):
   if (pat and pat in line) or (not pat and lineno % 2 == 0):
      print "\x1b[7m%s\x1b[0m" % line.rstrip()
   else:
      print line,

"Sun's industry standard x64 servers run 50% faster, use 66% less power, take up 1/4 the space and are priced at half what a comparable Dell box is. All this while running Sun Solaris, Linux or Microsoft Windows."

(from http://blogs.sun.com/roller/page/jonathan?entry=a_brand_is_a_promise)

How is the Dell box "comparable" then?