Introduction

Ok, so this post is only here in the hopes I’ll actually win something.

O’Reilly Books has a promotion where a random winner will receive up to $500 of books on their wishlist, provided they post the list somewhere online. You can probably see why this is here then!

The List

Programming the Mobile Web ($50)
Palm webOS ($45)
MongoDB: The Definitive Guide ($40)
JavaScript: The Definitive Guide: Rough Cuts Version, Sixth Edition ($50)
HTML5: Up and Running ($30)
Building Android Apps with HTML, CSS, and JavaScript ($30)
Building iPhone Apps with HTML, CSS, and JavaScript ($30)
HTML & CSS: The Good Parts ($35)
HTML5 Canvas ($40)
jQuery Cookbook ($35)
Learning Android ($35)
CSS Cookbook, Third Edition ($50)

(OR “The Post In Which I Conflate Programming and Philosophy” OR “The Programmer’s Existentialist Crisis”)

I woke up this morning to read Dmitry A. Soshnikov’s tweet:

While this seems like good advice for aspiring programmers, I can’t help but think what this means for those who will buy into this. Us programmers have a keen ability to sit and focus on problems for extended periods of time, usually to the detriment of everything else around us. From the perspective of “real life”, we might as well be sitting in a basement somewhere playing World of Warcraft. Sure, programming is more productive, profitable, and surely not brainless, but at the end of the day we could still only be sitting in a basement somewhere. What I mean to say here is that we’re not actually living our actual lives doing these things.

I realize Dmitry was only talking about learning another programming language for professional life, but for me and so many others, professional life is not easily separated from personal life. We don’t just work during the week during work hours. We can’t just turn off our minds and stop thinking about it when we go home. I end up thinking about programming or web design puzzles in my leisure time and on weekends, largely because I enjoy doing so. But when I see something questioning whether I should be devoting even more of this time to learning another programming language, I think about what I could be doing instead. Put another way, I think about what is missing and neglected in my life, and how those things will remain missing and neglected.

Socrates famously said “The unexamined life is not worth living”. He, along with those who followed in his immediate footsteps (famously, Plato and Aristotle) were concerned with how us mere mortals should live our lives, and more particularly how we should lead good lives. The sad fact about (western) philosophy is that it’s turned into a shadow of its former self, now plagued by millennia of self-doubt and failed grandiose systems. But it seems the original Socratic intention of finding how to lead a good life is still an admirable goal, even if we disagree on how exactly to achieve it.

Socrates also had a bit to say about those seeking to be experts in their field, and he couldn’t resist getting in a jab at his wife in the process:

It is the example of the rider who wishes to become an expert horseman: “None of your soft-mouthed, docile animals for me,” he says; “the horse for me to own must show some spirit” in the belief, no doubt, if he can manage such an animal, it will be easy enough to deal with every other horse besides. And that is just my case. I wish to deal with human beings, to associate with man in general; hence my choice of wife. I know full well, if I can tolerate her spirit, I can with ease attach myself to every human being else.

Yes, Socrates essentially just compared his wife with a horse. A wild horse, to be exact.

I’m unsure if this translates well into learning programming languages. Does this mean we should learn the worst languages first, so that the rest of the languages we learn will be comparably easy? I hope not, that seems like quite a lot of wasted time. But I certainly agree that the first languages we learn shouldn’t be the easiest. This might only make us frustrated in the long run. So perhaps we can learn something from Socrates’s quote after all, if taken with a grain of salt.

So should we still strive to become experts in our field? I believe that’s an admirable and acceptable goal, but it shouldn’t be our main goal. We should first be concerned with leading good lives. I myself have a LONG way to go on this point, believe me.

I’ll surely learn another programming language, but not for its own sake, unless my life is in reasonably good order.

This is just a fun little video demo into the inner workings of today’s Google Doodle. Nothing you can’t do yourself with Firebug or Web Inspector (built into WebKit browsers such as Safari and Chrome). But I liked this doodle so much, I wanted to talk about it!

Disclaimer: I know the difference between HTML5 and CSS3, but I’m not much one for pedantic nomenclature (however, I am apparently supportive of pedantic words like nomenclature). For the purposes of this video, webkit transforms and transitions are part of HTML5.

