Windows 8 – Lessons Learned

I got a great deal on a Samsung Ultrabook.  The person I was buying it for was most insistent that it didn’t have a touchscreen, which was a feature surprisingly hard to find.  It also came with Windows 8 pre-installed.  I reasoned that it couldn’t be that different.

Lessons Learned:

If you get a laptop with Windows 8 the first thing you need to do is switch the thing on and see what all the fuss is about.  This means you have to register it with email address(es), your phone number(?), and a password.  That password has to be all mixed upper/lower case, and can’t contain any part of your email address.  No problem, perfectly understandable precautions.

The first thing you’ll see is the new “tiled” layout screen, which disappears off to the right of the screen, containing a whole bunch of apps that Samsung has helpfully installed for you.  Most of which you won’t want.  How do you scroll right?  Well, since you don’t have a touch screen, this is way more awkward that it should be, but with a little trial and error, and by hooking a mouse up, instead of trying to use that awful touchpad; we find that the scroll wheel does what it should and scrolls nicely.  We’ll come back and fix this tile interface later on.

The very first thing you should do is get online and download about 87 Windows 8.0 updates.  If you try to do this without first responding to the confirmation email from Microsoft, which is sent after you complete your registration, the progress bar will quite happily sit there flashing away FOR EVER.

So, after completing the registration process, make sure you respond to the email from Microsoft.

If you have decided to upgrade to Windows 8.1 (advised), follow the instructions and go to the store.  You will NOT be able to find the upgrade anywhere in the store, or online at www.microsoft.com.  This is because you have to install all those updates (see above) before the store will allow you access to the 8.1 upgrade.

So, start the updates.  The progress bar will sit there flashing away for about 5 minutes, making you wonder what’s wrong now, before beginning to show some activity.

Go for a long walk.  Those updates are going to take a while.

After updating, rebooting, and updating some more, you are now ready to upgrade to Windows 8.1.  Go to the store and you’ll find the option to upgrade visible.

Begin the download of the 2.9GB!!!!!!!! upgrade package.  Words fail me.

Go for another long walk.  I don’t care how great your broadband connection is, you’re going to hit Microsoft’s servers, and they sure as hell aren’t going to be moving like greased lightning.

Finally, after the obligatory reboot, and more acceptance of terms and conditions, you’re back at that tiled page again.  Since you didn’t spend too long looking at it the last time, it’s hard to tell if anything actually changed.  The “internet” says it changed, and that it’s all for the better, but who knows.

Now I’m no luddite, but when it comes to paradigms for interfaces on a machine to be used as a DESKTOP computer then there’s one thing I like to see and be able to interact with, and that’s a DESKTOP.  So a little research and a speedy download later, although not through the Microsoft “Store“, but their own website (www.classicshell.net), we arrive at the very useful and thoroughly essential “Classic Shell”, coupled with the configuration to boot directly to the desktop, and voila! A functioning ultrabook running Windows 8.1

 

Google Apps API and Ruby – Part 2

My last post dealt with calling Google Apps API methods from a Ruby script.  I had hoped that I’d be able to do everything I needed with RESTful methods, but after a short while it became increasingly difficult, and I had to resign to using the Google API client GEM.  Initially I was resistant to using the pre-packaged solution as I like to know what’s going on under-the-hood when I’m interfacing with something, but it became apparent that the advantages to using the GEM far outweighed the simplicity of RESTful calls, especially with some of the APIs that I was going to be interfacing with.

As it turns out there are some very good reasons to use the google-api-client gem.  Since you can easily inspect the object’s methods and properties you can determine all the methods associated with an API.  For instance, to get the methods available for the version 3 Calendar api, once you’ve created a client object do the following:

api = client.discovered_api('calendar', 'v3')
puts api.methods

Nice right?

Even more useful is the ability to determine the APIs available, and their version numbers:

puts "Title \t ID \t Preferred"
client.discovered_apis.each do |gapi|
  puts "#{gapi.title} \t #{gapi.id} \t #{gapi.preferred}"
end

And that gives you a great start for attacking the Google API documentation.

There are some additional differences for creating a client connection.  You’ll need to have a private key file accessible to your script, on top of the usual server-side configurations.  You’ll also need to check out the advantages of using a “service account client”, which allow you to run API calls as a specific user, which is extremely useful when dealing with the somewhat flawed Google Apps access security model.