Saturday, November 21, 2009

Google Chrome OS How To and First Impressions

Twitterstract: Walter installs Chromium OS and realizes that it's a lot like the Chrome browser. He offers a few tips if you are wanting to take it for a spin.

It feels like this has been my Google week. Saturday again, and it's been Google Wave, Chromium for OSX, App Engine and now Chromium OS (I even set up my Google Voice account). Here's a quick how-I-made-this-work post for the Chromium OS virtual machine.

I first saw that someone had taken the time to compile the code into a virtual machine from this post on Lifehacker. I think without this, I wouldn't have bothered. At this point, Chrome OS is really just a concept, dancing bearware.

I started out by venturing over to The Pirate Bay and grabbing the virtual disk image via Bit Torrent. FWIW I still haven't embraced the whole Bit Torrent thing. I've spent too many hours watching P2P take bandwidth from my company's connection while my boss or some other Important Person is screaming about how slow the network is going.

The disk image I pulled over was called chromeos-image-999.999.32309.211410-a1.vmdk.bz2 and was just under 300MB compressed. There are already a number of files on TPB that say they are chromeos images. After I downloaded the image. I unpacked it and then started up Virtual box. As an aside, I'm really starting to like Virtual box as a Parallels and VMWare replacement for home use.

In Virtual box, I mounted the disk image and created a new machine. First, I used the Virtual Media Manager (File -> Virtual Media Manager) to Add the vmdk file as a hard disk image. To do this, click on the Add icon and navigate through the file system to find the .vmdk file. Now we are ready to create the machine. From the main Virtual Box screen I click on the New icon to start the wizard. On the first screen of the "New" wizard, I told it that the Operating System was of type Linux and version Debian. I've read conflicting forum posts in various places on what to set here, but Linux/Debian works for me. I kept the defaults for memory. Then at the Virtual Hard Disk screen, I selected "Use existing hard disk" and chose my image from the drop down.

Then I started up the system. At the login screen I entered the username of "mark" and no password and pressed the enter key on my keyboard. This part seems to be causing lots and lots of consternation on the forums as people miss this point. As he says in his release notes, Mark used the local account name of "mark" for the system, not chromeos and not my real Google credentials. As each person builds an image, they must have to supply some credentials during the build. Once the ChromiumOS loads then we will be able to use our own credentials to get our own information from Google. On subsequent starts of the machine, I've found that I can use my regular Google account login to start the machine. When I do this, it loads with my Gmail and Calendar right away which is nice.

And voila. We are looking at the home page of Google Chrome OS or Chromium-os or Chronos as some are calling it. A couple of points if you're actually following along: once Virtual box captures your mouse, you release it by holding down the key sequence shown in the bottom right. For me it's a Left - command key

Another thing is that if you've been using Chrome, you've seen all of this before. You've also seen it in a much more stable way. I'm getting regular crashes of the virtual machine. There are a few differences though: the home screen of applications which is accessed by the icon on the top left of the window is one. Even this home screen isn't actualy on the machine. It's served up by an AppEngine robot. You can tell by the language it gives you if you are not logged into Google. If you've ever developed with AppEngine you've seen this screen.
This is truly a net computer then. You can use any device running this OS and get at your information. It seems that it's caching a little bit of my profile, but not really expecting to spend a lot of time reading and writing local files. The final piece of the OS that makes it different from Chrome is the system tray looking set of icons.

The triangle icon and the wrench icon below it expand to show the exact same menu. This duplication is because on some screens (right now only the Welcome screen) the wrench and other parts of the browser menu bar go away. The icon in the middle that resembles a wine cup tells me that I am connected to the network via wire and that my WiFi is turned off. The gray plug icon shows that I am plugged in.

If you're one of those people who needs to see the man behind the curtain, you can get a glimpse of the file/folder structure by changing the download location which will open a standard X file dialogue box. Use either the wrench or the triangle menu select "Options" then choose the "Under the Hood" tab. In the Downloads section choose "Other..." and you can poke around to at least see the folder structure.

The folks over at Google are posting a lot of their philosophy on this project over at Chromium.org so I would recommend you visit there to learn more. The videos and User Experience documents are accessible to most everyone. A lot of the other stuff is going to make your brain hurt at first.

Wednesday, November 18, 2009

"Compiling" Javascript Code

Look what I found this morning. It's a "compiler" for Javascript code. Since Javascript is interpreted instead of compiled it's not truly a compiler but it does something similar: makes the code readable for the machine and takes out all of the extra fluff that a carbon based life form needs for comprehension.

