Catching Up to the New Television

First, there was broadcasting. This is one-to-many, and because of the costs and because of regulation, there weren't that many "ones" floating around. If you live in a town with an ABC and a CBS but no NBC, for example, that's because they decided years ago that your town only needed two broadcasters. When I was 14, in St Louis, we had ABC, NBC, CBS, PBS, and two or three UHF channels showing syndicated reruns. That's how I came to know Rowan and Martin's Laugh-In. Remember the Weird Al movie, UHF? I can't say that real UHF was like that, but there was more than a little truth to it.

Then came cable. The one-to-many paradigm became some-to-many, but through one wire. "57 channels and nothin' on" was the Boss 20 years ago. Seems kinda quaint today, doesn't it? The TVs were set for UHF and VHF, so special adapters had to be bought so your TV could get the cable channels. Eventually, you started to get "cable-ready" TVs. Right now, we have a TV that was swank in 1988 that has channels up to 60-some and three stereo RCA ins (for VCRs and such) and a few 1990s TVs that have channels up to and past 100 and one mono RCA in. Once, my VCRs were connected daisy-chained over co-ax, but now when I set one up, I always go RCA.

I guess there are two big changes post-1999, and they would be TiVo and YouTube, but to take away the camel caps and brand names, you can say digital video recording and Flash video. Once, when you wanted video online, it opened up Real or Quicktime, and I groaned for all the configuration options. I was applying for a web-dev position and one of the company's sites had video in the page and it amazed me. Since then, it's become a big thing. So big, in fact, that a <VIDEO> tag showed up in HTML5. Clearly, now it makes sense to have a computer connected to your TV, making TVs more and more just monitors.

(I suppose that the move from videotape to DVD and beyond needs a mention. DVDs were clearly better than tape — better image, no rewinding — so the video stores cleared out their tapes. Streaming video is equal in quality and clearly more convenient than DVDs, so strip malls are clearing out their video stores. I think that Blu-Ray is impressive, but like digital broadcast, it came in just in time to herald the end of non-streaming-internet video. Both require a change, and if the world is going to change, why go with the only-vaguely-better?)

The old TV way of scheduling recordings sucked. If you knew the time and channel and duration, you could set it up to record, but you could only watch what you're recording. My 80s videotapes are either Dr Who shown on PBS starting 10pm on Sunday or lots and lots of videos off MTV. (Yes, I still have some VHS tapes. No, I don't watch 'em much. Yes, it's more convenient to watch the same Tom Baker eps off Netflix and searching "Humpty Dance" on YouTube. I'm getting to that.) If you have your VCR inline with your cable box, it got worse, because your VCR couldn't change the channel and you might get several hours of the Weather Channel. With the TiVo, and with the set-top boxes that came after, and the TV tuner cards that cane after that, you have a box that knows the TV channels and schedules, can switch between them,

This is clearly wonderful, as this means that you are no longer bound to be at the TV to watch your favorite show at 9pm on a Tuesday. It also means that there's an explosion of set-top boxes, often doing mostly the same thing. GoogleTV, AppleTV, Boxee, Roku, TiVo, Wii, XBox, PlayStation, whatever came with my Samsung Blu-Ray player, all wanting to cover some subset of Hulu, Netflix, iTunes, Amazon on Demand and YouTube, plus whatever other streaming stuff is available.

I'm slowly trying to get from the 90s model (CRT, cable, VCR, DVD player) to the 2010 model, but I'm not sure what the 2010 model really is. Clearly, going to an HDTV that's inches thick instead of an old screen that's feet thick is a crucial move. I think the general-purpose computer is a dying thing, but a machine running Windows can handle all the video codecs and sites and choices you might want to do. I have an inexpensive VGA-RCA converter and an old desktop running at 800x600 connected to a big monitor right now, and another with a Wooted TV tuner. This gets my toe in, and while the first step is clearly getting a bigger, better, thinner HD screen, I'm not sure what the next step is. A recent Wired article seems to say that you can get everything you want cheaper by renting the shows than by getting cable. I'm thinking that having seventeen boxes connected KVM-like to my HDTV/monitor might be the way, but that seems so wasteful and wrong, too.

Dropbox v Ubuntu One

