Speakers:

Sebastian Stadil
Founder of Scalr & Founder of Silicon Valley Cloud Computing Group

Georgi Dagnall
CEO at Geogad & Leader of Android / iPhone informal meetup

Location: Hurricane Electric
Address: 48233 Warm Spring Blvd, Fremont California 94539
Food & Drink: Sponsored by Hurricane Electric

Register for the event at Eventbrite:
http://cloudcomputing2010-efbevent.eventbrite.com/

Agenda:
6:00 pm Networking & Food / Drink
7:00 pm Presentation
8:30 pm Raffle Prizes

Session I:

Cloud is becoming main stream in replacing traditional web host & servers. Most popular cloud computing options are Google App Engine (GAE), Microsoft Azure, Amazon (AWS), Rackspace, Salesforce, Zoho.

Cloud computing can be implemented into layers: Client, Application, Platform, Infrastructure, and Server.
As the Cloud is getting more complex in its offer and features, anyone would have to learn the basic of cloud computing, best practices, and optimizations. Come and hear from the experts in Cloud Computing.

Cloud Computing Options

• What are new trends in Cloud Computing ?
• How to setup Cloud Computing from scratch?
• What kind of mistakes to avoid ?
• How to keep the cost low ?
• How to use cloud computing in a lean startup ?

Sebastian Stadil
Founder of Scalr & Founder of Silicon Valley Cloud Computing Group

Sebastian has been an Amazon Web Services developer since 2004, starting with the E-Commerce Service (now Associates Web Service), then the Elastic Compute Cloud (EC2) as it was launched. He founded the Silicon Valley Cloud Computing Group, a user group of over 1800 members that meets monthly to present the latest developments in the industry.

Recently, Sebastian founded Scalr, a software-project-turned-startup that scales website infrastructure automagically. When he is not working on Scalr, Sebastian likes to make sushi and play rugby.

Sebastian Stadil’s Specialties:
Development (Ruby, PHP, jQuery, Git, Test Driven Development, REST and SOA) ;
Infrastructure (Apache, Tomcat, memcached, Amazon EC2 and S3, Cassandra, MySQL Cluster, NoSQL)
http://www.linkedin.c/…

Session II:

These days most popular device applications in iPhone & Android requires server-side content and computing. Our speaker(s) will be sharing their experience in designing and deploying server in supporting mobile application.

Georgi Dagnall
CEO at Geogad & Leader of Android / iPhone informal meetup

Georgi Dagnall is CEO at Geogad, Inc, an Internet travel content platform that distributes audio- and video-based self-guided tours of popular tourist destinations. The tours are available over the web, over the mobile web to browsers on feature phones, and over Google Android-powered smartphones via native apps. During her time at Geogad, Dr. Dagnall has become proficient in audio and video content delivery over multiple channels and mobile devices. She hosts the Informal Android Developer Meetup in Silicon Valley and coordinated and led the first Android-related developer-led competition in Silicon Valley. Her wide background in computer systems and languages is includes HTML, CSS, JavaScript, AJAX, Java, J2EE, PostgreSQL, C, and C++ among others. Her prior employment covered both R and technical marketing in the cable TV optical systems division of Harmonic, Inc. She received her doctorate from the Georgia Institute of Technology while researching the growth of InAsP strained quantum well lasers.

See you All There!

Wednesday, June 30, 2010 from 6:00 PM – 9:00 PM (PT)

Hurricane Electric
48233 Warm Spring Blvd, Fremont,  CA 94539
http://cloudcomputing2010-efbevent.eventbrite.com/

Our speakers will share the latest development on Python 3.0 compared to Python 2.0 and the role of Python in Google App Engine. Top open social developer from Buddy Poke will share his insight in launching a scalable opensocial-based social application on Google App Engine.

Event Title: Python 3.0 and its love interest with Google App Engine
Speakers:
Jeff Scudder, App Engine Engineer at Google
Alex Martelli, Python Engineer at Google
Dave Westwood, Founder & App Engine Developer at Buddypoke

Date/Time: 4/8/09 Wed 6-9PM
Location: Google, Mountain View Campus
Address: Tunis Tech Talk Building 43, 1600 Amphitheatre Parkway, Mountain View, CA 94043

