Google App Engine is a way to run your applications on Google infrastructure. You push your code to App Engine and it gets scaled out depending on how many instances you need.

My notes from the talk are below, but you can find the full slides here or here.

LAMP Setups

The motivation for using Google App Engine is due to the limitations or constraints of a typical LAMP (Linux, Apache, MySQL and Perl/PHP/Python) setup.

1) Single Server

A single server running the LAMP stack is not scalable and has a single point of failure.

2) Separate web & database server

The next step would be to move the Apache server and the database to separate servers. You may get better performance but this is still not a highly scalable solution and you now have two single points of failure.

3) Multiple web servers

You can provide a more scalable solution by adding multiple Apache web servers, but now you need load balancing and the database remains as a single point of failure.
In order to utilize the multiple web servers, you can use round robin load balancing. Register the web server IPs with DNS; DNS record is cached with a TTL (Time to Live). But the TTL takes time to propagate down and may not be respected, so if a web server goes does, you can still have problems. Additionally, the database remains a single point of failure.

4) Master Slave Database

The next approach is to use a Master Slave database. Note that this approach was also discussed at the Database Scalability Patterns talk, and the Database Sharding talk. This Master Slave database approach improves read throughput, but the Master is now a single point of failure for writes and may die before replication takes place.

5) Partitioned Database

So, you can migrate to a partitioned database where you will (hopefully) have better read and write throughput, but where you now have more machines and more management and you may need to update your application logic, queries and schema.

Google App Engine to the rescue

So, in order to avoid all the hassle of above, Google propose using the Google App Engine.

Cloud Computing landscape

App Engine fits into the Cloud Computing landscape as follows:
Software as a Service: Google Docs, saleforce.com
Platform as a Service: Google App Engine, force.com
Infrastructure as a Service: Amazon Web Services, Rackspace, VMWare

App Server

The App Server component of Google App Engine:

• Hosts application code
• Handles concurrent requests
• Enforces isolation for app safety
• Maintains statelessness
• Supports Python & Java runtimes (and in fact any language than runs on JVM, including Scala)

It also supports the following services & APIs

• Memcache – Distributed, very fast, in-memory cache
• Datastore
• Uses Bigtable
• Distributed, partitioned data stored
• Arbitrary Horizontal Scaling to ‘Internet Scale’
• Replicated and Fault Tolerant
• Predictable query performance with no deadlocks
• URL Fetch – Simple Http communication with GET/POST to external services; Allows integration with 3rd party REST APIs
• Mail – Inbound & Outbound mail
• XMPP – Instant messaging
• Task Queue – Background & scheduled computation and processing infrastructure
• Images
• Blobstore – Upload and distribute large files
• User Services – User account support including federated login (via Google accounts)

Open Source Implementation – TyphoonAE

The presentation finished with a code demo, but the presenter also pointed out that there is an open source implementation of Google App Engine called TyphoonAE.

What is an engineering leader?

• Serves the team
• Eliminates roadblocks
• Provides advice, guidance and helps get job done
• Mutual respect/Mutual trust
• Promotes technical and social health
• Leadership is not a waste of time…
• Being a team leader is a way of scaling yourself

The speakers broke their talk on how to be a good leader down in to two sections, which were (in good coding tradition) patterns and anti-patterns…

Anti patterns for leadership

1. Be everyone’s friend
Don’t try to be everyone’s friend because you still need to be a hard-ass sometimes. Instead, just try to maintain a healthy, working relationships. For example, try having lunch with your team regularly.

2. Treat reports as children
Give responsibility and trust.

3. Micromanage
Micromanagement breeds co-dependency. If you are off for a day, the team can’t work. They should work on their own initiative, without your commands.

4. Hire pushovers
Don’t hire people that are dumber than you! If they are smarter, you will build and better team and learn more from them.

5. Compromise when hiring
Don’t just just hire the top 10% of candidates you interview – they might not be good enough.

6. Ignore low performers
Do not ignore them! Low performers are the obstacle in the road. They will not go away. Try to motivate them. Maybe need to more-micro-manage. Have an ‘acceptable’ level bar.

7. Ignore human problems
Don’t assume the team has no life outside of work. Keep morale up.

Patterns