Here is a good head-to-head comparison between Dropbox and Ubuntu One. I cannot speak to everything in the article, but I can say that I have Dropbox working on two Linux machines and three Windows machines (2 XP, one Vista) and have always found the installation process extremely fast and painless. I have tried to get Ubuntu One working on my two Linux machines, but for my home machine, it always seems to trigger a problem that kills X, which is not good.

The thing that Ubuntu One does that Dropbox doesn't is sync contacts, but that's not an issue for me because I use Google to store and manage contacts anyway, and Zindus to access them in Thunderbird.

So I'm in agreement with the take-away: Use Dropbox, not Ubuntu One.

That being said, if I invite you to Dropbox and you join in, I get a bump in storage space. So, please, get Dropbox.

jQuery .css() Performance (1.4.2 vs. 1.4.3)

jQuery .css() Performance (1.4.2 vs. 1.4.3)
Originally uploaded by John Resig

I like this. I really do. Every improvement to jQuery is a big win to my life as a web developer.

But....

Isn't it best to do your CSS in your .css? If you need to change a stylesheet thing, make a class and .addClass(myClass) to it?

Thoughts about Passwords and their replacments

As I discussed previously, there's a rising use of OAuth as a mechanism to do authentication online. I don't really grok it, but I get it now.

Alice wants to use Bob's website to send her tweets to Twitter. Bob sets up with Twitter to get his Consumer Key and Consumer Secret. This uniquely identifies SuperCoolSiteOfBob as a Twitter client. Alice goes to Bob's site and starts to connect. This means a jump to Twitter to allow/deny SuperCoolSiteOfBob to do what it needs to to Alice's Twitter feed, in the form of giving Bob an Access Token and Secret to Alice's account. Alice can check her settings and see SuperCoolSiteOfBob and all the other folks she let have access to her Twitter account, and Twitter can decide that SuperCoolSiteOfBob is doing the wrong thing and block it. All without giving out the main keys to the city, Alice's Twitter password.

This is a good thing.

If anyone asks you for your login and password, who isn't the one and only service you're trying to access, while you're trying to access, treat them like they are trying to bankrupt you, take all your belongings, sell your children into slavery and do donuts in the Payless parking lot until your tires burst and your rims spark. Go to a site and have it say It will be much cooler if you could talk to all your friends, so give us your Gmail login and password and we'll see if they're already on and I read it as saying I'd like to f*** your wife or something even more offensive. Here's a several-year-old discussion of the problem and why OAuth is needed.

Let's sidestep for a moment. There's DVDs. There's basic encryption so not just anybody can play (meaning rip) DVDs. Yet, you want people to play (meaning watch) DVDs, and here, yes, you want just anybody to do so. Children watching Spongebob Squarepants. The elderly watching I Love Lucy. The stoned watching Spongebob Squarepants. Just put the disc in and go. So, everybody needed the key, but you needed to hide the key. And, people wanted the key so they can rip DVDs. And they got it.

Now, let's switch from SuperCoolSiteOfBob to SuperCoolAppOfBob. This is running on Alice's desktop or her phone. Or, Marcia's. (I mentally think of Alice and Bob as Alice the house keeper and Bobby of the Brady Bunch. Eve the eavesdropper is of course Eve Plumb, who played Jan. I once made mugshot-looking images with the protect-the-innocent black bars across their eyes.) Marcia can easily do what they did to DVDs to Bob's app and come up with a Twitter-bashing tool that claims to be Bob's app, eventually forcing Twitter to disavow and denounce Bob, meaning that Alice has to download another app to do her tweeting. Which is bad.

I do have a thought here. Bob as developer needs to have a Consumer Key and Secret (from here on out referred to as Consumer Key) in order to test and know his code works. Bob as website needs the key and can keep it secure. Bob as software vendor doesn't need to distribute his Consumer Key with his software, as long as Alice can easily get one from Twitter, and the process is not too hard. Why don't we go with this?

The Trojan Phone?

Do you read Eric Raymond's blog? I put it on my Google Reader list, but I haven't hit it in a while, but I read a few in the last few days.

