The ‘+’ that matters is that Google’s ‘+’ is web/http and Apple’s ‘+’ is objective c talking over some protocol that is inaccessible outside of Apple’s world. Yes, the user interface matters (a lot), but that is not the key differentiator. Over time, native and web will unify from a user experience perspective (of course standards will always lag innovation, but that is another story).

Traditionally, the term cloud has been associated with the web. Most large cloud implementations are all about the web and web protocols. Amazon (both books and AWS), Google, Flickr, etc all implemented their cloud services using open accessible web standards. They embraced and leveraged the spirit of the web by utilizing well known http protocols along with simple textual APIs. Call it the semantic web, web services, or web 2.0. In the end, it is about the ability of developers (with a wide skill gap) to mash together data and functional services to create completely new and interesting software. Think of it as the world wide middleware. The linkage between web 2.0 and these cloud based services…

Essentially, just go to the groovy console in hudson/jenkins (under Manage -> Script Console) and enter what ever groovy you like. The javadoc for the API can be found at: http://hudson-ci.org/javadoc/index.html

In my case, I needed to change the email address for every job’s notification settings. So, I used the following script:

import hudson.model.*

int count=0;
Hudson.instance.items.each{ item ->
  item.each{ job ->
     def configFile = new File(item.getConfigFile().toString())
     def config = configFile.text
     if(!config.indexOf("<recipients>")){
              println "$job Not Updated"
     }else{
         def regex = "</recipients><recipients>[^< ]*</recipients>"
         config = config.replaceAll(regex, "</recipients><recipients>somegroup@nowhere.com</recipients>")
         configFile.write(config)
         count++;
     }
  }
}
println "Updated $count Jobs"

The U.S. Patent and Trademark Office is confirming Amazon.com’s controversial 1-Click patent following a re-examination that lasted more than four years.

link: Amazon.com’s 1-Click patent confirmed following re-exam

On closer inspection, our measurements told us that pages were primarily slow because of network and render time. Our generation time definitely had (and still has) significant room to improve but it wouldn’t provide the same bang for the buck. So we devoted most of our engineering effort towards two goals: drastically cutting down the bytes of cookies, HTML, CSS, and JavaScript required by a Facebook page while also developing new frameworks and methodologies that would allow the browser to show content to the user as quickly as possible.

link: Facebook | Making Facebook 2x Faster

Some quick, back of napkin calculations suggest that they have reduced their overall bandwidth used for page transfer by 37%. If this is the case, using their published 200 million logins per day and 60 million status updates, they have reduced their bandwidth cost by over a half a million dollars. In other words, they actually get a return on that investment in year 1. Easy to justify that project. It makes you wonder why they waited so long.

Here are my back of napkin calcs:

Impressive Text Effect

See More at: The Best 40 Photoshop Text Effects from 2009 : Speckyboy Design Magazine

//
// Dear maintainer:
//
// Once you are done trying to ‘optimize’ this routine,
// and have realized what a terrible mistake that was,
// please increment the following counter as a warning
// to the next guy:
//
// total_hours_wasted_here = 16
//

link: Think Creative: Programmers humor

Mag+ from Bonnier on Vimeo.