Agenda
6:00-7:00 Social & Demo
7:00-7:45PM Python3.0: History & Future
7:45-8:00PM Break
8:00-8:45PM Python in Google App Engine
8:45PM-9:00PM Top Google App Engine Developer Experience Chat – BuddyPoke

Food & Drink: Sponsored by Google

Registration: http://pythonloveappengine.eventbrite.com/

What You Will Learn:

• iPhone App Store – How to improve your revenue
• iPhone Analytics – How to drive your app install
• iPhone Business Intelligence – How to position your app
• Demonstration on Flurry Analytics
• How to install FlurryLib and FlurryLibLocation into Xcode
• What additional info you gather on FlurryLibLocation
• App Data & Usage Behavior comparison: iphone, Android, Java ME
• App Store install, pricing & category comparison: iphone, Android, Java ME

Sean Galligan – Vice President, Business Development at Flurry, Inc.

Registration: http://iphoneanalytics.eventbrite.com/

Google Moderator
http://moderator.appspot.com/#16/e=19f32

State of Job Market and Best / Worst Strategies (10 min)
Tom Zhang, Google Senior Recruiter

Tom Zhang, Google Senior Recruiter
Tom (Qi) Zhang has been with Google Staffing since Jan. 2006. As the G-Talent evangelist, Tom has been doing sourcing/recruiting to meet Google’s staffing needs. Before joining Google, he taught at Computer Science Department at San Jose State University. Tom received his Ph.D. degree from Zhejiang University, China.

The Matrix of AJAX Revolutions: JQuery, Dojo, YUI, GWT, and MooTools

Speakers:
Dylan Schiemann, Co-creator of Dojo Toolkit, CEO at SitePen, Co-Founder at Comet Daily
Yehuda Katz, JQuery Contributor and Engineering Manager at Engine Yard
Adam Moore, Architect of YUI and founding engineers at Yahoo
Fred Sauer, Developer Advocate at Google, GWT contributor, Author of gwt-dnd, gwt-log and gwt-voices
Tom Occhino, Contributing Developer at MooTools

Registration: http://matrixajax.eventbrite.com

• Dylan Schiemann is the Co-creator of Dojo Toolkit, and is responsible for bringing Dojo to the forefront both in technical achievement and adoption. Dylan will tell it to you like it is. I’ve never seen him claim to know everything about all ajax libraries, but he’s never at a loss for sharp analysis.
• Tom Occhino is a Core Developer of MooTools. He’s started experimenting with JavaScript at a far younger age than anyone, and somehow he’s still at it.
• Adam Moore is the Architect of YUI and founding engineers at Yahoo. Adam More is personally responsible for many of YUI’s core components. He clearly knows what it takes to guide a library from its fledging stages to worldwide, daily use on the order of hundreds of millions of users.
• Fred Sauer is a Developer Advocate at Google where most of his time is devoted to Google-Web-Toolkit and Google App Engine. He’s the sort of guy we need to bring an enterprise perspective to this discussion, as he’s spent much of his career in Java related technologies, serving as a consultant in North America, Asia, and Europe in the financial and billing industry.
• Yehuda Katz is a contributor to and evangelist for jQuery, as well as the lead developer of the excellent Merb framework. Like so very few others, he’s found himself right in the middle of two massively successful open source projects, and at the same time.

Get your questions ready and I hope to see you next Wednesday!

Lunch & Raffle Prizes: Sponsored by Offerpal
Facility: Sponsored by TEN
Media and Giveaways: Bebo/AOL

Date: 12/6/08 Sat
Time: 12:00pm-6:00pm

Location: TEN’s Santa Clara Innovation Center
Address: 2953 Bunker Hill Lane, Ste 400, Santa Clara, CA 95054

Prepare your laptop before Hackathon:
Fully charged laptop with wifi support
Bring charger and power extension
Install Terminal command-line utility PuTTY for PC or Telnet for Mac
Install Notepad for PC or TextEdit for Mac
Install FTP program WINSCP for PC or FileZilla for Mac
Install Firefox on PC or Mac
Create an email account or use existing email yahoo or gmail
Create Facebook Account
Create Bebo Account

