![[Comments]](/nb//themes/Default/comments.png "3 comments")
(3) 2010-02-07T23:16:23 [link] (3) 2010-02-07T23:16:23
Obviously some of my posts are meant to help people who don't read my blog, so it's interesting to see what search terms are actually bringing people to my articles.
My search results for these queries may have helped:
My search results for these queries probably did not help anyone:
And to those who came to this page while looking for something in the top list, I'm sorry.
[link] (1) 2009-11-07T19:24:11
Goal: open garage door by cell phone, because its own remotes break a lot, and we're often not in the car when we want to open the door anyway.
I made this web UI. Dragging the window up makes a POST request for a quick-expiring, one-time-use access code:
All the phones we've tested can't actually make a drag event on a web page, so there's also an invisible tap zone above the button cover that animates it sliding up.
When you push the button, that posts your access code to my public web server. If that server approves, it makes an internal POST to another server on the parallel port. Would you like to control your parallel port with http post requests? Try this server. Since my parport is also controlling a shiftbrite, I'm actually using this other server.
A parallel port pin activates this relay, which closes the normal garage door opener circuit. The garage door just thinks the computer is another button, and all the existing buttons and remotes work the same.
A chopped centronics cable connects to a transistor with power from an old computer power supply.
Relay board on the ceiling of the garage. Most of the time, I forget to add blinky debugging lights to boards. This time, I remembered to include a blue LED for the relay status.
The parallel port pin only has to go high for a moment for the garage to open, and apparently my port does that at reboot. It was surprising.
I added a low-pass filter so the pin has to be held high for a long time before the garage opens.
5K
parport ---R--+-+-> transistor 2222 -> relay
| |
10K R C 1000uF
| |
gnd ----------+-+
The parport is about 3V, and it takes about 1.5 seconds for the relay to trigger. Relays sound cool when they're fading on.
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.
Some goals for a better wiki system:
A common case seems to be "add a new page and list it in some existing TOC section". Another one is "add a new section (paragraph or more) to this page". Editing words within an existing section that you didn't write, that might be rare.
I still like tinymce, although nelix_ isn't a fan.
Wikis that I use (that I'm trying to be better than) are: twiki, zwiki, confluence.
Related: rdf blog engine ideas
 | Unless otherwise noted, all content licensed by Drew Perttula under a Creative Commons License. |