I have tested it with some of the javascript that I use on my personal sites and got about a 25% average compression.

I looked at the largest piece of Javascript on the astd.org home page. It is the jQuery UI javascript code at 188K. It compressed down by 11%. The other way to really compress the Javascript is to use gzip. Here is a blog post by someone else about it (he also mentions some other utilities for doing what Google closure is doing). Basically, you zip the Javascript and then, since it runs in the visitor's browser anyway their browser expands the file to run the code after they've downloaded it. Gzip is achieving near universal installation, so this method of compressing Javascript has less risk of breaking than it did a year ago.

In essence, what the Closure "compiler" is doing is removing all of the whitespace and pretty variable names that we use so that we can read the code. It's very much like the "Optimize for Web" settings for image programs which remove all of the color descriptions for unused colors and the like.

The home page for the Closure compiler is here and it also explains the philosophy behind what they are doing. It works in conjunction with Page Speed. I've started looking at these things recently because I was reviewing the analytics for our organization's web site and noticing that people are still hitting the site with dial-up. I'm also noticing an uptick in mobile visitors who might be using EDGE or other slower networks to hit our site. Living in an urban area with good G3 coverage and broadband in most places, we forget the costs associated with Flash effects and high-res widget graphics. The 2007 Census numbers show that 10% or so of Americans with home Internet access were using dial-up.

As long as any of those people want to be a part of our organization, we need to make sure they can access our information. Besides, a flashy website is not necessarily the only sign of organizational quality. Take a look at this company's website for instance. The look is dated but clean and speedy.

Monday, November 16, 2009

Why Google Wave Might Change the World

I got my Google Wave account over the weekend and spent some quality time with the documentation and the software. At first, I had a similar feeling like when XML first came out: so what. Most of the features of Google Wave are familiar to anyone who has used email or any of the other Web 2.0 sites over the last year or so. You can leave messages to people and collaborate on documents and there is a rich multimedia component. Ho hum.

At its most basic, the Google Wave concept is that the message/document is the object. In a regular system each email or tweet or update is it's own object and it is up to the user to string them together. Here, the entire conversation is the object. There is also the cool notion of playback so that someone who is added to the Wave conversation later can go back and step through all of the iterations that the wave has undergone.

"So It's just a fancy wiki" said my tech savvy kids. It appears that way, but there can't be this much hype for that...

But, then I had the revelation about why this is oh so much more than a wiki/blog/teamsite/twitter client: federation. Google's vision is that the system is distributed, not centralized. Like every domain has an email server, Google envisions that every domain will have a wave server. This helps with survivability of information as no single server needs to have all of the information. We read about twitter and Facebook and even Gmail going down which is a reason businesses shy away. However, if those types of services are replicated across the servers of all participants then we are back to the type of survivability that the original email and Internet designs promised.

In the subsequent days, my team and I also began to look at Google's robot api. Basically, you add a robot to your recipient list of your wave and s/he monitors the wave for keywords and actions and then does something in response. Having a robot who maintains a web page in response to the content of a wave is one pretty interesting use.

Next post will be about why this will never catch on or scale. I think that Google is onto something revolutionary. I also think that there are lots of ways that we normal people can screw the whole thing up.

Sunday, November 1, 2009

Touch Events and the iPhone SDK

There are four events for touches in the iPhone.

(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event

(void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event

(void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event


and


(void)touchesCancelled:(NSSet *)touches withEvent:(UIEvent *)event



In the excellent Stanford ITunes U course CS193P they mention that two important things about touchesCancelled cause a number of calls to Apple support: “Cancelled” has two letter L’s in it and touchesCancelled gets called at times when a developer may think that touchesEnded might be called. So, as a safeguard, I now just call touchesEnded from touchesCancelled as a default using this code:

[self touchesEnded:touches withEvent:event];

In general, touchesCancelled will be called when a phone call arrives or when the user presses the home button on the phone to quit the app. If your application needs to do something special there, then be sure to put some code in touchesCancelled. Examples of things you might want to put over there include returning your application to its default state.
Right now, Isabel and I are working on a game that has an NSTimer and also responds to UITouch events. I’m experimenting to see if the timer frequency and the event loop frequency can be set to values that conflict. I’m guessing that we probably can, but I’m also guessing that normal people cannot move their fingers fast enough to make a difference. However, people who drink a lot of Sun Drop....well, that’s another story.