Stephen Anderson – Viewzi, VP of Design
Mitch Grasso – Sliderocket, CEO & Co-founder
Elaine Wherry – Meebo, VP of Product & Co-founder
Bill Wetherell – AOL, Director of AOLMail

There were 3 overarching topics within UI where the panel weighed in on:

1. Defining UI 2.0
“Web 2.0″ was coined to describe a fundamental shift that had occurred in the internet world. This led to the question as to whether or not there was a similar shift in the UI world. Was there such a thing as  “UI2.0″ and if so, how was this defined?

Panelists in general thought that Web 2.0 had an affect on design in both processes and new interactions. One panelist defined UI 2.0 in terms of the new processes that were practiced as a result of Web 2.0. Other panelists defined UI2.0 as a whole library of new interactions that were “on demand” (e.g. the edit boxes appear in-line on the page). While AJAX has been the technology that has facilitated most of these new interactions, there were still metaphors that users expected. A good example was when the new Yahoo Mail was updated to be more similar to a rich internet application (i.e. users could drag and drop their email), users still wanted checkboxes to be able to delete and more their mail. However, in general the technology has enabled design find ways to have user interaction define the technology rather than technology defining user interaction.

2. Effects on Design in UI2.0
As mentioned above their is no doubt that UI2.0 had affected Design. The main ways design has been changed were in these ways:

• Product design must work in a much more faster, rapid and agile environment.
  Rather than traditional monthly or yearly releases, all companies represented were working on release cycles from 1-3 weeks. Docs and specifications are a lot lighter and many times design and engineering will try and work in parallel.
• Product design has become more iterative and less “perfect”.
  This goes hand in hand with rapid and shorter design cycles. Designers don’t have time to make things perfect, and since there is another release coming up, the fix gets implemented/designed in that cycle. This means that lest “perfect” product is released. However, the early feedback will prevent bad product directions before it’s too late.
• User Testing still exists; however it is re-defined to be just as light and fast as the product design cycle.
  Meebo has done user testing/feedback in one day cycles so that they could catch a majority of the problems in a fraction of the time. AOL leveraged the blogosphere to hear customer feedback regarding their releases. While SlideRocket and Viewzi watched users use their product to gain feedback.

3. Future of UI
While this may be too early to tell much, but that didn’t prevent our panel from prognosticating. Here were some ideas:

1. Interfaces would focus more on delight. As we climb up the pyramid of design needs, delight is one of the top things. See Stephen Anderson’s slides on this topic.

2. 3D interfaces and tangible interfaces will become more prevalent.

3. Interfaces will become more adaptive and learn from the user’s history.

The panel was a great time to focus on UI2.0 – define it, analyze its affects and conjecture about the future. Thank you all for coming.

Holly
Watercooler Inc.

HTML5 provides a new thing called a WebSocket. I’m pretty sad that its not a TCPSocket, but alas, it was easier to throw in a handshake for security than to set up some out-of-bound security method, such as flash’s cross-domain policy files. We can’t connect to existing TCP servers, so we’ll just have to start over and write new WS/TCP servers. No problem. WebSocket will still be our salvation, leading us towards our stateful future.

I was at first overjoyed at the prospect of the World Wide Web’s new status as a real boy. But such feelings were just a precursor to the greatest technology-driven depression of my life. You see, as recently as twenty years ago the world was brimming with real programmers, who knew how to do such amazing things as write programs that conversed with far-away computers by using bsd sockets. We’ve traded those programmers, by and large, for JavaScript kiddies. Its not that the real programmers all died, retired, or gave up with programming; rather, every new programmer of the past decade is a bright-eyed 22 year old who thinks he’s the best thing since Google, what with his domination of rails (, java, or php) and javascript.

You can probably empathize with my character’s role in this story; I’m just like every other post-apocalyptic protagonist, having spent my whole life questing after futuristic technology of the past, only to discover upon finding it that we’ve fallen so far as to render its usage unobtainable.

The fact of the matter is this. Our civilization already selected “Good Network Application Architecture” and clicked research. Such practice includes simple ideas:
1) Isolate GUI logic to the client
2) Design a protocol (or use an existing one) to transfer application data
3) Use something called state. Have a session. In fact, tie that session to the TCP connection.