If you've been watching Google lately, with the joint take on Net Neutrality with Verizon, it's easy to wonder "What are they doing?" ESR's take seems to be that, by getting the phones cheaper, they're breaking the hold that the phone providers have. Combine this with Jeff Atwood's take that the fast OODA loop is beating the handset maker and service providers option-breaking "customization" and you begin to see a world with very powerful, very inexpensive and essentially unlocked phones. Which I think is way cool.

Question to Python Programmers

I am not a Python guy. I'm a Perl guy. I've tried it several times, and each time, I've found something that offended me about it. The first time, yes, was about whitespace. Finding the one SpaceTab intent in a page full of Tab indents took an hour and soured me. But the second time, the way Python's equivalent to LWP worked was seriously counterintuitive.

I've found something exciting and new that bugs me. Take this as a sample chunk of perl.

use This ;
use That ;
use The::Other::Thing ;

a() ;
for my $i ( b() ) {
    c($i)
    }

sub a {
    ...
    }

sub b {
    ...
    }

sub c {
    ...
    }

I edit a program and, after the declarations, all my central logic is up top. Compare a Python program.

import this
import that
import the_other_thing

def a:
    ...

def b:
    ...

def c:
    ...

a()
b = b()
for i in b:
    c(i)

This puts the "main" of the program at the bottom. I couldn't even fake it and make a def main(): and put it somewhere, because it would have to come after all the functions it uses anyway, so it would be useless.

If programs are to be written for other programmers to read and only incidentally for computers to run, it seems like this forced formatting seems wrong. But I'm willing to be taught. Am I missing something on this one?

More Than Changing Gears, Changing Transmissions

I have a friend. He plays drums. He's a good drummer. We were talking recently about playing, and he said that he plays guitar some, but can't get into it as much as the drums, because he's already hit a certain level with the drums and he can't get to that level with guitar, and he gets frustrated. I'm the same way with non-guitar instruments: when you get past the point where the novelty is amusing, you're stuck at the point where you're struggling to do things you fly through on other instruments, knowing you could be working toward the next level on your primary instrument instead.

I consider myself a Perl programmer. There's interesting things I do with Javascript, but if there's any decision to make on my part on how to implement something, I will choose Perl. I have spent over ten years in computing and there have been few problems where the solution wasn't a sudo cpan away.

There's a program. It handles big data and makes graphs and such out of it. It's a big graphical Java application. There's a lot of things that it does, and if you mean to use it once or twice, there's a lot of powerful parts, but if you need to use it many, many, many times, it gets to be ponderous. There's been requests for a programmer API to be made for this, but that is, at best, still in the works.  So, I've been trying to use Sikuli. Sikuli uses screen captures to find where to click. It's a neat thing, but there are a few issues. It's also written in Java, and it uses Jython, an implementation of Python in Java, for scripting.

Which leaves me having to learn Python. There's significant enough syntax differences that I feel like I'm learning to program from scratch. I've just searched Google for for loop python and python arrays, to show exactly how back-to-the-start I am.

I don't know. There's probably something good about this. I'm being stretched to figure this out. Plus, of course, I get one more name to tag onto the end of my resume. But it doesn't feel like it's a good thing. It feels like a pain, like frustration.

Surviving the Twitpocalypse

The 2010 Twitpocalypse has come. Buffy didn't save us this time, I guess. And what that means is that Twitter is no longer doing basic authentication for anything but their home page. So, if you have code like this:

my $twit = Net::Twitter->new(
    username => 'varlo',
    password => 'ISoLoveEdward' , #No Jacob
    clientname => $client ,
    ) ;

You're kinda screwed.

It's using OAuth now. I don't fully grok OAuth, so if you want the full deal, you should Google it and all, but in a nutshell, there is a key and secret combination that uniquely identifies my application. You use this application and it says "I don't see a user key" and sends you to Twitter. You get a user key and value, and you can use that user key and secret in conjunction with the app key and secret until you decide to go to Twitter and disassociate your user key with the app key.

This means that at no point does the application have your password, the same password that you might use for your pizza delivery, bank, email, etc. Until I began to understand OAuth, I thought it was a PITA, but I now think it's at least 70% win.

I have discussed Net::Twitter before, so most of the following code has been up before. My preferred way of handling a status is to join STDIN or ARGV with a space, but there should be enough here for you to adapt it to your workflow.