1. Be honest
There is no such thing as a temporary lapse of integrity!
Deliver criticism directly, constructively and with empathy.
Be honest about your motivation for making decisions.

2. Be a wise zen master
If someone asks hard questions, you can respond with questions.
Don’t try to manage people!

3. Lose the ego
You don’t need to be the smartest person in the room. Trust others and respect their abilities.

Appreciate any inquiries the team has; Accept feedback and don’t be scared to apologize. Humility != Doormat

To influence, be influenceable.

4. Get your hands dirty
Lead by example and understand the problems the team is going through.

5. Delegate
Delegate even if another team member can’t do a job as well (or as quickly) as you think you can.

6. Seek to replace yourself

7. Make waves
When you lease want to make waves, this is probably the time you should be making most waves.

8. Shield your teams from bureaucracy

9. Succeed and fail as a team
Public praise, private criticism as everyone already knows when someone messed up.

10. Be a catalyst, a teacher and a mentor

12. Set clear goals
Make sure everyone agrees on the milestones and the plan for a projects.
Otherwise you get feature creep and get side tracked.

13. Track happiness & careers
If someone is not happy,find out why.
What do team members want to be doing?
Ask them what they need?
Get everyone to work on fun stuff & dull stuff. Change it up.

Give Autonomy & Trust
e.g. the 20% time @ Google

Mastery
People want to grow; Always want to master new things; Give people a sense of purpose

Managing your manager
Act like a grown up. Encourage people to take responsibility

Pursue responsibility
Do more than is required. Deliver 110%
Take calculate risks

If you fail – learn. And document the process and what was learned.

Communicate!!

Point out obstacles

Argue
Good leaders don’t want yes men
Give back structured criticism

Conclusion

3 words:

• Serve
• Respect (give more, get more)
• Motivate

Stop being a manager, be a leader!

Finally, the speaker recommended checking out a talk by Dan Pink on Intrinsic vs Extrinsic Motivations. I think this is it.

The demo for our BlipWiki project (which I blogged about here) unfortunately had technical difficulties so our presentation didn’t go so well. One of our 2 browsers couldn’t seem to connect so we didn’t get to show our Wiki updating in real time in the way we would have liked. Still, I think we had a great application at the end of the weekend, and I certainly learned a lot, met a lot of great people, and got to know Google Wave much better. A great weekend…

There are photos and videos from the weekend posted here and a write up in the San Jose Mercury News.

I joined the Blip Wiki team. A Blip is simply a single message within a ‘Wave’ conversation. A Wiki, of course, is a software tool that allows users to easily create, link and collaborate on documents. So, our goal with the ‘Blip Wiki’ project was to bring the incredible collaboration capabilities of Google Wave (real time updates, autocorrect context sensitive spelling etc) to the easy document setup and linkability of a Wiki.
Although Wave can certainly be used to collaboratively create documents as it is, Wave is inherently conversation focused. We wanted Blip Wiki to be inherently Document focused.

To do this however, we needed to use our own instance of a Wave server i.e. use the Google Wave Federation Prototype Server rather than the regular Wave server hosted by Google. We also needed to come up with a new client (something like tiddlywiki) and, most importantly, ensure our client can communicate with the server. Our project won the award for the most ambitious pitch at the start of the weekend!

Federation Prototype Server and example client

We got off to a good start by getting the Wave Prototype Server downloaded, building and running (it runs on top of OpenFire, a real time collaboration server that uses XMPP/Jabber). We then got the demo wave client running and talking to our server. We managed this by late Friday evening.

Client/Server protocol

Next, we created our own demo client and tried to get it interacting with our Wave server. That is when we started running into problems. First, the client/server protocol has not yet been formalized, and there don’t seem to be any definite plans to do that yet either. For example, although this Client Server Protocol White paper describes a protocol and data model, it does not give any details on the format that should be used, or suggestions on how to use it. There is a lengthy discussion in the Wave Protocol Google Group about this. For example, someone suggests that the client server protocol is just protocol buffers ‘over the wire’. But a protobuf is really just a simple data format, and while I assume ‘over the wire’ means RPC, it is all a bit vague.

Submitting changes