But such wisdom can’t help us. We can’t even begin to understand its profoundity because we wholly lack the context. I’ve been trying to re-establish some of that context over the past couple of years, having devoted my life to uncovering the lost art of TCP. And I’ve succeeded in casting a bright spot of hope upon this gloomy era of Web Architecture. My work with Orbited culminated in the development of a TCPSocket api for all browsers. Much like squeezing the oil from olives to fuel the last of our ancestors’ mechanized tractors, this is made possible by employing Comet and Ajax to communicate with a TCP proxy, and thus with actual TCP servers.

But as I said, we’ve lost our context. Realizing my dream doesn’t mean anyone else realizes the next, obvious step. Time to stop dragging the plow yourself and we’ll cover some real ground. But handing a socket to a Web Engineer is the same as handing a tractor to a caveman. You’ve really got to spell out how to use it. And it turns out that the tractor is just too damn complicated to actually use.

So the next leg of my journey was to assemble a codex of knowledge. What does one do with a socket? Thus began the development of a collection of network codecs, js.io. Instead of teaching Webjneers how to use sockets, I can teach them how to use XMPP, IMAP, and STOMP clients, so they don’t have to invent their own shitty wheel when building a proper network application. So enters light into this world.

If only. Really its a small, fragile light that could be snuffed out by a stray bus on Castro street. When the 1 out of 50 web programmers I talk to actually start to get the idea of Orbited.TCPSocket and js.io, I don’t get the satisfaction of wisdom well shared. Instead, I get questions like, “Isn’t building stateful communication on top of stateless communication just a big hack?” All I can say is this: Its kinda like building TCP on top of IP. Or building so-called “HTTP sessions” on top of HTTP. But such comparisons are lost on savages.

Instead of laying down my burden and letting someone else carry on the torch, I noticed a fellow seeker, Hixie, who had tried to put a TCPConnection into the HTML5 Specification.

“Ho, Hixie.”

And with those words I proposed some improvements which led to what we now know as WebSocket, camel casing and all. Let this idea of a WebSocket be a standard ™ in this world.

So what happens now? I suspect that nothing will happen. We will have limited uptake of Orbited.TCPSocket and HTML5 WebSocket. There are too many trillions of dollars invested in the wrong way of doing things to such an extent that doing things the wrong way will be easier for a long, long time to come. Eventually though, we’ll have our salvation.

Though I despair with the present, we should recognize the moral of this tale, that the past iteration of technology led us right to the very brink, and then over. We must never repeat our mistakes. Only Open technology that runs everywhere is acceptable. The modern Web Browser has this characteristic, and it is this that we must keep as we recover our ancestor’s secrets. We must be ever vigilant, for a single slip can and will lead to a second apocalypse from which we may not recover. I am hopeful that a third era will arrive when I can truly say that there is technology in this world that doesn’t suck, and technology that is new; browsers with sockets are a likely candidate for both.

Michael Carter

Speakers:
Doug Ricket, Map Engineer from Google
Marzia Niccolai, App Engine Engineer from Google

Date: 11/9/08 Sun
Time: 1:15pm-4:15pm
Location: Foothill College Campus
Address: 12345 El Monte Road Los Altos Hills, CA 94022
Parking: Parking Lot 5
Website: http://www.siliconvalley-codecamp.com
Toy Giveaways: Sponsored by Rockyou http://www.rockyou.com
Facilities provided: wireless internet, electrical outlet, tables and chairs
(optional): Laptop with power cord

FREE Lunch 12:15PM
Provided by SVCC Sponsors

1:15PM Sunday
Hackathon 4 Kids: Building App over Google Map
Doug Ricket
“Google Maps engineer Doug Ricket will be going over all the basics of the Google Maps API — watch cool demos of games and mashups and learn how to do it yourself. Please bring your laptops to follow along.”

2:45PM Sunday
Hackathon 4 kids: Building App over Google App Engine
Marzia Niccolai
“Marzia Niccolai will amaze and inspire you by walking through building a simple app from beginning to deployment – make a slamback and collaborate with all your friends!”

