Day 2 - Future of Web Apps

[Ms. Jen's transcription and paraphrase plus some notes, will add more notes]

Paul Graham - walked in during questions

10am -Edwin Aoki from AOL
Edwin's Near Term Industry Predictions
1. A new industry group to develop standards for building web apps and content for low-cost, reduced capability devices
2. Aol to announce a major push for html and javascript apps on the desktop
3. new mobile computing device with a modem os and open deve platform.

All of the above came true 10 years ago:

1. The Network Computer Reference Platform - 1996 Sun, IBM, Apple
Replace Network with Mobile
2. Netscape Crossware 0 1997 apps build on javea javascript & html
3. AT&T/EO Communicator - 1994 - touch screen, handwriting recognition, live object embed, 33.6 kbps fax and data modem

Technology evolves, impetus the same

Build on Solid, Tested Foundations:
Storage - AOL Xdrive, Amazon S3
Message & Data Exchange - XMPP, JSON & REST based APIs to Open AIM
Publishing & Commenting - Atom
Idenity - Open ID, Open Auth

Web apps of the future need to run everywhere.

Learning from our past:
Small & beautiful beats large and clunky
Sweat the details, but don't sweat infrastructure
Let the service provides do the heavy lifting for you
Standards and openness are important
But employ with an eye towards security and trust
Technology moves faster than society
It's up to us to use it responsibly

http://dev.aol.com
aoki@aol.com

10:20am - Leah Culver - Pownce.com
Practical Lessons We Learned
Pownce - Social messaging application

Think about technology choices
We could pick anything - made from scratch
Social as well as technological reasons factored into our decisions
Took risks to work with newer technologies

Why Django?
Django is a Python web framework
Yah! Web frameworks!
Documentation and readability
Auto-generated admin

Why S3?
Amazon's Simple Storage Service
Pownce files are stored on S3
Less maintenance for Pownce
Inexpensive

Why Air?
Adobe Integrated Runtime
Works on both PC and Mac
Easy to develop
Encourages good UI

Do a lot with a little
Pownce has a tiny team
One website developer
Self-funded
Short deadline

Small Teams - we wear many shoes
Multiple roles
Learn quickly - I have had to learn a lot about everything
Dedicated

Open Source Tools
Plenty of web application help
Someone has solved this problem before
... and they're probably smarter than me
Lots of tools available

Use your Resources
Get some help
Documentation websites
IRC
Network and learn from friends
Exchange knowledge with other sites

Be kind to your database
Pownce's databse is its main bottleneck
One MySql database - a bit embarrassed about, not a dba
REsponding quickly to slow queries

Caching - I've already done that
Memcached
Caching at page and object/list level
Cached our static pages since launch

Queuing - I'll do that later
Taking a shorter note of a longer process to do later
We send notes via a job queue
Need to improve our queuing system

Limits and Pagination - I don't need to do all of that
Notes list, friends list, recipicient list
Good user interface as well

Index - I'll mark that
How would I search, set up database

Avoid Complexity: I won't make the db do that
Some queries are just to complicated for a new web app
Consider if they're actually needed
Usually good to avoid abstract or conceptual data display

Expect Anything
Young sites can run into many problems
Need to respond quickly
Can't prepare for everything - stuff with come out of hte blue
Every web app is different

Keep Backups - because stuff happens
Use version control
Have a system to revert to code changes
Tract dependencies and updates made
If developing locally, backup personal

Duly Noted - Keep lots of data
Stats to monitor
Quantitative data

Community - Keep in touch with your community
Let users know what you are doing
Respond to bug reports
Inform users of bug fixes and new features

Friendships Matter - Social sites are all about friends
Strive to make it easy to establish, maintain or break relationships
Accurately represent user relationships

Prepare to Scale UP - It's a good problem to have
Don't prematurely optimize
... unless you work with Kevin Rose
Design for success
Accept that your code will change

Questions -
Scope: Choosing a feature - think of what features people will use and what only a small group will use.
One person shop - We have several people working on it (Daniel on design, another person on desktop app), building on what others have already built on.
I am a believer in execution, lots of people have great ideas, but it is really how the features are done. It is about developing fast and getting it out there.
How cheap is it to start a web application - it is hosting costs, that is about it.
Are you doing unit testing - I am really bad at testing, that is one of my weaknesses. Don't tell anyone...

Morning Break....

11:30am - The Future of Presence
Jyri Engeström of Jaiku & Felix Petersen (zengstrom.com) of Plazes interviewed by Brian Oberkirch

Felix - We build an application that could locate a place on a network, be it a wireless device at Starbucks or a wired device's IP address. In the beginning it was a few nerds who liked adding information to a database, but how to make it interesting to others?
Where are you? What are you up to? Where will you be?
Brian - Where do you see your users are?
Felix - Yuu need users, to make it fun you need others in the same city to see what others are up to. Communities in Berlin, Amsterdam, Stockholm and San Francisco.

BO - Story of Jaiku
Jyri - We founded Jaiku a yar ago. How do we enable a social periffial vision? To stay close to the people we like. Where are we going? What are we doing? Jaiku focuses on your activity or presence stream by mobile, rss and entered text. Mobile is the most compelling platform. Picking up social availability and location.

Felix the need emerged that if folks are somewhere w/o their laptop, so the addition of mobile... Try not to be as dogmatic about presence, but what does the user want. Is that presence.
Brian - It adds information.
Felix - Coordinates don't give a lot of information. Just because something is close by doesn't mean you want it. Plazes tries to give more context.

Brian - How do you describe
Jyri - A lot a people are talking about microblogging, I think we are still figJyring out the language of this. Presence, permalink, history of your presence then it starts to look like a blog. The important part is to bring people closer together by giving this perifial vision.

Felix - When I started blogging in 2002 it was to reduce communication noise between my friends. Whoever wanted to read it, they can. I never wrote elaborate articles, but updates for my friends, a small group. When Flickr came along, updating photos from your mobile, it became a presence tool.

Jyri - Thoughts on the Social Graph (read this article) bradfitz.com/social-graph-problem
Interoperability or social network portability? The ability to import you friend list from one service to another. This only works if it is a network of the same issues.
This is a really a test if democracy on the net really works. I am doing a Ph.D on the history of technology. Telephones started as silos and phones only really started to take off when the networks became interoperability.
One service can't pretend to be the internet.

Felix - I agree with Jyri that it is more about interoperability and portability right now. Harmonization of the objects.
(Brian just put Jeremy's presence stream mash up with is tweet about having someone kicking Paul Graham in the nuts.)

Brian - Jyri this was a really important blog post for me
Jyri - My background is in sociology. Everything we do is important by a theory. Teh image that comes to people's mind is a graph of people's relationships. Problem - it assumes that people are just connected to people. But I am more interested in that people are always connected by objects. We are not in this room for a random reason, but because we are interested in presence. We have these kinds of containers for objects, pictures on Flickr, video on Youtube, presence on Plazes - Jaiku is reporting when new activity happens on these objects. Activity streams are reporting on the actions that people are doing to these objects.

Felix - Blogging was a step forward because you could comment on a post, do something to that post. What objects do we have in our Service - people, place, and time - then you can add activity to that. What are we now? A service or a community? That is five year old thinking, you have to connect with people to filter the them. Connecting to other people on Plazes is a matter of privacy. Plazes is a social service app.

Jyri - Everything I see on the web is about more fluidity. We shift interests so quickly these days, the community we have is dependent on the network you are in. Knot network - quickly get people together around the object that is interesting right now. Not a community that pours us in and closes.
Jaiku uses RSS to pull objects from various services, this is not perfect as it creates load for other services, this is not realtime. Also if you post a photo to flickr and Jaiku, there will be two objects with comments. Looking at using a java protocol to work in realtime.

Felix / Plazes is looking for Rails developers in Berlin.

12:05pm - Suw Charman
dat Suw Charman, she talks a lot.
2day: adopting kitties
with LOLCATZ slides

I iz ekzamenin evrehthin - what is your tech readiness? Does our tool actually work? Support readiness? Are you ready to support your customer? Support and Adoption are different sides of the same coin.
iz not ready t come out yet srsly
Don't try to sell your tool to enterprise if you are not ready. You only get one chance at enterprise. They won't come back in a year's time to see if you are ready, if your tool isn't ready they will find some tool that is.
Enterprise is not used to beta roll apps. They want something that works now with updates on occasion.
Have a process for feature requests. A roadmap for this is how we are going develop. If the customer asks you to jump, ask how it will fit your roadmap. You can run around in circles and the client still may not be happy.
ur wish? mai command? I dun think so
Don't assume that your software will be adopted. People are resistant to software adoption. People are resistant to change.
want!
Start with what do businesses want? with my tool?
Enterprise will want integration with their servers - single login - LDAP / active directory - make it easy for people to use your tool.
Security - Can our employees use your tool and will our data be safe? Technical and user security (against user stupidity)
Disaster recovery? If the worse happens, how will you help your customers recover their data?
iz ok can wait
u no unnerstan. dis not pakajing dis mai home
Slow downs - Big vendors may want to do a code review. It takes time. Contracts and lawyers. Internal political wrangling.
yoga cat iz fleksibl
Be flexible. You may have to host the service compared to selling someone a chunk of software that the client uses internally. Tojan Mice - IT is the department that likes to say no. They will take it and store it on a server to be ignored for a while or tested.
i has kaptchad teh balloon. i win
Be prepared for large scale success.
U fink we culd add a ruum in teh ruuf?
If you can't scale, that is a really good way to get your tool dropped. Be ready to scale fast.
dis need sum considereashun
Be ready to fail. Have processes in place to be able to change. Try to fail in new and innovative ways.
did sumwun call support?
Bundle in support costs into your prices that you are selling your tool at. You need to make sure that you can afford that you can help your clients get the best out of your tool.
i will ansa ur email one day. mebbe.
You take it for granted in the fact that people will be responsive when you have something to sell.
I is confuzled how dis work agin?
What kind of materials will you provide the client with?
dey say we alike dun see it maiself
Gathering people of like mind together to figure out what people need. People need really specific use cases.
bring me teh goal posts then i score
Adoption is not a business goal. Business is business's goal. Businesses want to get their job done quickly.
teh ansa u need is ryte here
Don't design documentation, design learning tools. Understand the different types of learning. 80% of learning that happens in business is informal. How can you provide ad hoc support? IRC? Blogs? Wikis? Collaborative support of users helping each other.
iz easy! let me sho u!
Provide materials for colleagues in business teach each other.
halp! i cant pull dis string alone!
mai url. let me sho u it
http://strange.corante.com/archives/2006/03/05/an_adoption_strategy_for_social_software_in_enterprise.php
thankful kitteh
want 2 no moar? strange.corante.com

2pm - The Semantic Web or Web Plumbing 101
The Semantic Web a decade old idea of Tim Brenners-Lee - sharing of data across the web
Why has it failed? Selfishness or ROI?
A Change is in the air... a bunch of web apps are changing this
Facebook is proving what you can do with the Semantic web. Open platform and API.
Practical techniques used when changing - simple structured feed
Less is More
doesn't work -> works
APIs : Soap -> Rest
Interaction Server-Side -> AJAX
Standards RDF+OWL -> Microformats
Dapper created to create a semantic layer over every website - ambitious
[Presentation or shill?]

2:35pm - Matt Biddulph of Dopplr
Riding on the shoulder of giants
Dopplr is a specialist social network, we have taken advantage that emerging standards and technologies to merge data from the web.
Dopplr is a website you should never have to visit.

A "platform" is a system that can be programmed and therefore customized by outside developers - users- and in that way, adapated to countless needs and niches that the platform's original..." Marc Andresson

Internet - small pieces loosely joined
Dopplr is built with Ruby on Rails

Sharing Data - simplest thing we can do on the internet
A really good social website uses data as a focal point.
Simplest way to get info/data out there: XML
Dopplr feed: rss, calendar feed, hcalendar - full of clues that is somewhat agnostic to the technology you want to extract it with
Dopplr is not on the open web, as it is a private network with your friends, but the feed can be accessed.

User Idenity - after data, people are the most important on a social networking site
You have accounts on many websites and have many idenities. Most important thing to me is to port your identity from one site to another, of which step one is OpenID. OpenId is not just for login.

Social Network
Dopplr has a number of social site import on the invite page. Using Mofo library for Ruby (microformats) mofo.rubyforge.org.
code.whytheluckystiff.net/hpricot - site scraping library
Gavin Bell - the best way for you to manage your network is to stop thinking about all of the little pieces and to start focusing on the big picture."

Delegating Authority - sometimes delegate authority to robots
bad practice to ask user for their username & password for another app, better to use the api of another app
Yahoo uses BBQuth
Google uses AuthSub
flickr uses Authentication
AOL uses OpenAuth
Easy to revoke by going to the providing to site to take away the power of Dopplr.
Dopplr is using OAuth - oauth.net - an open protocol to allow secure API authentication in a simple and standard method from desktop and web apps.

Widgets & Plugins - becoming more active
Facebook FA platform is an impressive bit of work, after a bit of work, I had something working on Facebook within an afternoon. I don't want to implement Dopplr in Facebook, just be able to echo some information.
facebook proxies directly to your server
facebook rewrites your HTML, CSS and JS
facebook caches what it can
facebook needs you to respond quickly
all made easy by Rfacebook now with Rails plugin rfacebook.rubyforge.org

Created a javascript badge for non-facebook sites, like a blog.

"Javascript is the extra layer above the markup and the css. It adds another layer to your site." (paraphrased) Christian Heillman
Jquery

Utility Computing
I am big fan of outsourcing everything I can - Basecamp for the team, Swosh for SVN, etc.
Widening the internet as platform.
Amazon S3 data storage - farm out your data serving. Use it to back up mysql database. Use rake file to make a mysqldump and backup to S3.
Pre-build EC2 Rails - I can bring up as many servers as much as I need them. The trick is that the data is not on EC2, so use MySQL Slave (replica database).

3:45pm - Joe Walker of DVR
Speaks on Comet

4:30pm - Tom Coates of Yahoo!
Head of Product at Yahoo! Brickhouse
FireEagle is a geo-service
Uses rails, oAuth, rss, etc.

Share your location online
Capture and make sense of your location
Share that location with your friends
Shore that location programmatically

Not launching with the name FireEagle

GeoApps
Get Location
Using Location
Problem too heavily meshed with each other.

There are lots of ways to get your location: IP address, Mac Address, Mobile, etc. Anyone who builds a geoapp has to both build both get & use.

A better model : a backbone for geo app
lots of sexy open apis to get: mobile, plazes, yahoo local, zonetag, etc
use: exact point, neighborhood, post town, state, country, cell phone ID, etc.

Open APIs mean anyone can build a client and anyone can access the data (with user's permission).

Clients on phones or websites capture location & share with FireEagle
A user manages how much info they want to share and with which services.
App authentication, mobile application

[ the idea is to be able to broadcast location so that other web services can localize their data for you... hmmm... Not sure what I think... I don't mind choicefully GPS tagging, in fact I like it, but only on occasion and now near my house.]

Very useful: nearby ICBM silos

Being honorable with your data : Privacy, Hiding and stuff like that
Why would I want to put this data anywhere?
Because it is profoundly useful and fun.
How much to share?
Exposing your logs to you - surface, open, possible to purge it. Can delete everything.

Hide me! Doing something naughty? Already created a hide me button...
Private places - drag a circle over a map and FireEagle would never show the location within the circle.

Forgetting that they're sharing?

http://fireeagle.research.yahoo.com

6pm - Final Session - Panel with Developers / Founders
Ryan Carson, Kevin Lawver, Lane Becker, Rashmi , Dick , Ted Rheingold, and Simon Willison - Brian Oberkirch as moderator.

Good and funny. All panelists had a good "How we started story". many were trying to improve skills or doing something that they loved or a problem they wanted to solve. Lane told a story about hanging out with Thor to avoid his consultant work with AP and then it turned into a funny rant.

Failures:
Ryan: Didn't invest enough in success.
Rashmi: One huge mistake, invite only when we launched. everytime we have been afraid, it has been bad. Being too cautious is a mistake. Second mistake, listening too much to advanced users.
Kevin: The biggest mistake is waiting for perfection, you either kill what you loved about it or you get sick of it. In Ficlets, we started in January and set the deadlines for SXSW in March.
Dick: Doing biz dev deals before we were ready to deal with it.
Ted: We lost more time making a rash decision rather than waiting for the right time.

List one thing you did do right:
Ryan: Make it as viral as possible.
Kevin: Start small and stay that way until you have to grow.
Lane: Figure out the hook. What is the smallest possible peace of this that solves a problem that companies want.
Rashmi: Ruby on Rails. Being agile. Don't think too much.
Dick: Keep A players in the company as long as possible.
Ted: Hire. I couldn't do it alone every night of the week.

Good conference. Big thanks to Carsonified and all the folks who worked hard to make this work.

Feedback: tinyurl.com/2rj3de