Andrew HumeAndrew Hume
Andrew SkinnerAndrew Skinneraim: nonsymmetric
Ben WardBen Wardaim: BenWardcouk
Chris StainthorpeChris Stainthorpe
Damien TannerDamien Tanner
Duncan PontingDuncan Pontingaim: duncanponting
Gavin MontagueGavin Montagueaim: gmontague
Jeremy KeithJeremy Keithaim: adactio
Joshua SierlesJoshua Sierlesaim: jsierles
Julian VirtueJulian Virtue
Levent AliLevent Aliaim: triplefury
Marcus MitchellMarcus Mitchell
Mark McLaughlinMark McLaughlinaim: markmkorn
Matt BaileyMatt Bailey
mike priddymike priddyaim:
Richard RutterRichard Rutteraim:
Robert SharlRobert Sharlaim:
Steven MarshallSteven Marshallaim: steviethebm
Stuart ColvilleStuart Colville
Tim BlairTim Blair
Andy BuddAndy Buddaim: theandybudd
Barry FrostBarry Frostaim: barryfrost78
Jonathan HeronJonathan Heronaim:
Lee ParryLee Parryaim:
Olly WillansOlly Willansaim:
Stig PalmquistStig Palmquist

Wednesday, 8 February 2006

Notes: Please add your name, if you contribute, to the 'Authors' section at the bottom of this file.


tag: futureofwebapps

10:00 - 10:45
Delicious - Things we've learned
Joshua Schachter - Delicious

    - painful to deal with
    - JS gonna be different
    - Opera users are whiners
    - CSS not great everywhere
    - IE caching
    - Fx Extensions
    - Muchos pain

    - not recommended

    - you can't predict the problems
    - Read Cal Henderson/Brad Fitzpatrick's
LiveJournal stuff on how to make things faster
    - Think how to split data, get things on multiple machines
    - Understand indexing, test every query for performance
    - Set up monitoring