Now W3C is defining the HTML 5 standard, which promises to raise the bar for the modern Web browser, turning it into a fully capable rich Internet application client platform.  The most important Comet-related enhancements defined by HTML 5 are called Server-sent Events and WebSockets.

HTML 5 Server-sent Events (SSE) standardizes Comet for all browsers, eliminating the need for those clever workarounds that make the task of writing both Comet clients and Comet servers so challenging.  Instead, SSE allows the browser to send an HTTP GET request to the server, and defines the syntax of the response payload that is used to stream events from the Web server to the HTML 5 compliant browser.  Each event is described using a line-based syntax, with an optional event type (defaults to “message”), an optional id (used to track progress through the event stream), and the data which describes the actual event payload, such as “Hello, world” shown below.  An empty line marks the separation between events in the stream.

event: message\n
id: 101\n
data: Hello, world\n
\n

The HTML 5 DOM introduces a new element, called “eventsource” that is used to co-ordinate access to one or more SSE event streams.  Setting the source on an eventsource element triggers the HTTP GET request described above.  Adding an event listener to the eventsource element allows the application to receive events in JavaScript as they arrive at the browser.

<eventsource src="http://www.example.org/server-sent-events"
             onmessage="alert(event.data);" >

If connectivity is broken between the Web server and browser, then the eventsource element automatically attempts to reconnect, informing the Web server of its progress through the stream to avoid receiving duplicate events.

However, simply standardizing Comet is not sufficient to satisfy the networking requirements of a fully capable rich Internet application platform, because we also need full-duplex bidirectional communication, just like traditional desktop applications already enjoy today.  To address this requirement, HTML 5 standardizes WebSocket, which integrates with the existing HTTP infrastructure of the Web to complete its handshake with the WebSocket server, and then switches protocols (on the same TCP connection as the initial HTTP-based handshake) to remove the undesirable half-duplex nature of HTTP from further communication.

The WebSocket JavaScript API provides the equivalent of a desktop style TCP connection, limited to text-based payloads for now, because JavaScript does not yet have a byte or ByteArray type.  The WebSocket wire protocol itself can represent either binary or text payloads, so languages other than JavaScript that do have a binary representation can choose to send binary data to a WebSocket server in the raw, rather than having to encode the binary data as text.

var socket = new WebSocket("ws://www.example.org/web-socket");
socket.onopen = function(event) { alert("socket opened");
                                  socket.postMessage("Hello, world"); }
socket.onread = function(event) { alert(event.data); }
socket.onclosed = function(event) { alert("socket closed"); }

WebSockets represent a revolution for rich Internet applications, because they enable socket-based access to back-end services.  For example, with WebSocket, a JavaScript implementation of the XMPP protocol (used by desktop GTalk for chat), a suitable WebSocket gateway server, and any off-the-shelf XMPP-compliant server, you can develop a Web-based chat solution in short order, focusing primarily on the user experience.  Naturally, the scope of WebSocket is not limited to XMPP, in fact any TCP-based protocol is feasible to implement over WebSocket.

The world of HTML 5 Server-sent Events and WebSockets certainly seems exciting, but when will browsers implement it, and how should we prepare?  The HTML 5 specification is scheduled for completion in 2022 (!) although the Server-sent Events and WebSocket sections seem more stabilized than others and will likely be implemented in modern browsers much sooner than that. But even if all the modern browsers would implement these standards today, there would still be an issue of backwards compatibility for folks using older browsers, futher increasing the burden on developers to support such varying browser capabilities.

Fortunately, it turns out to be possible to emulate both HTML 5 Server-sent Events and WebSockets in all the modern browsers today using Comet.  The Orbited open-source project provides something similar to WebSocket called TcpSocket, and Kaazing provides emulation of HTML 5 Server-sent Events and WebSockets in both open-source and commercially supported solutions.  Working with APIs that closely emulate the HTML 5 standard today will allow those Web applications to seemlessly fall forward onto the native browser implementations as they become available. This should also help to stimulate futher interest in the HTML 5 specification itself, hopefully leading to an earlier completion date!

If you would like to find out more about how you can start building your future Web applications today, please join us for an intriguing panel discussion at the Chronicles of Web Standard: the HTML 5, the Comet and the WebSocket.

John Fallows