#!/usr/bin/perl

# largely taken verbatim from
# http://search.cpan.org/dist/Net-Twitter/lib/Net/Twitter/Role/OAuth.pm

# Next step is to get the keys and secrets to a config.

use 5.010 ;
use strict ;
use IO::Interactive qw{ interactive } ;
use Net::Twitter ;
use Carp ;

my $status = join ' ', @ARGV ;
if ( length $status < 1 ) {
    while (  ) {
        $status .= $_ ;
        }
    chomp $status ;
    }

if ( length $status > 140 ) {
    say { interactive } 'Too long' ;
    say { interactive } length $status ;
    exit ;
    }
if ( length $status < 1 ) {
    say { interactive } 'No content' ;
    say { interactive } length $status ;
    exit ;
    }

say $status ;

# GET key and secret from http://twitter.com/apps
my $twit = Net::Twitter->new( traits          => [ 'API::REST', 'OAuth' ],
                              consumer_key    => 'GetYorConsumerKeyFromTwitterDotComSlashApps',
                              consumer_secret => 'GetYorConsumerSecretFromTwitterDotComSlashApps',
                              ) ;

# You'll save the token and secret in cookie, config file or session database
my ( $access_token, $access_token_secret ) ;
( $access_token, $access_token_secret ) = restore_tokens() ;

if ( $access_token && $access_token_secret ) {
    $twit->access_token( $access_token ) ;
    $twit->access_token_secret( $access_token_secret ) ;
    }

unless ( $twit->authorized ) {

    # You have no auth token
    # go to the auth website.
    # they'll ask you if you wanna do this, then give you a PIN
    # input it here and it'll register you.
    # then save your token vals.

    say "Authorize this app at ", $twit->get_authorization_url, ' and enter the PIN#' ;
    my $pin =  ;    # wait for input
    chomp $pin ;
    my ( $access_token, $access_token_secret, $user_id, $screen_name ) =
      $twit->request_access_token( verifier => $pin ) ;
    save_tokens( $access_token, $access_token_secret ) ;    # if necessary
    }

if ( $twit->update( $status ) ) {
    say { interactive } 'OK' ;
    }
else {
    say { interactive } 'FAIL' ;
    }

#========= ========= ========= ========= ========= ========= =========

# Docs-suggested
sub restore_tokens {
    my $access_token        = 'GetYrOwnAccessToken' ;
    my $access_token_secret = 'GetYrOwnAccessTokenSecret' ;
    return $access_token, $access_token_secret ;
    }

sub save_tokens {
    my ( $access_token, $access_token_secret ) = @_ ;
    say 'access_token: ' . $access_token ;
    say 'access_token_secret: ' . $access_token_secret ;
    return 1 ;
    }

And if this has helped anyone drive their pet dingo and XB Falcon into the post-twitpocalyptic wasteland, remember, I'm just here for the gasoline.

First Pass on Javascript: The Good Parts

I read some of Douglas Crockford's JavaScript: The Good Parts on Safari, using the school's site license. I saw some of the talk videos on YouTube and Yahoo Video. I now have a copy on my desk.

I've even been putting some of my code into JSLint. It has a warning — JSLint will hurt your feelings — which is exactly right. I mean, ow!

I'll say more on this book the more I integrate it into my headspace. I've been getting serious about Javascript over the last few years, after over a decade of being vocally dismissive of it, because changes have made the languages run faster, as has Moore's Law. The first machines I did web development on would be seriously outclassed by first-generation iPhones. I take that back — even the second machines I did web development on are seriously outclassed by first-generation iPhones. And as a programmer getting serious about Javascript, I want my code to be serious, too, not just lame hack stuff. Which is where having JSLint comes in handy.

And where my issues start to come in.

You can see this as having a similar purpose as Damian Conway's Perl Best Practices and the connected Perl::Tidy, where you use the tool to outline the changes the book suggests you make. Except, Perl::Tidy gives you chapter and verse as to where to look up the dink and allow you to learn. As I put more code into JSLint, the more I wonder "Why is that?" and so far, I'm not finding the answers in The Good Parts.

Still, if you're a Javascript programmer, you can probably help yourself out a lot by getting this book.