You're browsing the “Tools” category.

Liveblogging on Twitter at http://twitter.com/natekoechley

everything in this article is my paraphrasing of speakers’ presentations. not my own words.

(Video coming soon.)

1. We run web applications. We’re only focused on this narrow goal.
2. We handle the entire lifecycle of an app.
3. Apps are run on Google infrastructure.

“It’s hard, but it’s worth it for us.”

“For the first time you can use the same infra we use…Auth, GOS, BigTable”

The Stack

1. Scalable serving infra
2. python runtime
3. SDK
4. Web based admin console
5. DataStore

Demo: App from scratch in 8 minutes.

More details

1. Scalable Serving Infrastructure: fault tolerant (redundant). Fluid: don’t need to schedule needs up front… more servers come online dynamically.
2. Python Runtime and Libraries. All tools are generic, so new languages can be dropped in later. Python used in same python available otherwise. Goal: you can use any language eventually. We don’t want to limit you.
3. SDK: Environment to develop apps locally. Avail for Linux, Mac, Windows today. (But can probably work anywhere.)
4. Admin Console: web-based admin console. (Looks like google finance meets google analytics.) Tools for request logs. Data explorer. Usage/quote numbers. App-version balancing. Can hook up domain (don’t need to run at *.appspot.com).
5. Scalable Datastore. Schemaless object store. Not a clustered sql thing. Instead based on BigTable. (Whitepapers online.) Horizontally scalable. Reacts to hotspots. BigTable instead of SQL is a big change, and may take some time to get used to. But we think you’ll come to like it. Schemaless means you can add a new datatype or entity whenever - no need to update your schema.

Now we’re looking at a Datastore Model Class.

GQL Query example

SELECT *
FROM Story
WHERE title = 'App Engine Launch'
AND author = :current_user
AND rating >= 10
ORDER BY rating, created DESC

Other Notes

Mail Sending API

no setup needed.

Make HTTP Requests

Authenticate with Google Accounts

Frameworks

The whole Django framework.

Guido van Rossum: Creator of Python and member of Google App Engine team

My passion is making life easier for developers. With python i’ve done that for decades. Now i’ve joined GAE team. Excited by potential. (and that python was first picked)

First time that GOogle has let third-party people run software on their infra. That’s fundamentally a big deal.

8:13 PM “We’re offing 100% of the python lang.”

8:14 PM - we don’t offer threads, but you won’t been it because of our scalable arch.

GAE uses a quota system so nobody monopolizes the infra.

me: if it’s so scalable, why do they need the quotes?

What’s Next?

• large upload/download support
• purchase additional capacity
• other language support
• offline processing.

I updated my Mac to Leopard a few weeks ago. All good.

Yesterday I ran the update to 10.5.1. Not so good: It knocked out my Cisco VPN client. Permanently. Rebooting did not help. Reinstalling did not help. (I rely on VPN non-stop, even to retrieve my office email.)

So today I poked around for a while and after some deep searching found the fix. It’s easy, and worked for me on the first try. The solution was on Anders Brownworth’s site (thanks Anders!), and I’m reprinting an excerpt here in the hopes that it will make it easier to find for somebody else.

If you are running Cisco’s VPNClient on Mac OSX, you might be familiar with (or tormented by) “Error 51: Unable to communicate with the VPN subsystem”. The simple fix is to quit VPNClient, open a Terminal window, (Applications -> Utilities -> Terminal) and type the following:

sudo /System/Library/StartupItems/CiscoVPN/CiscoVPN restart

and give your password when it asks. This will stop and start the “VPN Subsystem”, or in other words restart the CiscoVPN.kext extension.

Spent a bunch of time in the past few days pruning and organizing my feeds, and catching up on some blog reading. When I started, my feed inbox was at about 65,000 unread items. I’ve got it down to a much less daunting 22,491 unread items now.

I read about 400 feeds (well, the 65k unreads number tells you that I don’t *read* them all). If you’re interested in my reading list, and you don’t mind how dated, ugly, and messy it is, then by all means take a look. (Im working on improving it, and will post as update when it’s better.)

Information R/evolution is a five minute video telling the story of the transformation from a world of categorized information to a world of living information the we all enrich continually. It’s from the same guy (Michael Wesch) and in the same style as "Web 2.0 … The Machine is Us/ing Us."

When his "Web 2.0," video came out I wrote that

Perhaps the so-called ’social web’ isn’t about connecting people, but about information conservation: If a person chooses to do something — no matter how small — it’s inherently interesting, precious, and valuable.

I still think that’s true, and I find more support in this new video:

Here is "Information R/evolution" by Prof. Michael Wesch:

Hap tip to the information aesthetics blog which is a great source for "data visualization & visual design."

Alex Russell (of Dojo fame) has an good post up right now called Browser.Next in which he lists 10 key things browsers need to give us poor developers so we can do our jobs without going insane. Here’s the list, but head to his blog to read the details:

1. Event Opacity
2. Long-Lived Connections
3. Expose [DontEnum] To Library Authors
4. Fast LiveCollection -> Array Transforms
5. Provided A Blessed Cache For Ajax Libraries
6. Mutation Events
7. onLayoutComplete
8. HttpOnly cookies
9. Bundle Gears
10. Standardize on the Firebug APIs

I’ve long felt that the balance of power between web developers and browser vendors is out of whack: for every one developer working on the browser itself there are probably 1000 web developers at companies around the world toiling endlessly, struggling to overcome the shortcomings and weaknesses of the browsers. It’s wrong. It’s wasteful. It’s expensive - a drain on the economy, and serious sand in the gears of what should be the world’s most powerful innovation platform.

And so, from that perspective, I’m very happy to see visible developers like Alex telling the world (*cough* browser vendors *cough) what needs to change. He’s got a good list of comments going over on his blog - I hope you’ll join in the rally.