The Down Side to HTTPS Everywhere

HTTPS Everywhere is a project of the Electronic Frontiers Foundation (EFF) that seeks to encourage the use of encryption on the web, including a Firefox Add-On that changes links to HTTPS for sites such as Twitter and Facebook. I've mentioned this before, and I still think it's a great idea.

Google has released an encrypted site, https://encrypted.google.com/, where your queries and responses are protected by encryption. But they don't support it for Images and Map queries. And I think I know why.

A browser can only have n connections to a website at one time. I think that's generally eight. This means that, if you have an image-heavy site, such as Google Image Search, you can only serve the page, the Javascript, the favicon, and five images, and you have to wait until that's done before you can start working on images six through thirteen, and you need to have all the images there before you can render. The trick is to have a Content Delivery Network (CDN), or a bunch of other servers to serve the images. That way, you can download eight at a time from each node and get 'em as fast as the network will let you.

But, if you have an HTTPS-served page, the browser considers everything not coming from that server as a potential breach, as well it should. This means that CDN is a huge problem. That, I think, is why Google isn't using HTTPS Everywhere.

Streaming Problem

I run Boxee on two machines. First is a fairly modern Vista-running machine, connected via wired ethernet to my modem/router/switch/access-point. The second is a Dell Optiplex running XP that was being retired from university use when I got it, connected to the network with a Netgear USB WiFi dongle.

I have demonstrated that I can serously hinder the ability of the second to stream, simply by surfing the web via my netbook. I don't know which part of the chain is the weak point, and even the strong points are not strong on a PC that old. My friend Patrick says that running CAT6 through the home is kinda worthless for most people because home broadband bandwidth are and will be much smaller than even older WiFi protocols. I understand this and believe it, but problems like this make me wonder.

Do People Really Want Geolocation?

Reading 2011: The Year the Check-in Died on ReadWriteWeb. Not too sure what to think of it. Of the people I know, only two people who live in the same city as I am have used any of the check-in services I've dealt with, and for neither was it often enough for the serendipity thing ("Hey! You're at the mall, too? How are you doing?!") to happen. I have yet to find another person who wants to share their lat and long via Google Latitude with me. And, I must admit, there's only a small set of people who I'd do that with.

The author lists four reasons why people check in to places — Finding people near you, Rewards, Remembering things and Personal Branding — then proceeds to explain why this is trivial and not lasting and nothing to base much on. There's just not much in it for people to tell others where they are.

But I want to know where I am. Or, rather, I want my desktop, home of my alerting crontabs, to know that I'm near my work, where it knows to alert me like this, or near my home, where it knows to alert me like that, or somewhere else, where it can alert me with a whiffleball bat. Or something. I don't need my friends to know where I am. I don't really want to tell advertisers or employers where I am. But it would be a great boon to me if I could tell where I am. Screen-based alerts are useless if nobody is at the screen.

Be aware that Xerox PARC, the Palo Alto Research Center for the Xerox Corporation, invented computing as we know it. One of the things they had were badges that could tell where you were in the facility, so if someone called for you, the telephone nearest to you would ring, no matter where. That's great and all, but today, everyone has their phone on their hip, so standard wired phones are more and more useless and less and less used.

When I used to work for the medical clinic, I tested badges that could unlock a computer when you got close, and unlock it when I walked away. It seems like it would be easy to write authentication modules that would allow the same thing with Bluetooth, but I'd rather have GPS rolling than Bluetooth most of the time.

There's a Latitude API, but I haven't done more than poke at it. But I suspect this sort of thing will be the real use of location-based computing.

Proper Uses of Social Media: Conferences

I heard a story once, about a decade ago. A guy comes in to present on Deep Technical Subject A to a conference room full of people. They all had laptops, and the guy thinks, more and more as his talk goes on, that he's dying, that they're all there by fiat and everyone's just sitting and browsing and hoping for the presentation to be over.

He goes through his slides, giving it his best, and gets to "Are there any questions?"

And the questions are good. Well thought out and to the point. Turns out that everyone was on IRC and discussing the points of the presentation as he presented.

We still have IRC, but you can still wear bow ties and spats if you want. Today's thing is Twitter, and many conference suggest a hash tag by which you can follow and discuss the current goings-on. I've seen it suggested for a few things, and I've been disappointed in the past. I can only hope that it's a flyover-country thing and bigger events in bigger areas have more vibrant tweets. Purdue's BoilerWeb 2011 had some great discussions on the #bweb11 hashtag, and there was some nice interaction at Indiana Linuxfest.

I can understand if people don't want to dive into a stream of people mindlessly photographing their meals for everyone to see, but here is a case where it really makes sense.

Podcasts and Synergy

Image from vanRijn

I've put Google Listen on my phone, listening to podcasts while I drive. One of them is Spectrum from the IEEE, and the one that came on my player was about the Kinect. I have never used the Kinect, as I'm not much of a gamer. Sometimes I'll sit down and play the Wii with the boys, but I have used it more as a Netflix player. So, I'll never use it as intended.