The client/server protocol used in the example client (a “toy’ text client) is for “illustrative purposes only”, according to this doc. We couldn’t seem to find much documentation for it, perhaps because it is not supposed to serve as a standardized example. As a result, we found it difficult to reverse engineer. So, we ended up resorting to using the Client example code to marshal our data to and from the server. The example client code in effect became a sort of interface to the server for us. A client side stub, if you will. (We had this running in the web tier servlet layer).

Receiving updates

So, after we had used the Client example code to submit changes (blip updates) to the server, our next hurdle was understanding the data that gets returned. Ideally, we would like a ‘delta’ of the data. That is, after the server has done it Operational Transformation magic, we would just like the latest and greatest version of the data to display on the client. However, this proved difficult to get from the server. Instead all I could seem to get was a non-delimited complete history of the blip. I admit that this was done using pretty hacky code. I am sure there must be another, better way!

So, we ended up taking a similar approach to the example client, and just displaying the latest submissions.

Demo ready – almost…

Right now, we have a working client and server with updates made on one user’s WikiBlip automatically showing up in another users.

It would have been really nice to be able to deploy our local Wave Server to app engine, but apparently this isn’t possible since the OpenFire jars required aren’t on the whitelist of allowed jars.
It also would have been nice to experiment with our local Wave server talking to the real Google Wave server (e.g. to have a regular wave client user be able to interact with a blip wiki), but apparently this is not possible due to authentication issues.

So, we chose a very difficult task for the weekend! But, we have a working version ready to demo and it has been a great weekend all in all.

Thank you’s

A big thank you to

• Sriram and Sreejith, my BlipWiki teammates
• Kevin and Van from the GTUG
• Stephanie, Brian, Fred and all the all Googlers who made the weekend possible and great!

I will post again later with the results of the demo…

I am not too familiar with Wave yet, so this should be a great opportunity to get to know it better, meet a bunch of fellow techs, and hopefully produce something cool by the end of the weekend. Looking forward to it…

Registration is free, so if you are interested you can sign up at here.

The presentation slides can be found here.

I thought Romain was an excellent presenter and did a top job of talking on his area of expertise: Android UI development. He covered the issues you need to be aware of when developing Android UIs if you want them to be performant, best practices and work-arounds for the gotchas, as well as useful tools that can be used for development. Personally, I would have benefited from more of a broad overview and introduction to Android, but that is more a reflection of my own lack of knowledge on Android! Maybe the newly created Android User Group will provide an ‘Intro To’ type talk at some point…

First, Romain covered the Andriod UI terminology (like Canvas, Drawable, Surfaces and Views) before covering the architecture.

The bulk of his talk covered how to make sure you UI runs fast, including:

• Avoiding runtime scaling of background images
• Avoiding invalidating (i.e. redrawing) the entire screen and instead only invalidate the small part of the screen that has actually changed.
• Minimizing the number of views you use (ideally have <100, which seems pretty reasonable for a tiny phone screen!) and talked about some techniques to help with this including using ViewStubs and recycling views
• Avoid allocating memory (apparently the Garbage Collector is slow and pretty much stops the world when it is running)
• Use SoftReferences (objects that only have soft references to them will be kicked out of memory if the Garbage Collector needs more memory) and WeakReferences (which can help to avoid memory leaks) when possible

He also talked about some neat dev and debug tools including Allocation Tracker (which monitors objects being created, memory being allocated etc) and Hierarchy Viewer (which shows you all the devices/windows/views you have how long things are taking to render).
He also mentioned the Android emulator that can be used for testing your apps.

Some of the questions from the Q&A session included:

Q: Will Android support languages other than Java?
A: Romain mentioned that there is a version of Scala and python that work on Android, but currently all APIs are in Java.

Q: Does Flash work on Android?
A: Development is on-going and the Android team is working with Adobe.
(I found more on the web about this topic here: http://gizmodo.com/5300800/flash-for-android-webos-landing-in-october)

Q: Can JavaFX be used on Android?
A: Code might be hard to run on the phone and may not be performant.

Q: Apparently, Sony Ericsson are also building an Android phone. How do you plan to avoid fragmentation as other companies start shipping Android phones?
A: CTS – Compatibility Test Suite
You cant ship a phone as ‘Android’ if it doesn’t pass the CTS.

Other links:
http://d.andriod.com
source.android.com
android.git.kernel.org
code.google.com/p/apps-for-andriod
http://android-developers.blogspot.com/
http://forum.xda-developers.com/