EDIT: Apparently I missed that the doodle has accelerometer support for devices that support it! Confirmed that it works on my MacBook Pro in Chrome.

Introduction

A little while back this post made the rounds, which took us on a journey through some of the new features introduced in the browser in Android 2.2 Froyo. Among the most overlooked features are the file upload functionality (you can upload photos from your browser now! But we’re still waiting on iPhone to support this…) and a little-known JavaScript addition to the Browser Object Model (BOM) in the form of navigator.connection. Let’s take a peek at its contents:

// contents of navigator.connection object
{
  "type": "3",
  "UNKNOWN": "0",
  "ETHERNET": "1",
  "WIFI": "2",
  "CELL_2G": "3",
  "CELL_3G": "4"
}

This is data taken from a Nexus One running on a 2G network, so you can see that the type is set to 3, which corresponds with “CELL_2G”. In other words, this phone runs on a slower network, so from a performance perspective, you probably want to consider delivering a lower-bandwidth experience.

So how exactly do we target this?

The code

The purpose of this code is to first find the connection speed, and then add a class to the html element based on this connection. The goal is to be able to target these connections with CSS, so the right content is delivered to the right connection:

.highbandwidth .logo   { background-image:url('logo-high.jpg'); }
.mediumbandwidth .logo { background-image:url('logo-medium.jpg'); }
.lowbandwidth .logo    { background-image:url('logo-low.jpg'); }

And here’s the JavaScript:

var connection, connectionSpeed, htmlNode, htmlClass;

// create a custom object if navigator.connection isn't available
connection = navigator.connection || {'type':'0'};

// set connectionSpeed
switch(connection.type) {
  case connection.CELL_3G:
    // 3G
    connectionSpeed = 'mediumbandwidth';
  break;
  case connection.CELL_2G:
    // 2G
    connectionSpeed = 'lowbandwidth';
  break;
  default:
    // WIFI, ETHERNET, UNKNOWN
    connectionSpeed = 'highbandwidth';
}

// set the connection speed on the html element, i.e. <html class="lowbandwidth">
htmlNode = document.body.parentNode;
htmlClass = htmlNode.getAttribute('class') || '';
htmlNode.setAttribute('class', htmlClass + ' ' + connectionSpeed);

Give the user control!

Just as it’s a good practice to give the user a link to the full desktop version of the website, if you’re going to deliver different content based on different connection speeds, then it’s highly advisable to give the user full control.

So give them control! You can provide something like the following:

Open Web Camp II at Stanford today was a blast! Lots of information. Plenty I’m already familiar with, but also lots I learned.

I woke up late, only to see people tweeting about the conference (doh!), so I missed seeing Molly Holzschlag. But I arrived just in time to see…

Estelle Weyl: “CSS3 Implementable Features”

Estelle Weyl (@estellevw)

Estelle’s talk was about what features of CSS3 are available to use right now. She covered all the usual: border radius, text shadow, box shadow, tilted images, etc. And she showed off Paul Irish’s css3please.com, which greatly helps implement these cross-browser, with even the filter hacks required to pull it off in IE! (no word about the performance hit of these IE hacks, which I’m sure I’ve read about somewhere…)

One of the cool new things I learned was that you can use CSS shorthands to declare border-radius (rounded corner) values. So instead of this mess (courtesy of border-radius.com):

-webkit-border-top-left-radius: 1px;
-webkit-border-top-right-radius: 2px;
-webkit-border-bottom-right-radius: 3px;
-webkit-border-bottom-left-radius: 4px;
-moz-border-radius-topleft: 1px;
-moz-border-radius-topright: 2px;
-moz-border-radius-bottomright: 3px;
-moz-border-radius-bottomleft: 4px;
border-top-left-radius: 1px;
border-top-right-radius: 2px;
border-bottom-right-radius: 3px;
border-bottom-left-radius: 4px;

All you need to do is this, which is equivalent to the above (disclaimer: I’m not sure about the compatibility of this shorthand!):

-moz-border-radius: 10px 20px 30px 40px;
-webkit-border-radius: 10px 20px 30px 40px;
border-radius: 10px 20px 30px 40px;