But the interview is not about intention. It is about capability. The Kinect is able to multiple identify people, both by voice and by vision, in noisy, chaotic environments. People are already starting to hack the Kinect to allow Minority Report interfaces and the like.

The second thing I heard was on Hacker Public Radio, which I started to get into after Indiana LinuxFest. The podcast itself is a pre-interview discussion between KDE spokesman Aaron Seigo and Jonathan Nadeau of Frostbite Systems.

Accessability questions have been floating in my head recently. There's lots of buzz about Section 508 in the circles I float through, enough so I've attended two compliance talks in 2011, and my wife has been trying to be a productive person while having severe pain in her right elbow and forearm that keep her from being able to type. She's been playing with speech recognition software, finally trying the Windows 7 native setup that came with her new laptop.

But honestly, when thinking about accessability, I wasn't really thinking about accessibility. I think that there's research at the end of the line for this train of thought that will serve to help accessibility, but it isn't foremost in my head here.

I was driving. I was thinking about cars.

As I think I've mentioned, I've been looking at some travel applications. I tend to have either Listen or a media player of one sort or another playing when I drive, rather than CDs or even worse, radio. (I have only one objection to Amazon Cloud Player, which is that it wants to run only on WiFi, and by and large, I want to use my phone as a media player when I'm mobile, away from WiFi, but maybe the coming of 4G or the next software fix from Sprint will fix that.) I have a TomTom GPS showing my location and speed and I sometimes use Sprint or Google for directions, too. Also, I've been looking into Vlingo, which gives a voice interface to phones. I noticed a bug, hopefully fixed soon, where I hit the Talk Now button while listening to a podcast, and told it to call my wife. Normally, when you tell it to call, it shuts up the media player, Listen included, but here it didn't. So, I'm trying to pause the player and/or mute the player, while on the Interstate.

I know. I know. The point of the exercise is to keep from having this sort of attention-sucking frustration from occurring while I'm driving, because I don't want to hurt myself, my stuff, or other people and their stuff, pretty much in that order. Haven't been too keen of Vlingo since. It's cool enough, but you shouldn't have to press a button while driving to say "I wanna talk now".

And I don't think the Vlingo is alone. Watch just a few high-end car reviews on Top Gear and you'll know that the UIs for even fancy cars are crap.

Ultimately, to do a driving interface right, you have to assume that there will be no vision at all. Most of the things you do while driving (besides avoiding obstacles and other drivers) occur without vision: you use your sense of touch to feel the vibration and you hear the engine to know when to shift. You see the red Check Engine light but you take it in when it starts to sound or feel funny. You can even get away with not often checking the speedometer by staying at a similar speed to your fellow drivers. If you're going to do much computing while driving, it'll have to be via voice. And once that shows up in high-end vehicles, that browser is going to rival Firefox and Chrome and IE at the top of the browser food chain.

(As a pure aside, I think Opera will go there. I don't like Opera and haven't for over a decade, but I know I'm biased on the subject, but it seems like a place that Opera would go, more than anyone else.)

But as we needed the keyboard and then the mouse to get the WIMP interface for computers into the office and the home, we need to rock a voice interface to get the computer into the car. Which is where the Kinect comes in. I kinda think that the car will be a big docking station for future computers, as seat settings and address books and the like are highly personal but a great deal of hardware is there for anyone who sits down. Kinect-based technology would be necessary to distinguish between the driver, the passenger in the front seat who talks with his hands and the loud kids in the back seat. The recognition between conversations between user and computer and conversations between driver and passengers is crucial, and one I think that Microsoft Research and Kinect are closest.

There's going to be a small LED screen for the backup camera in the New Car's rear-view mirror (and some cars of today already have it) and a Kinect as well. Of this I am sure.

Comments on BoilerWeb 2011 #bweb11

I took a paid vacation yesterday and attended Purdue's BoilerWeb conference. I had a blast. I saw old coworkers and classmates and bosses and had a good ol' time. 

Last year, evidently, it was a one-track thing, but interest was such that there were two tracks. This leads to some minor minor complaints. First was the lack of electricity available. For the first track, this was remedied by an attendee (who shares a job and workspace with one of the organizers) bringing in some power strips from the office, but the orientation of the other room and the modular setup of the floor meant that there was only one jack available at the back of the room. If you're going to follow along, liveblog, tweet and such for an all-day event, you need available power.

But that is my only complaint, and I can only categorize that as a minor gripe. And unlike the Indiana Linuxfest, I felt the printed and online scheduling information for this conference was top notch. (Not a slam, ILF guys. Just a pointer on what can be done better next year.)

First pair of presentations were Know Your Limits,  covering load testing, and jQuery Plugins. I felt that jQuery Plugins was much more in line with my needs. I write Javascript. I try to write jQuery, which I learned about from a co-worker, but I'm much more the JS guy now and I mostly have experience with my own code, so I don't know the best practices, and have a great tendency to spend time writing my own stuff instead of using used and tested existing plugins. Plus, as I figured out, I kinda clog up the existing namespace, which isn't good. The presenter was very effective, and funny. I really liked his intro use of "Final Countdown" by Europe and high-fiving much of the audience, cheesy at it was, and the presentation showed him eating his own dogfood, so to speak.

Next choice was Introduction to Responsive Design vs NanoHUB. I've know people working with NanoHUB for a while" and while I respect them and their work, it is really orthogonal to anything I expect to ever work with. Meanwhile, Responsive Design as presented was all about writing once and presenting from everything from the desktop to the smartphone with three simple design aspects: Flexible Grid, @Media Queries, and Flexible Images. The coolest part of that, the part that works best with me as a developer, is @media queries. Traditionally, that's used to differentiate different style sheets based upon whether you're looking at it on the screen or printing it. Now, you can put that into the stylesheet and not have to define it in several pages, and make distinctions based upon windows size IN THE CSS. So, one stylesheet. That's the win. 

Next was Introduction to Content Strategy, which in a way is fundamental and in a way is meta to this sort of conference. "Content is king" but we spend more time and more money creating the context than the content. We create a framework and say its done, but it isn't done. 

My first degree was in Journalism and Mass Communication, and as part of the degree, we were required to get an internship. There was a requirement that set our program apart at that time: it had to be a paid internship, because if the internship was unpaid (as the majority of journalism internships were), there was the assumption that you would not be used for real work and thus you wouldn't learn anything. Years later, as I was starting Computer Science, there was a course where they brought in people from industry to present what you could do with a CS degree. One of the first presenters mentioned that he had internships and that you should send him resumes. I asked if they were paid internships. Imagine if I had asked if we would be breathing oxygen and using electricity to light the office. That's the kind of response. As a society, we do not value the content creators like we value the interface creators. This talk kinda covered that, and offered some means to run the process to make and keep your content current.

There was a presentation on Food For The Heart, which had Ruby on Rails and data munging aspects I was curious about — need to create a test server and learn some RoR stuff — but instead went to the Class Hacks presentation on Mixable. Best way to describe it is kinda Facebook for Classrooms, and it does connect to Facebook. By the tweeting of people who saw the "Food" presentation, the main take-away is that Fat Secret has a nutrition API. This is something I should take a look at. What has my curiosity is Mixable, which I've started to get into for the community of it. Also, a little bit of inspiration in terms of design. I do web design like a web developer: without a real eye for aesthetics and with a tendency to implement new aspects of CSS only until I understand all the controls and get bored. Anyway, Mixable is cool so far.

The talk on Rapid Development in Groups was like being told to eat my vegetables. I know I should start using revision control. I know I should look into MVCs. I know I should eat my vegetables. Being told is not as useful as one might think. The talk Design Patterns Every Web Developer Should Know sort of fit into that. Design Patterns is a subject I have heard about, but don't really understand well enough to know why I should spend my valuable time diving deeper. I've started to look into the three presented, but the presenter had time and audience to dive further into each of the three, so the opportunity was a bit wasted, to the point where "Understand the Facade patttern" has joined the vegetable list, too.

All in all, I think I'm energized and more curious about the possibilities of the newest generation of web technologies. Great conference, guys. Make it better next year.

Why does it all have to be so terribly loud?

CSS Table Printing Problem

So, I have a page that holds lots of tables. These tables are all the schema for a database I use for a project. All 31 of them. The page is basically the DESCRIBE table for each table. We're talking usually about 4-8 rows per table. A main reason for creating this page is so we can have the schema taped to the wall.

The problem gets to be that of widows and orphans. In layout, a widow is the last line of a paragraph occurring after a page break, while an orphan is a first line of a paragraph occurring before a page break Or, in this case, tables. And it is considered to be bad.

A widowed row.

Using THEAD and TBODY allows the browser (in this case, Firefox on Linux) to repeat the head of the table, which is nice, but one row of the table isn't enough.

Clearly, these are short enough that forcing the browser to keep the table together through a page break shouldn't be too wasteful, unlike if this was a SELECT * FROM table on a table with hundreds or thousands of rows. But it seems this isn't possible with CSS. CSS has page-break-before,  page-break-after and  page-break-inside, but they are insufficient. You can force a page break before or after an element, but that's not it. If you can fit seven or eight tables on a page, why would you not put them on a page? And there's three options for  page-break-inside: avoid, auto and inherit. The choice of auto translates to "break it anywhere", while avoid has all the practical use of "break it anywhere" and inherit simply means "do what the parent did", which of course means "break it anywhere".

There are CSS properties for widows and orphans, but they don't seem to work for tables. Well, less with tables than tables wrapped in DIVs.