Cookie Notice

2014/02/22

A decade ago, I started to get obsessed with the idea of hooking a computer to my car. I thought about storing and displaying diagnostic and status information, about storing music and podcasts, about having it handle navigation and all sorts of stuff. I hit the point where I considered the trade-off between storage media — solid state would be more survivable, but I could get literally hundreds of much bigger spinning hard drives for the cost of an SSD — and decided to keep it a mental exercise.

Point I'm trying to make is, for all my dreaming of putting a car into my computer, I now have one every time I sit down in my car, and even better, it comes back out every time I get out, so I don't have to worry about it when I go to the office, and it isn't locked in there if I have an accident. Things like Ford's Sync work best when they realize they're just an interface between your phone and your car.

(I now have an OBDII-to-USB cable and a Raspberry Pi, so I will have a computer in my car, but I'm going to explore the API and try to do more of the controlling-the-car things than a phone app would do. Certainly I'll still listen to podcasts while driving with my phone, not my Pi. I'll be sure to blog about it later.)

But I am not here to talk about car PCs.

I'm here to talk about home theater PCs.

I have one. It's an old HP that was handed down to me because it had connection issues I have never been able to replicate. The CMOS battery had died and corroded, too. Now it runs Windows 8.1 — will the indignities never end? — and I have it in my bedroom connected to the VGA port of my TV. I don't often use it, because when I start throwing pixels through the video card, the fan starts up and I have to turn it up to hear anything. I use it when I want to play with Windows 8, so not a lot.

When I want to consume media these days, I pull out my phone or tablet and point it at the Chromecast. More and more apps are coming — Google's opened the ChromeCast API — so the sweet spot between "essentially a wireless HDMI cable" and "smart thing that holds on to your credentials and streams you stuff" is being filled with more and more things.

I have a BluRay player. It comes with a wired ethernet jack in the back, and I have on occasion had it set up so I could use the networking portions, but when you're searching for YouTube videos or trying to type in passwords, the remote is a poor interface. Updates to YouTube's TV interface and others now bring up a URL you browse to that sets up the connection between your box and your account, but that's an update nobody ever pushed to my BluRay player; basically, once they make the next device, they don't care about the old one, so nothing cool is ever going to come back to my several-year-old player. This is what I fear is the fate of proprietary smart TV interfaces: the next cool thing in streaming apps will come next year, while I'll hold on to any TV I buy for several years, which means I'd have an ugly interface I hate for a decade after the company doesn't care.

We just got a Roku; I haven't even used it yet, and have only touched the remote once. It makes sense for the living room TV, which is old enough that it doesn't have an HDMI port. There is a Roku app for Android, so I'm sure I'll use it in a similar way to how I use the ChromeCast.

I saw a presentation recently that showed the older Google TV interface next to the Apple TV remote, arguing that every button in the full-keyboard-rethought-as-an-XBox-controller is a delayed design decision, and that the sparseness of the Apple TV is a selling point; I haven't used the Apple ecosystem, and I understand it's really slick, but trying to handle deep, full and varied content through such a limited interface. (Sophie Wong has a fuller discussion with photos of both remotes in a blog post.) The Roku's remote adds to that by having a hardware button to go directly to Blockbuster's app; Blockbuster is defunct and now there's a button always pointing to a dead thing. Software remotes like the Roku app should be easily updated to the sweet spot of usability.

When some people I know have tried the ChromeCast, they've objected, because they want a computer they control, not a second screen for their phone. I recognize that thinking, because really, that's what I was looking for in a car PC, before I realized that it isn't what I really want. Nothing built-in, as little smarts as I need to talk to it, and as much controllable from my phone as possible.

Do you have an argument for set-top boxes I haven't talked through? The only one I can think of is that content providers sometimes allow their content to be viewed in one forum and not others; the video to the left of Marina Shifrin telling her boss she quits through the art of interpretative dance is one of many that is cleared to be shown through TV only. As the use of phones for connectivity dwarfs the use of desktops and laptops, I'm sure that'll fall. If there's another argument, I'm game to engage it.

2014/02/21

I have a FitBit Ultra (which I have discussed before) that I use to keep track of my daily activity, trying to force myself into higher and higher numbers, toward the AHA-suggested 10,000 steps per day.

In all honesty, I have dropped my personal goal from 10,000 steps to 6000, because 6000 is an amount that I can adjust my day to get, while I have to spend hours of my evening walking around to get myself up to 10,000. With 6000, I have a lower barrier, so I don't beat myself up with disappointment as easily. I still do, because I still have <3000-step days, but with 6000, I feel I have a fighting chance.

I have a FitBit but I don't pay for the upgraded API, but I can check every hour. And now I do.

There are three modules that are mine: the fitbit module which comes from my fitbit_tools repository; locked module which uses xscreensaver-command to determine if the screen is locked (if I'm not at my desk, my step counter isn't being updates; and pushover, which uses the Pushover service to keep me informed. I could and maybe should have it do speech with Festival or pop to my screens with Notify or Snarl, which also are desktop-centered tools, but this is what I have.

Similarly, perhaps this task is better suited to a key-value store like Redis than MongoDB's document store. At most I'm having one entry per day and the first entry of a day clears out all previous entries.

But, notwithstanding all the perhaps-suboptimal design decisions, this is an example of how coding and quantifying yourself can help you improve your life.

2014/02/15

I listened to FLOSS Weekly's podcast on nginx today, and it hit a cap on something that I've been considering for a while. Basically, I have worked in a few technology stacks over the years, but if I was to say what I've spent most of my development time with, I'd have to say Linux machines, Apache web servers, MySQL databases and programs written in Perl.

This is not exclusive: For a while, I did work with Windows on whatever their default server was, doing Active Server Pages with VBScript connecting to an Oracle DB, while being admin for a VMS system. I've written Python, Bash, R and JavaScript. I've tied hashes to Berkeley DB and used flat-file databases before I learned the next steps. Not that I ever got it into production, but I've written Visual Basic for Embedded to build an app on an iPaq in the days before .NET. And I'm sure there's more that I've forgotten. But the things I write for myself tend to be hosted on Linux, distributed over the web, served by Apache, storing to MySQL and generally written in Perl.

We'll call that my comfort zone.

The comfort zone is a good place. You have a job that works in the comfort zone, you know where to start. You likely have a "framework" in place that you can adapt to what the new thing is. The world can turn quite a lot while you sit in your comfort zone.

Aside: I generally don't use frameworks, because I know my comfort zone well enough that I can make separate things fast enough by adapting existing things that I'd rather do that than spend time trying to learn a framework. With Catalyst, I timed out twice before getting to the point I could do something with it. I'm better with Dancer, which is closer to the level of web programming I'm comfortable with, but the individual-pieces-of-CGI I work with doesn't lend itself to the web-applications world. Our lab still does puppies, not cattle. Consider that part of the comfort zone.

The first thing I missed was Python and Django. I was the last remaining Perl guy when most everyone I knew went to Python in the late 1990s and early 2000s. Then there was Ruby and Rails. I could probably get to iterative and recursive Fibonacci on both without looking too much at the documentation, but I've not spent quality time with either.

There are two problems with staying in a comfort zone. First is, the world goes on, and eventually nobody values your comfort zone. There are still places where they want Perl people, but other languages are higher in the desired skills list. The other is that it's a good way to burn out. Everything looks like X and you get tired of looking at X.

I think the hot spot for web development, the place I'd be if I was starting out right now, is still Linux, still Web, but nginx, MongoDB and Node.js. I like what I've seen of Redis and have used it in a personal project (and really, I've spent enough time with it to REALLY like MySQL; I still think in tables), but I think that MongoDB maps well with JSON (which works well with Perl hashrefs, which is the source of my love for it all, I won't lie) and is my fave so far of all the NoSQL databases I've played with so far.

So, I'm curious: if you were starting over today, knowing the computing environment and your own preferences, what would you start with? Why? Is this stuff you use right now?

2014/02/09

Time was, you authenticated via htaccess, and the server handled the details for you. If you gave the right password, you could access the materials in a directory, and if you didn't, you couldn't.

Now, we're authenticating with OAuth with Google or the like, and the smart stuff you write knows whether you're authenticated or not, but that kinda happens at the client level, and your server doesn't know whether it's authenticated or not.

If you're talking to the database to get content, there has to be some code there that says "OK, there's authentication, so we know Alice's content from Bob's, but if there's something saved to file, like an image — You could put your images in a database table, and I've done it, but in practice it's kinda stupid — that means that image is hardcoded, so anyone could browse around your authentication.

So, is the solution to have the images in a non-web-shared directory and have code determine whether it's OK to send the image or not? I've done that, too, but it seems like you stop the server from doing what it's good at. As efficient as you can make a program that takes in a user identifier, determines if it's acceptable, reads in a file and sends either a good image or a "that's not okay" image, that's always going to be slower than letting your server just send that image.

So, do I own that slowness? Is there another way that I just don't know yet? I'd put this on Stack Overflow if I even knew how to pose the question. Any thoughts?