- eg Nagios
    - Tags don't map well to SQL
        - Have seperate tables to 'stash' indexes

        - no-one is going to view page 100 unless they are a bot

    - prune DB for efficient indexes
    - Use caching wherever possible
        - 'Is this resource out of date? When was it updated?'
    - Understand where legacy is ok
        - is it ok if something takes 10 seconds to show up somewhere?
        - e.g. RSS doesn't need to be instant
    - be sloppy wherever you can!

    - Greasemonkey
    - Idiots are smarter than you
    - Your defenses aren't gonna be right
    - Don't fix things before they break

    - Learn Apache intimately
    - tuning
    - mod_rewrite : a dark art.
    - Put a non-apache proxy in front
    - A dial-up user could be sitting there tying up lots of resources

    - Images, RSS, everything from seperate servers
    - Proxy can merge all of this, and provide throttling
    - mod_throttle
    - use perlbal(
    - IE 'Make available for offline use' is an arese   

    - Joshua built an API early on

    - Helps adoption.
    - We geeks love this stuff - take dataand put it elsewhere
    - make thge API easy for user to get and out of - helps adoption    
    - If you use SOAP etc., it's haaard
    - Make things easy: GET requests, PUT requests. EASY as π
    - No need for API keys, can play straight away
    - Hundreds of delicious plugins

    - UIDs a mistake for scaling
    - Don't expose this to the outside world
        - Someone will try to iterate to scrape the DB, especially if sequential or computable

        - Use md5 of url to access data


    - features you add are as important as features you leave out
        - Influence behaviour
    - Dropdowns would have changed user behaviour, maybe made delicious less successful
    - Leave out stuff that exists
        - No messaging: e-mail exists already, so why bother?

    - build what people will use.  not what they ask for.

        - Get to the ~why~ they're asking for that, extract a story/use case
        - Then you can solve the problem, not add another feature
        - Delicious lets you look for things that have a tag, people want insane logic queries: that's hard to make it fast.

        - People ask for 'set' queries "EVERYTHING THAT ISN'T 'webdesign' but             less than 1% of queries even use a simple 2 tag query.

    - native representation of a list/pile of links
    - Another way lin/out of the system
    - Everything that could have a feed should
    - Need to understand headers, caching, feed-reader behaviour
- stash the timestamp saves a trip to the DB
        - RSS traffic more than anything else in the system

        - RSS readers are easy to write (badly).  This causes big traffic.

    - Make them follow the use of the site
    - People will be pasting them around
    - No session keys

    - No-one cares about the implementation/framework, get rid of it
    - Way to expose functionality to ultra-core
priesthood(?) types (us!)
        -Doesn't need UI


    - Watch out for new behaviours
        - Amplify
        - Ignore
        - Dampen
    - Bookmarking a page of delicious bookmarks
(to create a 'conversation')

    - Solve a problem you have
    - Text file -> Web over DB
(single user) -> Larger web over DB (multi-user)
    - Solve a problem YOU have
        - Someone else passionate about a problem will solve it better than you
    - Easy to start
        - Small problems acceptable, given advertising and revenue


    - Closed betas, limited releases, etc. -
Horrible idea
    - Every day of closedness is another day without real experience
+ picking up users
        - lots of loss
        - ideas and suggestions missed

    - Aggregation is interesting, gets attention
. People pay attention to the attention.
    - Works for small population with obvious bias
    - As population increases, bias drifts
        - becomes less popular overall
as the bias gets weaker
        - more focused aggregation/fragmentation becomes interesting

    - Spag - Tag spam?!?
    - Social systems get spammed

    - Attention theft
    - No top 10 on
        - Slashdot, google, yahoo, whatever
    - Becomes an attractive nuisance
    - Don't provide feedback to spammers
        - let them think things are still working

    - Not about classification
it's about user interface
    - Way to store working state/context
    - Useful for recall
    - Kinda useful for recovery

    - Awful for distribution
    - Not all metadata is tags
    - Value is in attention

- automatic tags are less valuable
    - Auto-tagging not very helpful for users
    - Sites linking into delicious ("add to delicious") allows prefilling of the description but not the tags
    - Transaction cost makes system stronger - don't make tagging too easy - make the user think a bit
    - Too dif
ficult makes it unlikely to be used
    - Too easy makes it easy to be a waste

    - beware librarians
        - No absolute description of tags

    - Delcious base case is for a selfish use

    - Make it useful for 1 user, it'll be useful for others
    - Collaboration not necessarily useful
        - Look for payoff to YOU, not others
        - Money fucks other factors
    - Make users you have want to bring people to the system
    - Evangelism, free promotion

    - Beware where you spend your effort
    - watch where you spend your time scaling, adding features, etc.

    - Watch your system carefully
Intuition is guesswork backed by numbers?
    - Do survivorship analysis
        - Is a user using something in week 1 using it in week 5?
    - How are users reacting to features, details, whatever

    - Be sure to measure behavior rather than claims
    - No star rating system you either bookmark it or not.  Why would a user bookmark a one * site?

    - UA testing
    - Features you're building actually matches user expectation
one to two days user testing with entire team in the back row and impartial interviewer
    - Everybody on the team should see this
        - People not there won't believe you
    - Labs are great, but expensive
Ghetto testing.  Do it in Starbucks?
    - Don't give goal-based testing
        - Causes different behaviour, not what happens in real life
    - Let people wander off of the beaten track
Worked with Creative Good in NYC

    - Speak the user's language
    - The vast majority of users don't know the concept of 'bookmarks' form NN
(bloody IE users)
Talk to users in their own language.
    - Don't make users speak your language

    - Don't make users register to get in

    - Give them as much functionality as possible
    - Let them use the system anonymously beforehand?
    - Users don't want to sign their life away and put in effort for no benefit
        - let them test first
    - You can't tell them, let them explore and find out themselves
    - make it as short and sweet as possible, and put them back where they were

Design Grammar

    - Understand where you break from the norm
    - Try to use commonly accepted terms elsewhere
- Don't re-invent the wheel
    - Breadcrumb trails, logo top left, etc.
    - Develop a sense of morals

        - In terms of data, how people are dealt with
    - User's data, not yours
        - They allow you to use it, not you allowing them to use your system
    - Let them remove themselves, their data, their account
    - has no transaction log 'cos the data is purged totally from the system
        - Important to allow this for accidental addition

    - How to promote systems

    - 0 dollars, no ads, nothing
    - Enable evangelism
        - Make people want to get others into the system
    - RSS

        - Turn every RSS reader into a client app
    - Add functionality to the feed itself
Viral vectors
    - Figure out what apps look at and talk to, figure out how to get in there

    - How communities use your system
    - Don't think your system has one unless you're trying to build exactly that
No threading no comments, it's a tool not a community
    - Let communites ~use~ the application, but don't own it.
    - Avoid flame wars and so forth
    - Enable communities ot use your system, don't force it


From web site to web application - Ten reasons to love web 2.0
Cal Henderson - Flickr
(From web site to web application)

    - Flickr
    - Web 2.0
- term invented by Tim O'reilly
        - Kinda awesome
        - Name for a bunch of technologies combined
    - Birthday!
        - In San Fran
        - Everyone's invited! Free CAKE! w00t!
sico.  There will be cake!

Passionate users
    - Important to flickr
    - Devs passionate too
    - People don't start business to make money
        - S'cos they care about what they're doing
    - Passionate devs = passionate users
    - Less likely to make people care if we don't
    - Users wants != user needs
    - Don't listen
to your users
        - They'll tell you what they ~think~ they want, not what they really want
    - Watch behaviour to understand needs
        - Even if they don't realise it, this'll make them passionate
    - Look at behaviour rather than what they say they need

1. Collaboration
    - Two 'lovely gentlemen'
        - I'd call them old geezers

        - playing on a tablet PC
        - With dreadful shirts on

    - Before flickr, there was game neverending
        - real-time MMO
    - flickr = MMO photo sharing
        - friends
        - social network
    - Already lots of photo uploading things
    - Flickr's niche is the social aspect
    - Bottom-up social network
    - Create incentives to add to the network
    - Add fri
ends makes flickr better for me
    - Collaborative metadata
        - tagging my own for organisation
        - tag friends' stuff

        - Contacts can edit/collaborate by default

2. Aggregation
    - Previous apps silod by user

    - Each user has their 'ghettoised' space

    - Show latest stuff from everyone
        - Daily popular
        - lots of other interesting 'slices'
        - tags
        - geo-location
        - interestingness
(proprietary algorithm based on activity round a pic)
    - Aggregation isn't necessarily about smushing everything together

3. Open APIs
    - API = web service API (obviously)
    - REST, SOAP, CORBA, XML-RPC (and probably some other candidates for Buzzword Bingo)
    - flickr had one since the dawn'atime
Original API was built for use by Flickr in the Ajax routines.
    - flickr wasn't first, but was early for impact
    - Read only stuff first
(RSS etc), write later?
        - Lots of value off the bat
        - Later, interaction added
    - Flickr becomes about that data more than the site - all the apps that work      off it.
    - Allows others to build really interesting seques that maybe wouldnt' have been thought of by original devs
    - FASTR - multiplayer game, shows photos guess the common tag.
        - All flickr did was build an API
    - People will do this anyway, API just makes it easier and more transparent
        - Allows optimisation


4. Clean URLs
    - Expose logical, not 'physical' structure
    - Not the filename
    - mod_rewrite
- doesn't have to point ot a physical resource/file
        - Directories are virtual

    - Allows 'hackable' URLs
        - Power-user type thing, but good
    - If you want links, the URLs have to be permanent, unchanging, and never break
        - URLs to photos in flickr are shit

        - Original URLS were ../photos/12 didn't scale.

        - This will come back to hurt you
    - Think about URLs EARLY
.  URLS are for LIFE!

    - Named by JJ Garrett
        - Previously called remoting, remote scripting, etc.
    - AJAX - only the A is important.
    - not necessarily about xml
, can use JSON etc
    - Not necessarily about JavaScript 'cos it could be in VBScript (for IE only)
    - XMLHttpRequest is also badly named for similar reasons
    - AJAX client side, server 'scripting' other end
    - Client side all based on server-side API
    - Primarily, in flickr, used for speeding already extant interactions
        - Make 2 steps into 1
        - Also makes bandwidth savings
- data moved through Ajax is smaller in size compared to 2 page loads
    - Creating whole new experiences, but lesser use
        - Is this really good? Jeremy might have a fit if people do this...
(only is it's not done Unobtrusively?)
        - Allow URLs for clear addressing of different parts of systems
6. Unicode
(picture of rosetta stone)
i18n, l10n - Internationalization and Localisation
    - i18n means supporting different locales
        - displaying other character sets, date formats, number formats, cheese flavours
    - l10n mans translation of UI into other languages
    - i18n first, l10n later
    -Do you want i18n from the beginning?
        - Store using Unicode
        - Store almost any character in almost any language
        - Bajillions of code points
    - Store data, present, whatever, in UTF8 (ASCII-transparent)
    - UTF8 supported by most modern browsers, UTF8 degrades for others
    - UTF16 ~doesn't~ degrade so well: 2 bytes to represent each character

7. Desktop/platform integration
    - Dont' lock interactions to the browser
    - Pull these to other platforms
        - APIs!!!
    - flickr uploaders, for example
        - OS X widget
iPhoto plugin
        - etc.
    - Browser widgets for file transfer sucks. only allows one file upload per input
    - Avoid suckiness of the web

        - file uploads + browser = terrible user experience

    - Browser plugins/bookmarklets
        - Flock takes this to another level entirely
        - More complex integration possible using XUL or whatever
        - Also Windows Presentation Foundation (née Avalon) using XAML
            - This isn't true, exactly, but y'know
    - Email integration
        - Everyone has email
(“Using existing infrastructure that people already have”)
        - but not often included in webapps.
        - Available on mobile platforms (cheaper than MMS)
            - MMS is a rip-off
- email a photo == instant uploader
- got to handle about a million different email and attachment formats though!  

    - flickr has it's wn, stupid messaging system
8. Mobile
    - Everyone loves WAP :D
    - 'Standards' for mobiles have been shit until now

        - everyone either uses Opera (great!) or Proprietary browsers

        - They're now starting to support XHTML:Mobile
- subset of XHTML 1.0
          Note: XHTML Mobile Profile extends XHTML Basic

        - Proprietary stuff makes Baby Fatty cry
    - Building content for mobile isn't a matter of sticking another skin on your app
        - Mobiles don't have a 20" display to give you 400 comments in a thread at once
        - Dont' just re-0present the same content
        - Make things easy to consume and lightweight
- different thumbnails for mobile devices. Less metadata.
        - Mobile use is different to desktop use :o

Note to Rich and Andy and Jeremy: These seats are more comfortable than the ones at d.C :P
(I'll second that)

9. Open data
    - Let users take their data with them
    - Provide methods to allow export
    - This draws people in, and gives them a (false?) sense of security
    - Don't just do this for primary sources
        - Tags, metadata, comments???

10. Open Content
    - Previously, upload means ownage
        - Google video own your content
        - Flickr is different, users still own their own stuff, offer CC licensing
- CC licenses are available to users.
    - Allows reuse, remix, etc.
        - Apparently, someone made a song of photos CC'd photos on flickr
            - See it at

All photos in presentation from flickr, CC with attribution :D

Slides available at


Native to a Web of Data
Tom Coates
( - Yahoo

Fucking loads of us!

Hello London!
    - Only been at Yahoo! a few months

Design and Web 2.0
    - Round corners

    - Omnigraffle

    - Gradients
        - Rollyo
        - Blogger
started some of these design trends
        - Use of Macs
    - Products that fit and thrive inside their environment

What is the web changing into?
    - Web 2.0
        - Buzzword, conference, marketing, new bubble, all of these and less?
i.e. Money generator
        - Tim O'Reilly did a meme map (
        - Tag cloud by Marcus Angerme
ier (
    - Can't support everything that is under it
    - Moving from connections by links to data sources connected by APIs
    - Silos of info with links to a huge aggregate of testicles
         - A load of bollocks, for those who don't get it.
         - Data is connected like it never used to be.
    - 'A web of data sources, services for exploring and manipulating data, and ways that users can connect them together'
    - A web of data -> A web of mash-ups -> ?
    - Yahoo astronewsology
( l:yahoo, p:yahoo but don't tell anyone
        - Yahoo news + yahoo astrology
        - Browse news by 'things that happened to capricorns'
        - Compare what was meant to happen with what did
    - Navigating one data source in terms of another
        - 2 is interesting, 3 is useful, 6 is cool, becomes a network
    - A network effect of services
        - Every new service can build on top of every other service - the web becomees a true platform
        - Every service and piece of data […]
        - Massive creative possibilities
        - Accelerating innovation
        - Increasingly competitive
        - Increasingly componentised services
        - Increasingly specialised services
    - There ~is~ money to be made
        - Use APIs to drive people to your stuff
            - BBC making everything uniquely addressable
(Program Information Pages)
            - Happening on Radio 3
and Radio 4 websites
            - Amazon a prime example
        - Make your service more attractive and useful with less central development
        - Use syndicated content as a platform
            - Google maps + google ads = more targeting

            - SuprGlu (small scale, personal feed munging. e.g

        - Turn your API into a pay-for service
            - Puts hippies into the same ecosystem as business people
        - No open data leaves you in a backwater hovel

Choosing what to build
    - What can I build that will make the whole Web better?
        - How can I add value to the aggregate web?
    - A web of data sources, services for exploring and manipulating data, and ways that users can […]
    - 'The race is on to own certain classes of core data: location, identity, calendaring of public events, product identifiers and namespaces' Tim O'Reilly, "What is Web 2.0?"
    - In many cases … there may be an opportunity for an Intel Inside play […]
    - Navigation is increasingly important
        - The best navigation wins
            - 1. Navigate
            - 2. …
            - 3. Profit!
        - If you can find a place in there, you can take advantage

Architectural princip
    - What you should do to be part of this ecosystem
    - From work with Matt Biddulph 'The A
pplication of Weblike Design to Data: Designing for Data Reuse' (
    - Core components
        - Data sources
Standard ways of representing data
        - IDs & URLs
        - Mechanisms for distributing data
        - Ways to interact with/enhance data
        - Rights frameworks and financial
            - This one is key
    1. Add value to the aggregate web
    2. Build for normal users, developers, and machines
        - Normals just consume
        - Devs look for hooks to build
        - Machines mean predictability, let them read and track
    3. Start designing with data, not pages
        - Data is reusable, pages aren't
        - Data will spread, pages are just your interface
        - Represent it properly in one way
        - Design it in web-like ways THEN manifest as pages
        - Data is rich and consistent for pages, comprehendible for exploration and comprehension by humans
    4. Identify your first order objects and make them addressable
        - Core items: BBC - program
mes, flickr - photos, Upcoming - events
        - Give these unique, well structured URLs
        - This makes it useful to search, technorati (aggregators), communities (digg),

        - The annotation post Tom displayed (

    5. Readable, reliable and hackable URLs
        - Good URLs should
            - be permanent reference
            - have a 1-1 correlation with concepts
            - use directories to represent hierarchies
            - not reflect the underlying technology
                - NOT index.php, .aspx, .blah
                - this WILL change
            - Reflect the structure of the data
                - Rebroadcast shows mean this isn't necessarily easy
            - Be predictable/guessable/hackable

                - Meaningful == Predictable

            - Be as human readable as possible

            - Be - or expose - identifiers
                - Don't expose DB IDs, but expose something unique and open
                - incorporate URL into page?
            - Good URLs are a mark of quality
    6. Correlate with external identifier schemes (or coin a new standard)
        - some things don't correlate with URLs or originate there
        - If 100 people are talking about 1 thing, correlate it
- Unified Identity
- Ben's profile.xml idea... ;) URL?
            - So-called "Identity 2.0" (

    7. Build list views and batch manipulation interfaces
        - Only 3 types of pages:
            - destination page: a core first-order concept and its subordinate info
            - List-view page: a slice of your data used to navigate between first-order concepts
            - Manipulation interface: interface for batch manipulation of first-order concepts
            - AJAX - DON'T BREAK THE WEB. More to make Jeremy cry, if you do.
                - Should only be used to change the current concept - manipulate the current list, data for item, whatever
        - Flickr example of Ajax/Flashy UI enhancements that don't break the web
        - Odeo example: page for every podcast, flash widgets to explore data
    - Parallel data representation
        - APIs cover all three page types
        - Microformats cover destinations and lists
        - Parallel XML and RSS cover both, but separately
            - RSS is the Unix pipe of the net
    9. Make your data as discoverable as possible
        - If you do everything above, this should be free?

Available later on

Font is Alega light


Ruby on Rails
David Heinemeier Hansson - 37 Signals
DHH personal blog:

Motivation - key to productivity (silver bullet)

    - comes from happiness

- optimise for happiness
    - happiness -> motivation -> productivity
    - How?
        - Coding may not be exciting

Beautiful code can be exciting
    - aesthetically pleasing
    - right
    - beautiful

Your application is not a unique snowflake
    - You are not special
    - I am.
    - Hard for people to deal with
    - Most work revolves around same details as everyone else
    - RoR is for: What most people do the same most of the time
- we're aiming for the 80%
        - this can be optimised
        - special stuff can't, and can't be abstracted
        - people need to believe in the 80:20 rule

        - solve 80% of problems for 80% of people, 80% of the time

Convention over configuration
    - Way too much config in software
    - Tell everything and everyone what you just did.
        - Tell the same stuff over and over and over and over and over and over and over and over and over
    - Repetition is ugliness - (DRY - Don't Repeat Yourself)
    - most frameworks take lots of time describing this stuff
    - assume conventions be default, allow overriding
        - classes singular, tables plural
            - allows removal of explicit linking
            - becomes more reliable
        - Primary key
            - assume "id" by default
        - Associations
            - foreign keys/other classes become implicit based on name
    - Configuration can still be done, if needs be!
    - Controllers
        - Model, View, Controller model
        - Controller relies on convention that naming on server and client side should correspond
        - If app is called 'weblog', the controller is called '
        - Corresponds to URI, no need for mod_rewrite
- Nothing to configure - mapping is all implicit
        - Actions also map to URI: e.g.

Flexibility is overrated
    - More flexibility !~= good
    - Giving valuable properties of system away for flexibility
    - Stop chasing it so religiously

Constraints are liberating
    - Following constraints give consistency to systems

    - get things in return - systems are consistent - free us up to just coding what app should do
    - Other devs can jump in and 'get it'
    - Who cares what the underlying shit is called, just let the framework handle that

Doing the Right thing
    - Not always easy to do
    - Starting development the programmer has the devil in one ear and an angel in the other

    - Environment determines the size of the temptations to not do the right thing
        - 'You can clean this up later'

        - 'It doesn't matter if others know how this works'
    - Seems like things get done more quickly
    - 'Angel' encourages testing, standards, conventions, consistency, best practices

    - David did PHP for 5 years before Ruby
    - Not about possible/impossible, about encourage/discourage
PHP is the devil (see below.)
        - Constant temptation to hack
        - Language is built in this way
        - Could fight this, but it's hard when pressure is on

        - 5000 methods in one namespace encourages you to be a slob
    - Ruby on Rails is the angel

    - easily do the right thing
Invitations to do better
    - automatically producing test files
when you create a class (controller)
    - auto reminders to build tests on build

        - test file auto generated - in test directory \test\test_helper.rb
    - learn more
    - become a better dev
    - allow common patterns, but show a better way
        - many-many relationship causes issues, use 'join models' instead: many-one-many, allowing attributes on the middle 'one' link

        - e.g. rather than having many-many join between authors and books, use a seperate 'authorship' model

    - Expected to use best practice
    - If code is posted
to the RoR mailing list without tests or with odd config, people ask why that way?”

More beauty
    - Transactions
        - If something goes wrong in the current scope, roll back to before the action
        - Are these as slow in Ruby on Rails as they are in SQL Server?!
        - uses locking in a 'do … end' structure
    - Extending the language
        - Domain specific languages, new keywords
            - validation
                - requires input of certain data items
                - pseudo-human readable
                - handled auto-magically in the View

            - association
                - point of reference in the URL, unique ID (refer to a project in BaseCamp)
                - a project has things (manager, milestones, etc.)
                - belongs to something (portfolio)
                - pseudo-human readable again
            - intelligent scoping of association
            - common usage
                - allows traversal within current scope
                - obvious reusable features are defined so that they can be accessed simply
            - domain specific features
                 - stupid idea to track sessions for an RSS feed
                 - shouldn't be able to directly access the comment function without having been to a post
            - encourages cross-domain work

                - Use Ruby for everything

                - dont' do DB separate from API separate from UI
                - allows XML DOM work to generate XML (RSS, whatever)
                - allows configuration

                - It is still possible to get out of Rail's extraction and just run a simple sql statement

When to use Rails
    - When you feel the hurt (from lack of structure, consistency, degrading productivity over time, overburdened by complexity)
    - You appreciate agile (functional specs evil, unit/functional test good)
        - Domain models
    - You can skip the vendor
        - "I'm not here for you"
        - Doing rails for own benefit
        - Solutions to problems of contributors

But does it scale?
    - Yes


2:30 - 3:15
10 Reasons Why You Need to Build an API
Shaun Inman - Mint

What is an API?
    - "API's take a good thing and make it better"
    - A documented means of interacting with one application from another
    - A successful API obscures the storage format of the requested data as well as the details of the retrieval process
facilitates requesting data, manipulating
    - successful - obscures data storage
    - No matter where data is stored, you can retrieve it
    - ATM is API (example for non techies)
    - Every company represented at Carson Summit has an API be it public or private
    - who is using API's
sites, widgets,

Now, about those ten reasons:
1. Increase brand awareness
    - APIs not mea
ningful to lay people, you care about uses
    - You see the brand everywhere (used by early adopting techies), this influences others
    - empowering users to do stuff
    - people talk about what empowers them
        - Something that's not been done before gets talked about

2. Allow users to own their own data

3. Build goodwill with developers
    - Saves people doing the same thing over and over
    - Save yourself the trouble of doing something if it's already available

4. Perfect excuse for community
    - API allows anyone to extend functionality
    - Generates community

    - share knowled
ge - pulling people together  - explain stuff, shows your knowledge
    - Explaining to others proves you know it

5. Solving programming problems with an API in mind can improve code quality
    - If others are going to use what you're working with, you're going to be more careful in your decisions
    - Helps you clarify your mental model
6. Simplify internal  reuse of data

7. Allow others to extend the functionality of your application
    - Lets others create features you have absolutely no interest in developing

8. Alternate input mechanisms
    - Allows devs to create other ways (client apps) to edit your data
    - e.g. Desktop software
    - e.g. Cross-site input (‘Blog This’ in Flickr uses the Wordpress (et al) API to directly create new posts)

9. Unanticipated applications of your data
    - MASHUPS :D
    - Unexpected, unanticipated use of data
        - Google map of Chicago crime, browse by severity, cop beat
        - Online version of "RISK" using Google Earth maps (now pulled by copyright owner)

10. Turning your program into a platform
    - Your application becomes a necessity as people build tools on top of it
    - Win32 was useles until everyone released applications that relied on it.
    - Lots of webby examples (google, yahoo, backpack, mint, blah, blah, blah)


What is mint:
Stats package with an API called Pepper to allow new views, plugins, whatever

How much value is added as a result of community:
A great deal. Mint is a framework with an API. It would just track hit times.
All base features of Mint are implemented as Peppers (plugins).
Same with blogin tools: templates etc.

What type of API is Pepper:
Plugin + Server + Ajax
Uses Ajax to serve related info in panes
RSS a ‘read-only API’

Users have to have direct DB access
Mint expires rows in DB based on time/DB size
Pepper devs want to store stuff in seperate table, but their table is 'invisible' to mint

How soon after releasing mint were peppers released:
On release, API not final, and undocumented.
First in 2 days

(…Lots we missed…)

Without Shortstat, would there have been Mint?:
Probably not. Shortstat defined by Shaun's needs. Met people who had similar needs/wants.

How has Shaun dealt with Piracy in the face of mint being public source, but not Open source?
Didn't want to use an encoding engine 'cos it places additional requirements on the host. Hit or miss on support - no support or outdated.
Just put comments in code around activation, if changed, not being clever.

How concerned is Shaun about guaranteeing his service is available tomorrow?
Not really, it seems: the source is available, so who cares?

Were the 10 reasons lessons from Mint, or goals for it?
More 'learned from', rather than 'looked to'
- Not followed step by step.


3:15 - 3:30
Adobe Flex 2
Andrew Shorten - Adobe
(formerly Macromedia)

Currently in beta, sharing with the community
    - we have this in our pack

Working with Enterprise customers in 18 months
Transform the products of this into something for everyone
    - Flex

    - Possible alternative to AJAX

AJAX and Flex share web 2.0 themes
    - Engaging user experience
    - Seperation of data and UI
        - RSS feeds, public APIs, Open data formates
    - Information comes to the user
    - Standards-based development
        - HTTP, XML, ECMAScript
    - Tried to stick to AJAX principals

Why Flex?
    - AJAX is limited by the browser
        - Not designed for high performance UI rendering
        - Limited number of built-in UI controls
        - True write-once, cross browser/platform delivery is still a dream
            - *cough* mobile *cough*
        - Lack of integrated audio, video capabilities
            - which is really needed in a document :D
        - No bi-directional real-time messaging support
            - hard work
        - Data connectivity limited to XML over HTTP
        - No local data storage for online/offline working
            - working on the train not possible (without wifi on the train)
        - Difficult to make accessible (screen reader support)
            - Possible, but difficult
    - Flex delivers the framework, components, tools and servers to build AJAX like applications that leverage the Flash Player
        - bypass the browser for a consistent platform

What is Flash?
    - No longer client runtime
(skip intro's etc)
    - Application platform
    - 'The leading platform for delivering effective user experiences across browsers, operating systems, and devices'
    - Now on mobile platforms too (Flash Lite)
    - Most 'expressive medium' for content
    - Ubiquitous

    - Flash 8 includes streaming media capabilities (not on Linux yet: Flash 8.5 in beta now/soon)

    - Effective UI for strategic applications
    - Most versatile endpoint for communications

Widest reach in the world
Claims 98% market penetration
        - Is this really right?

        - No idea. But a lot of the new JavaScript-based stats packages can record the specific Flash Player version, beyond just the presence of Flash.

        - This includes all versions I guess, so includes people with Version 4 of the player

    - All platforms, many devices
    - Browsers take a long time to acheive install base.
    - Flash Player 8 allegedly has 350m installs, 5 million a day, since launch

What is Flex?
    - Flex enables developers to build applications that deploy to the Flash Player
    - MXML/ActionScript/CSS over Flex Class Library
        MXML | ActionScript | CSS
            Flex Class Library
    - Compiles to Flash file to put on any ol' server
    - Executed on client side
    - Option to use XML/SOAP/…

Messaging applications
    - Real-time data sharing, no polling
- Does this require flash comms server?
    - Singleton data access (one file, many concurrent authors… sound familiar?)
    - Data rich apps with less overhead

Beyond AJAX: When to use Flex…
    - Guided service
        - Interaction from two sides (support)
    - Media rich applications
        - Video/audio/image
    - Data management/composite applications
        - CRM
    - Data visualisation/collaboration
        - Big hairy data

AJAX and Flex together = Better experiences
- blog analysis tools

Product Line
    - Flex Framework
        - Class Library
        - Utilities
     - FlexBuilder 2
        - Visual designer
        - Code editor
        - Debugging
        - Integration with Eclipse
     - Flex Enterprise Services
        - Automated testing
        -Data services
        - …

-  This all looks rather expensive? - Some of it is Open Source, I think (FlexBuilder built on top of Eclipse). If not, there *are* Open Source development tools for Flex, they were demoed at d.Construct last year by Aral Balkan,Thanks for that :) Adobe + software = cash*100 normally you see ;D Really? I'm pretty sure I read last week that there was… If there is that's cool I think it was on Daring Fireball, something to do with ‘if there's no UBin for Flash, then Safari would have to run through Rosetta, and it doesn't so there is… I didn't look too closely, since a MacBookPro is somewhat out of range for now… Something like that, anyway.

    - Player is free of charge
    - Free of charge SDK
        - Compiler
        - Documentation
        - Samples
        - Flex source
    - Free of charge application deployment
    - (Optional) Free of charge Flex Enterprise Services server
        - limited to single server
        - limited to ma
ximum number of connections
    - Flex Builder IDE < $1000


3:45 - 4:30
How to Build an Enterprise Web App on a Budget
Ryan Carson - DropSend

What's the big deal?
    - You don't have to be big anymore
    - Why now?
        - Broadband is widespread
        - People are more comfortable with web apps
(Gmail, online banking)
        - Hardware is cheap - no need to spend £5m
        - Open source is cheap

What's enterprise?
    - Debatable, but mainly
        - Mass market or 1000+ users

on a budget?
    - Under £30k

    - £30k is the minimum spend to bring an enterprise product to market

DropSend - Enterprise and on a budget
    - For sending and storing large files
    - 10 meg file, can't e-mail
    - Don't wanna explain FTP to clients/parents/idiots
    - Sending and storing large files
        - Personal need
    - 9500+ worldwide users in 2 months
    - 5 servers at 365 Main
- bitpusher
    - Desktop apps which use API
        - Mac, Windows
        - API public soon
    - PHP, AJAX, MySQL

The most important thing
    - Make sure your idea is financially viable
        - Use common sense - will people actually pay for it?
        - Be cautious about your projections
            - With web apps, it's complete and utter guess work
        - 65% and still in business

            - pessimistic projection and cut by 45%
... So they anticipated 110% initially :s
        -Acquisition my ass - aim for profit from the beginning
            - don't hope to be acquired, it's not a sure thing
            - very large bet
        - Forget about the 'is this another bubble?' stuff
            - Compelling, viable applications will last

The budget
    - Different budgets for different apps
    - Burtally honest about the figures

Show me the money!
    - Branding and UI Design: £5,000 (Ryan Shelton)

        - (slightly cheap) most important aspect is UI though

“UI design most important aspect of a new app. Without it you're screwed”
    - Development: £8,500 (Plum Digital Media)
        - Not developers, outsourced dev work
        - Another deal
to reduce costs by offering a percentage of equity
    - Desktop Apps: £2,750
    - XHTML/CSS: £1,600
        - Someone amazing, but not telling
            - Not sure I agree about this, looking at their markup...

            not too bad?

    - Hardware
(for development): £500
        - Crappy Linux box + freelancer
    - Hosting/Maintenance: £800/month (
        - for 5 boxes, including architecting the hosting platform

    - Legal: £2,630
    - Accounting: £500
        - Figure out invoicing for web app payment, etc.
    - Linux specialist (dev box): £500
        - set up virtual hosts, SVN, etc.
    - Misc.: £1950
        - Random other stuff
    - Trademark: £250
        - If you spend time on your logo, it's worth making it a trademark
        - Don't bother with a lawyer unless it's a 'controversial' name
        - Do it early, before finishing branding
Online merchant account: £200
        - Natwest 'Streamline' account
        - Taking 'recurring payments' is too risky for Natwest
        - HBOS is more helpful
    - Payment processor: £500
        - Someone to take the transactions
- Secure Trading
    - Total: £25,680
        - sounds a lot, spent over a long time
    - Have a side-business to fund your idea (Carson Workshops funds Carson Systems projects)
     - Find out when costs will hapen, plan cashflow around them.

The reality
    - It took about 1 year to save the cash
    - If it takes some time, it's OK!
        - Time to learn and become a more mature organisation

How to build your team on a budget

    - Don't go for rock stars - go for quiet talent
        - Not neccessarily well known, but good
Offer a small percentage of the product equity [2-5%]
        - If you get acquired, it's a thankyou
    - Ask friends for recommendations [Bad people waste ££]
        - You'll have to undo their shit work
    - Outsource

        - Amazing dev in India / central Europe --> tried India, didn't really work
        - Reksoft in St. Petersburg, Russia seem ok, I guess, even if they are taking my bloody job. €20-€30/hour

Scalability on a budget
    - crux of the issue with enterprise web apps (must scale!)
    - Have to scale for enterprise, but can't afford hardware early on
    - Buy just enough hardware to launch
        - flickr started like this

        - Don't go insane with money 'cos it might fail and you'll look silly

        - look like idioits if it breaks is not worth it - wait! - wait till see if app is successful before throwing money at it
    - Build your app so it easily scales
        - Think about what you'll do if you run out of disk space?
            - Can you plug in a disk/add a new machine, and it's fine?
- think about things ahead of time
    - Plan, but don't obsess
        - It sucks to do this
        - Worry when your app succeeds

How to keep it cheap
    - Don't spend money unless you have to
        - Don't buy stuff unless you're 100% certain you really need it
        - No stationery - They wasted £1000 on Dropsend stationary. Dumb.
        - No new shiny machines
        - No luxuries
            - don't get new machines
            - don't get a company car
            - etc.
        - No froo-froo
(wtf?) features
            - The m
ore ideas you have for features, the longer it takes to dev, the longer it takes to launch, the more you have to pay
            - Less features, sooner
            - Product is easier to use, and simpler
        - Before you spend £25, check if you really have to
        - Make deals
            - If someone has something you want/need, make a deal with them
            - Offer to build web sites for people in exchange for services
            - Give a small percentage of revenue or something
            - Offer ad space
, even on your blog
        - IM, not phone calls
        - Do as much as you can yourself. They did:
            - Wire-framing, marketing, testing (got friends to do it), bookkeeping and copy writing

Wire-framing: each frame in Flash represented one state of the app
                - big button to "walk through"

        - Get friends to help (usability testing)
        - Shop around - their first hosting quote was £12k/month

Pessimism has its place
    - You'll go 10% over budget
        - It will happen
    - You'll go 3 months over schedule
        - It just happens, that's life as a dev
    - Solution? Plan on it and update your cash flow

Holy crap! Lawyers are expensive
    - You'll need
        - Terms of service - £1000
        - Contracts for freelancers - £800
            - Regardless of how much you trust someone, get a contract
        - Privacy policy - £15
            - ClickDocs
    - Barter!
        - Every lawyer needs a website, so offer to sort their site
    - Get a free one-hour consultation

Cheap software is your friend
    - Project management: Basecamp
    - Bug tracker: Trac
    - Meetings: Skype and AI
    - Version control: Subversion

- article on Sitepoint yesterday about setting SVN up for web app dev

        - another -

    - LAMP

Cheap hardware is your pal
    - Get a £200 Linux box for your dev server and run it from your office

How not to spend money on marketing
    - Blogs
    - Word of mouth
    - Is your web app viral?
    - Writing - great way to raise profile
        - People with good ideas write features for magazines
        - If a mag is in your customer's sphere of influence, e-mail the editor

What about Venture Capital?
    - Don
't have to cut costs
    - Might need it if:
        - You need to expand quickly
        - You can't wait a year to save the cash
    - You need to have a solid reason to go the VC route
    - Why give up 25-50% of your company?

If you don't remember anything [he] just said…
    - Don't spend money unless you have to
    - Bring down costs by bartering services for equity
    - Cut your features so you can build quickly
    - Be realistic, if not slightly pessimistic about your cash flow
    - Plan for scalability but don't obsess


4:45 - 5:30
Greater Expectations - Reality-Checking the AJAX Web Application Architecture
Steffen Meschkat - Google

    - What's in a name?
        - Asynchronous
        - JavaScript
        - XML
    - But…
        - All of the parts are either nonessential or redundant
        - boils down to client-side scripting, done the right way (but the name CSS is taken)
        - a bad name, however, is better than no name

AJAX - The Difference
    - REST and SSSS
(Server Side Session State) applications
        - Client side, only two events: click a link and submit a form
        - the action is each time to replace the entire document
        - application specific behaviour resides on th
e server
    - AJAX applications
        - scripted event handlers are embedded in client side documents
        - in reaction to specific events, the current document is updated, possibly but not necessarily involving additionally requested data from t
he server
        - application specific behaviour is implemented on the client side

- Sophisticated user interaction
- display can be partially updated, modified, animated
        - complex manipulations are possible
        - user interaction like in 1990s

    - Client Side Session State
        - transient session state is managed on the client
(DOM storage, JS objects)
        - persistent user state maintained on the server
        - corrects a long standing architectural aberration

    don't need server side session state
        http protocol - entirely determined by request - nothing in server
        tedious to put session state into URL (QueryString)
        server side session state
            object on server, maintains session state (problems - mult servers, must go back to same server, scalability)

            - sessions always expire at the wrong time, don't work cross-server, not scalable
                - This is A Fucker™, I know from personal experience

        AJAX makes server side session state ok - can store "state" in browser

    - The bad thing about doing something right the first time is nobody appreciates how difficult it was.
    - Web technologies give us plenty of oppportunities to appreciate how difficult it was.
    - He doesn't like pop music, but does like opera, apparently
        - Opera apparently takes talent and patience and training, but any old knob can make pop music. Yeah,

hat's really in it, I
    - CSS
        - Layout, colours
, fonts
        - no clear seperation between real world and 'promises' made in CSS

    - DOM
        - Jeremy's lovechild.
        - nodeName, nodeType, etc.
        - no transactions, unspecified partial deserialisation semantics
            - this means 'it's not able to handle grouped, roll-back-able operations' and 'it has no defined semantics for converting to a transmission-safe form'
            - if it's half-loaded, how should the document look?

    - JavaScript
        - Just two words (but more later): semicolon insertion
        - single threaded, but nobody tells you so.
    - HTTP
        - XMLHttpRequest (notice the capitalisation, let alone the semantics)
    - Data Marshaling
        - XML, but better JavaScript Object Literals

    - FAUST:

Who art thou then?
        Part of that power which still produceth good, wilst ever scheming ill.

    - (Goethe: Faust.)

Practical consequences
    - Cross browser compatibility
        - different implementations of all mentioned technologies
        - different (but always many) bugs
        - ~enforces good libraries~
    - Separation of interaction logic and application logic
        - implemented in different languages
        - separated by flexible and extensible protocol
        - seamful integration

    - Reputedly not serious (ridiculed for the name)
semicolon insertion
surprising scope rules
poorly specified runtime),
but actually better than its reputation
custom objects, delegations, closures
rich literals, exceptions, functors
has been called Lisp withC syntax
even the name made sense at the time. Don't be afraid of JavaScript :-)


    - Deployment
        - compilation/packaging modularization, cache control

- Bookmarking and History
        - in applications quite pedestrian, but so are the browsers

    - Graceful Degradation
        - smart reuse of transfer format helps a lot

    - Frameworks
        - or rather, to resist the temptation to build one
        - because there already is one, only it isn't called that way


5:45 - 6:30
Panel Discussion

This is gonna be available, and I'd forgotten to take notes, so there you go.


Steve Marshall:
Damien Tanner: (
Richard Rutter:

Chris Stainthorpe:

Stuart Colville
Gavin Montague
Tim Blair:

Duncan Ponting:

Joshua Sierles:
Jeremy Keith:

Ben Ward:
Andy Hume:

Marcus Mitchell:
Levent Ali:

Mark McLaughlin: (
Andrew Skinner: (nowt there... yet)

Mike Priddy:

Robert Sharl: