Sunday, October 28, 2012

Read Later on Google+

In a nutshell: I use Google+ to solve the 'read later' problem.

Reading things later has become a problem for me. Someone at work emails me a link, following up on a hallway chat about something I'm genuinely interested in and would actually like to read about, but just not now. So I close the email, and the link - unvisited, and now representing unread content - haunts me like a tiny ghost.

Or where my wife, God bless her cotton socks, sends me a link about the place we're thinking about staying in up in Noosaville before Christmas, but right now all I want to do is smash out some JavaScript, and I'll get to that other thing on Saturday morning when I'll be in the mood. Promise.

Or if I'm on the bus, 500 metres before my stop, and I follow a link from a tweet and the article just about loads before I have to alight (love that word) from the bus. The aricle looked interesting, but will languish in a mobile Chrome tab holding pattern unless I do something with it.

Flickr photo
FlickrPiles of books, by NettyA. My Read Later list is building up like the piles at this second hand book shop in Seoul.

Recently, Scott Hanselman wrote an interesting (as ever) piece about pushing what he calls "long-form reading" onto a Kindle for his deferred reading pleasure. The Kindle part is just incidental here: as long as the articles are saved "in a way that will encourage you TO READ THEM!" (his shouting) then that's all that matters. Well, maybe not incidental. I mean, Kindles are obviously designed for reading things, but not particularly for web pages that you're not interested in reading straight away. Instapaper is, though. Same with the "social bookmarking" site Delicious, in a way. So you can cook up an If This Then That recipe to combine your bookmarks with your Kindle automatically, achieving hitherto undreamed-of productivity. As long as at some stage you actually read the articles of course. They have to end up somewhere you're likely to see them. For some people like Scott H, the Kindle is something that they reliably pick up on the weekend, or take with them to the park, on a plane, into the toilet, the bus, anywhere they catch up on their reading. Somewhere away from the desk, where they're relaxed, and ready to absorb content that's longer than a tweet or an email.

But it seems to me there are too many moving parts here. Recipes scare me. They can go wrong. IFTTT no longer works with Twitter, for example, so any recipes cooked up with twitter as an ingredient just got burnt in that particular oven.

There's also something else that stops me from using a Kindle, but that may not affect you. I'm a web developer: I'm actually interested in seeing web pages as they appear in the wild. For that reason I've never been interested in Instapaper, Readability, or any of those things. I don't consider RSS to be like those though - it makes entire sites machine-readable, so RSS gets a pass.

It takes a lot to deter me from a web page: video that plays automatically, without prior warning, is one of those things, by the way.

Google+ Read Later circle

Read Later solved as a Google+ circle

So I see a simpler solution. Use Google+. Almost all content pages have the +1 button by now. The dialog that appears usually allows you to choose which circles you share with, so I just share it with a "Read Later" circle (see the green circle above) which I created to be my private repository of links. It's not really a circle in the conventional sense, since I'm the only one in there. The point is it quietly stashes the links, and I can dial down (red circle) the degree to which these links show in my Home Stream.

Google+ is ultimately just a website, so your saved web content stays on the web. Up where it belongs. When you finally, finally, read the damn article you put aside, you can just delete the post, or more usefully, share it at that stage with the Google+ world. You can even share your whole Read Later circle (blue circle), although that would probably be interpreted as "Hey, here's stuff I haven't read yet, and I'd like to add it to your pile of unread material too :)".

You can also add the official Google +1 Button Chrome extension which shows the full +1 sharing dialog just to be sure. Notice I didn't say "to be sure" twice there. Some sites, like The Guardian, despite having Google+ buttons on their articles, disable the usual dialog, and just show links to their G+ content. And some only allow you to +1 something, that's it, without any of the circling or commenting. But in those cases you can just browse to G+ (I usually have it open in some tab anyway) and slap it in manually.

C'mon Guardian, don't wreck the Google+ pop-up. Let me selectively circle stuff.

And the main reason this all works, the reason this is simple, and I actually remember to read these put-away articles, is because the Google+ client is on both of my Android devices, even on my old iPhone. It's on my main desktop computer, and my work one, in the form of the Google+ website. No extra software required. I don't need the Evernote client, or the Delicious one, or the Instapaper or IFTT one.

Smug? Undoubtedly. Keeping it nice and simple? Yes. Total Google+ fanboy? Oh yes.

Saturday, October 20, 2012

The 21st century belongs to JavaScript

This century is going to belong to the Chinese and to JavaScript. You should learn one or the other. In this post, I look at a good way to get started with JavaScript.

Let's face it, you probably need to give the chaos called your app's JavaScript code some order. If your app is in an entropic state, in a state of high disorder, you need to stabilise it. How can you possibly do that if you don't know any decent JavaScript patterns? You probably want to start using namespacing and modules, for a start. But how can you can do that if you don't know the basics of JavaScript functions?

Reading 'JavaScript Patterns' by Stoyan Stefanov, I realised there's too much stuff in here to remember. Too much. You have to write it down, blog it, or otherwise come up with some way of memorizing the information so that the book is actually useful to you. Obviously, using the patterns themselves in your code is the best way to learn something like this, but unless you have some functions that badly need currying and so on, it can be impractical to just start baking ideas from a book like this into your working code. So where do you start then?

Flickr photo
"DMP-FF005 CHINESE ARMY", by damopabe. The Chinese are going to rock the party hard in the 21st century, everyone knows this.


The chapter on functions is a good place. Javascript is object-oriented, but without classes, which seems a paradox if you mainly work in C# like I do. So, forget classes, and learn your functions if you want to learn Javascript.
In general, when you think of a function in JavaScript, think of an object, with the only special feature that this object is invokable, meaning it can be executed.
Reading this chapter, I was struck by how many different, but only slightly different, ways there were of doing the same thing: making a function. So how well do you know your Javascript terminology? What's this?
    alert("Who am I?");
That's right, it's a plain ol' function declaration. Specifically, an anonymous function declaration. If you had named it (because, let's face it, it's going to be difficult to use that declaration as it stands) by making the first line function MyFunction(){ then it would be a named function declaration. If you assign the function to a variable,
var myFunction = function(){
    alert("Who am I?");
then the whole thing forms a function expression, complete with semi-colon at the end. Since it's still unnamed, you probably know it better as an anonymous function. Now, going back to the first example, the "Who am I?" anonymous function declaration (see how I'm cunningly using repetition to drill the names of these functions, both function declarations and function expressions, into our memories?) seems to be inert and useless, except if you wrap it in () and put a () after it, in which case it stops being useless. In fact, in that case it takes immediate effect because - it should come as no surprise to find out - it becomes an immediate function.
    alert("I happen immediately");
What prompted me to pick up 'JavaScript Patterns' (it's actually an ebook but I feel in my heart that you can pick them up just the same) in the first place was the befuddlement I felt on my current project at the absolute effin' proliferation of JavaScript files: 3rd-party behemoths like jQuery and Modernizr, minnows like jQuery File Upload, and our own proprietary code. Cracking open some of the JS that the other guys in my team had written, I realised I had little idea what I was looking at much of the time. Like dark matter and dark energy, there's dark code. Bad neighbourhoods, I call them. Parts of the app you don't want to find yourself in. I mean I could see that there were a bunch of functions in a DateHelper file, for example, all doing sterling work like converting a day to a date and so on, but why they sometimes were created in an object literal, and sometimes using a constructor function I couldn't tell. What's that? Constructor function, you say?
var Thing = function(message){
    this.message = message;
    this.displayMessage = function(){
var myThing = new Thing("Note the *new* keyword");
Now, I'm not so artless as to believe that there's always great thought behind every piece of production code, especially - like I say - given that this is after all JavaScript we're talking about. But not knowing, at a high level (is this function part of another object? When does it run?) what you're dealing with puts you at a severe disadvantage. And so I decided on a top-down approach to start with - simply to learn what things looked like. Yes, you should learn everything, but you can't because you don't have enough time. So you have to start somewhere. I have any number of free ebooks available to me nowadays - I suppose most devs do too - but I'm realising that they're all useless unless I read them. And I can't read them all if I read them all.

In this post, I'm avoiding talking about how or why you'd use one type of function over another. Obviously, you can read 'JavaScript Patterns', or any number of books, sites, or posts to learn about that. That skill comes with experience, with recognising patterns, and knowing how and where to apply them. I'm talking about doing what you might do when learning astronomy, chess, or bird-watching. You start off by simply being able to identify the things you're looking at.

Now obviously, when it comes to programming, you're supposed to go deeper than crudely identifying objects based on a superficial recognition of coarse features. But this is Javascript we're talking about, people. No-one learns this stuff. Most "senior" developers I've met in the last few years, people who pride themselves on knowing arcane facts about C# and SQL Server, are just blue-arsed ignorance monkeys when it comes to the natural language of the browser, JavaScript. Why is that? No idea, it just is. They must think it's a "junior" language, beneath their dignity to learn. Who cares? And the usual disclaimer in these cases about including myself in that list applies here too, it should go without saying.

So, it might seem like there's not a lot to learn here - immediate functions, custom constructors vs object literals, a few other slight variations - and indeed there isn't. But without knowing those building blocks, the important patterns that you're going to need to learn soon like callback patterns or using Modules to structure your JS are going to expand away from you quicker than your ability to reign them in, until in the not-too-distant future their light will never be able to reach you, leaving you surrounded by an expanding sphere of obscurity. Much like the fate of this galaxy in fact.

Wednesday, October 3, 2012

You need a spare mobile phone

Don't rely on The Man to hook you up when your mobile phone breaks. The Man don't give a damn.

I had a scare a couple of weeks ago. Let me tell you about it. On Sunday I had to pick up the kids from MacDonald's in the afternoon, so I set off for a pleasant 15-minute jaunt through the bushland between where I live and Logan Rd. Naturally I took my phone with me, a 4-month old HTC One X. I thought I'd catch up on some podcast or other while I walked there. To my consternation however, as I strolled along the path that goes through the Roly Chapman Bushland Reserve I found I couldn't get the phone to turn on. Holding the top button down made it beep and vibrate, but there was no screen activity. By the time I'd crossed the creek and reached Logan Rd. I had to concede that the phone was as dead as a doornail.

Or was it?

Later that night when I had a bit of time to investigate, I discovered to my great excitement that the phone had actually been on and working all the time, but that the backlight/screen was the source of the problem. I could see the icons, etc, ever so faintly, far too weak to be able to actually use in any way. But however it might be possible to describe it as technically working, I was going to have to bring it back to the nearest Optus shop tomorrow.

Flickr photo
"The spare tire", by jmschrei

And so had begun my Period of Inconvenience. Over that weekend I had found out the One X was banjaxed I wouldn't really have used it much, except for a check-in or two in New Farm Park and the Powerhouse on the Sunday afternoon. Now however I was staring into the abyss of a working week without a phone, without a smartphone, and immediately suffered the absence of my usual podcasts on the cycle to and from work. No Guardian Science Weekly, no Skeptics' Guide to the Universe, no This Week in Google. You know, I don't want to sound helpless here but there's a difference between starting your day listening to Alok Jha talk to Craig Venter about artificial life and listening to utes on the freeway.

So, if your phone didn't work, and you got to work, what might you do? Well, you might log in to Gmail, seeing as how you can't access your personal email on your phone, right? But you wouldn't be able to. Know why? Hackers, that's why. Ever since I read Jeff Atwood's great post on email two-factor authentication, I've set Gmail up to send an SMS to my phone whenever I try and log in on an untrusted - read work - computer. Can you see this one coming? On Monday morning I went to log in to my Google account on my work computer only to be challenged by the 2-factor verification code screen. Simultaneously, sitting on my desk like a little blind puppy my HTC phone alerted me to an incoming SMS, one sent all the way from Mountain View, CA, with a 6-digit authentication token. But it just couldn't show it to me. Because it was fucked. Aw barnacles!

Fake it with 2-factor

That's when it hit me just how inconvenient this period of inconvenience could be. I knew I could log on to my Google account at home, but it might not be long before my home computer decided to recycle the 2-factor token it keeps for 30 days, being a trusted computer, and then I'd really be snookered. Nor did I think I could even switch the 2-factor off, since I would surely need to answer an SMS challenge before being able to change it. But actually, it turns out I needn't have worried. You can change it from SMS to a voice call with no interim challenge, after which a nice lady calls you and tells you the code without you having to try and read an SMS. As an aside, this is a handy way of faking an incoming phone call. Just set up voice call 2-factor authentication on your google account, and try to sign in on an untrusted computer. The robot lady will call you and you can proceed to impress listeners with a one-sided conversation (as long as you commit the actual 6-digit code to memory first) saying impressive things like "Two hundred grand? I hardly think so!"

I have to admit to walking in to the Optus store on the mall that lunchtime with an optimism I just hadn't earned. There was simply no reason to expect I'd walk out an hour later with any satisfaction. And sure enough, I didn't. Like an airhead, I thought they'd have a deep and dirty supply of smartphones to choose from while they ministered to my broken HTC. That's if they weren't able to execute some secret button combination and restore life to my moribund phone. Well, they didn't. In fact, the guy's suggestion was to buy an interim phone. That's right: at the same time as they acknowledge that the phone is broken through no fault of your own, they will tell you to buy one if you want a phone for the duration of the repair period. $190 was the cheapest he could offer (smartphone, that is, and they would discount $50 of that). Still, $140 was the going rate that lunchtime for a replacement phone. Did I mention that there was no suggestion that it was in any way my fault that the backlight was defunkt?


Flickr photo
"Prof Brian Cox", by Joe Dunckley. I bet he has a spare mobile.

And that's the point of this post - don't throw away your old smartphone. Don't give it to your wife, kid, struggling brother-in-law, a mugger, or your Mum. And don't recycle it for Africans. Keep it - you'll need it. That night, steeped in humility, I rooted out my old iPhone, the one I had given up on because it had begun to slow down somewhat and the battery had begun to run down too quickly. That was the night I got hooked up with LastPass too, since there's nothing like trying to log back in to iTunes after a few months blissful absense to get you into self-harm. So, tip#2: use LastPass.

And that's a clue to the best analogy I can give to what happens if you're like me, someone who uses their phone a lot, and your phone goes out of action for a month. It's like Brian Cox talking about entropy in Namibia - everything goes to crap simply because that's the most likely course of events. Sure, everything could come out golden when something goes wrong with your phone, but entropy dictates that disorder is far more likely. For instance something entropic like, oh, that a day or two after I go to Bali on holiday the repair shop will leave my phone back to the shop, they will phone me, and the message will get buried in my unlistened-to message bank. There are just many more ways that chaos can happen than ways that things can go to plan. You can't change that, it's a law: the second law of thermodynamics, in fact. But you can plan for it, by having a disaster recovery plan in the shape of a spare mobile. Do it.