Or if you get bored of doing a perfectly rounded border radius, you can also do elliptical border radius (again, I’m unsure about the compatibility!):

-moz-border-radius: 20px / 10px;
-webkit-border-radius: 20px / 10px;
border-radius: 20px / 10px;

Matt Henry: “Going Mobile”

Matt Henry (@greenideas)

I’ve worked closely with Matt at Yahoo! Mobile for the past year, so not much was new for me. It seemed that the audience really dug the talk though (lots of questions were asked!).

Essentially, Matt explained that you have to make at least two different versions of your website: one for feature phones and one for smartphones like the iPhone, and with the help of something like WURFL, detect the phone and direct the user to the appropriate site.

Matt also emphasized that feature phone browsers are terrible, much worse than IE6.

As part of a response to someone’s question, Matt talked about the idea of feature detection on smart phones, essentially saying that by the time you’ve sent the JavaScript feature detection to the device, it’s already too late, and in some cases might end up crashing the browser (for feature phones that have an extremely small page weight such as 9KB). So for now it looks like user agent sniffing on the server-side is the way to go.

And there was a brief shoutout for Yahoo! Blueprint, which renders a website across thousands of phones.

Victor Tsaran and Todd Kloots: “Accessibility 101″

Victor Tsaran (@vick08) and Todd Kloots (@todd)

Before joining Twitter, Todd Kloots spent some time with Victor Tsaran at Yahoo! on accessibility.

In this talk they went over common misunderstandings and showed that even today, big companies such as Digg.com are still not investing in making their site accessible.

This was a pretty high level overview of basic accessibility, including an introduction to screen readers and ARIA attributes.

Here’s some of the stuff covered:
-making forms accessible with fieldset and legend elements and linking captions to their inputs.
-adding alt tags to images even if blank (so the screen reader doesn’t announce the entire URL)
-the title tag doesn’t make things more accessible, whereas the alt tag does
-screen readers obey display: none and visibility: hidden and that to hide something from normal users you have to position it offscreen (with negative left or text-indent).
-how to make basic tables accessible by taking advantage of table summary and caption, as well as putting tables headings into the <thead> element.

I’m still trying to absorb it, but Todd also mentioned that a simple anchor tag for a button didn’t semantically make sense, and that it was more semantic to have a span wrapped around a <button>. I guess I either don’t understand fully or I just disagree, since a <button> appears within a form and sometimes it just may be a cleaner solution to use a simple anchor tag. I guess I will need to look into this more.

Joseph R. Lewis: “Refactoring for Mobile”

Joseph R. Lewis (@sanbeiji)

This talk was basically a live demo of implementing CSS media queries in a WordPress installation to make an iPhone-friendly version of the site. There was a good use of the viewport tag, media queries, @font-face, text-shadow, box-shadow, border-radius, etc.

One surprising thing I learned was that apparently Mobile Safari recognizes border-radius without the webkit prefix? I’m going to follow up on this.

Dirk Ginader: “5 layers of web accessibility”

Dirk Ginader (@ginader)

Dirk is another Yahoo! (we’re everywhere!) whose presentation was also about accessibility.

As web developers, we’re already familiar with three layers of the web:

-HTML, responsible for content
-CSS, responsible for presentation
-JavaScript, responsible for interaction

Dirk introduced another two levels:

-CSS for JavaScript: special styling for when the full-featured JavaScript is available (this can be used by having JS add a “js” class to the document, and therefore writing CSS rules with “.js” in the front)
-WAI-ARIA: special HTML attributes to help define roles, landmarks, allow the developer to give instructions directly through the screen reader, etc.

Also a few more points:
-use the JavaScript focus() method for events (alerts that are injected at the top of the document and are otherwise ignored by the screen reader, windows that open and close, etc.)
-:hover CSS pseudoclass is for the mouse only.. be sure to also use the :focus pseudoclass! (my note: this is also important on mobile, for touch devices!)

Summary

Overall a great day. The food was pricey but good, and the whole event was free, so I can’t complain! Nice event, I just wish I could’ve seen the other talks in the other tracks!