All +
All -
oscon-2010
- Wednesday
- + -
keynotes
- codeforamerica.org
- CTO of Washington DC
- Dirk ??? of Meego
- full open source mobile linux stack
- first full release soon
- changes are made to upstream projects, THEN put into meego
- avoids forking and maintenance problems
- Stormy Peters
- "pick up the poop"
- web services
- twitter
- gmail
- facebook
- etc
- we're not doing the hard work to make Free software web services
- there are many that "just work"
- identica == free twitter
- tomboy online
- notes syncing
- http://live.gnome.org/Snowy/
- look at the license
- who owns your data?
- will they keep it when you leave?
- avoid lock in
- Marten Mikos, Eucalyptus
- believes that the way to make better open source is to make it make money
- mysql was sold for $1B...
- The Cloud is the next big change in IT
- 20% of it workload in the clloud in 5 yrs
- rackspace just released open source cloud stack
- eucalyptus is for running an on-premise cloud
- "eucalyptus" is a backronym
- + -
Android: the whats & wherefores
- Dan Morrill
- Android program open source manager, Google
- what do we mean by "open"?
- wanted no central point of failure or restriction
- '...defend to the death your right to say it"
- google has a few mobile apps...
- solution
- modern platform
- pc-like model
- user installs what they want
- open src to speed adoption & enable innovation
- professionally developed
- android market lets you put up (almost) anything
- alternate methods available
- you can write an app store app
- sideloading
- android open source project AOSP
- not a distro - single corpus of sw
- not designed for pick and choose
- predominately apache licensed
- partially non-public dev process
- open for any use
- to join the ecosystem you must be compatible
- why ASL
- like BSD, but adds patent protection
- google avoids copyleft
- why a partially closed dev process?
- defining a platform as we go
- if we do it in the open, people will ship early
- can't afford inconsistent APIs
- necessary to compete
- this is the way the mobile world works
- splashy launches work
- not trying to change the whole industry
- more and more of the devel. is done in the open
- tools
- git
- repo for cross-git project automation
- gerrit for pre-commit review
- http://review.source.android.com/
- infrastructure
- kernel.org hosts
- OSU OSL hosts back-end tools
- issue tracker needs more work
- + -
Django: Two extreme case studies
- mike biglan & wiggins
- concentric sky
- boutique devs in eugene
- 10 django devs
- about the projects
- michaelmoore.com
- 5 weeks
- very hard deadline (movie release)
- santafe.edu
- process
- owners of well defined tasks
- identify and resolve blockers
- daily routine checkins/meetings
- as issues come up, change the process for next time
- planning
- start with the data schema
- don't overplan
- get everyone on the same page
- mockups
- wireframes
- sitemaps
- identify questions early
- content & migration
- bootstrapping
- django admin
- clone prev & prune
- clone a standard template
- gives you a standard structure
- easier to train new devs
- works with your deployment system
- http://code.google.com/p/djenesis
- bootstraps a new project
- with some 'best practices' defaults
- scaling
- lots of proxying
- separate media servers
- start with a load balancer
- even if you have only one media server
- easier to add more servers later if it's already set up
- proxy dedicated db servers
- load balance app servers
- memcached for sticky sessions
- avoids probs w/load balancers
- cache your queries
- cachemodel
- base class for Models that support caching
- code.google.com/p/django-cachemodel
- namespaced caching library
- table level caching
- object level caching
- integrations
- haystack
- django integration for SOLR
- model based
- identify
- pull
- make a proxy model
- use caching
- push
- + -
Database scalability patterns
- robert treat
- omniti
- mostly postgres
- some oracle & mysql
- what are db scaling patterns?
- part db design
- part app lifecycle
- not talking about failover
- simple patterns
- myfirstdatabase
- simple design
- low traffic
- vertical partitioning
- partitions within a table in a db
- still one node
- minimal app-level changes
- vertical scaling
- throw a bigger server at it
- RAM
- CPU
- Disk
- not a "solution" per se
- but it works for many/most companies
- moore's law works in your favor
- read slaves
- master/slave
- or multiple slaves
- or memcached as read slaves
- writes go to master
- reads go to slaves
- only helps read-limited systems
- full copy of data on read slaves
- delay in propagation
- possible data loss on master crash
- consider
- partial copies
- only replicate the busy tables
- synchronous
- don't use an RDBMS for the read slaves
- use memcached
- or mysql
- or nosql
- requires application changes
- app needs to know about read vs write
- where to look for data
- will take a lot of time
- been done many times
- basically a solved problem
- scaling writes
- Not easy
- most people don't have this problem
- multi-master
- many ways to implement
- most don't work in production
- write to any node, db syncs automatically
- can reduce cpu, can't reduce i/o
- works ok for failover
- write to one master
- writes duped to failover master
- sharding
- SOA
- horizontal partitioning
- divide schema by jobs
- move each piece to its own server
- duplicate data as needed
- need to split dependencies in app code first!
- otherwise you end up with just another point of failure
- each node is a new instance of vertical scaling
- horizontal scaling
- data split across server based on algorithm
- data dropped into buckets
- put each piece into multiple buckets for redundancy
- something needs to manage buckets
- and provide lookup services
- your code will need to be quite different
- this is rarely needed
- What are the "universal truths" about scaling?
- "it depends"
- vertical scalability matters
- no matter what other technique you're using
- the more vertical scale you have, the less horizontal multiplicity you need
- new nodes are never free
- points of failure
- management costs
- adds complexity to app code
- adds complexity to architecture
- tips
- plan for layered data sources
- db + cache, read slaves vs write master, etc.
- distinguish between a read connection and a write connection in your code
- use schemas to separate services
- + -
Membase
- Matt Ingenthron
- Northscale
- what is it?
- open source
- distributed
- fast
- key value store
- optimized for web apps
- memcached with persistence
- replicated data
- simple
- get
- put
- increment/decrement
- compare-and-swap
- at least as fast as a highly optimized dbms
- designed for the modern datacenter
- cloud
- vm
- flash storage
- etc
- elastic
- add nodes w/o losing access to data
- maintain consistency when accessing data
- scale linearly by adding nodes
- who
- The guts
- cluster func. based on erlang OTP
- custom vector clock based way of storing & propagating
- cluster topology
- vBucket mapping
- hash keys to vBuckets
- map vBuckets to servers
- collect stats from many nodes of the cluster
- identify hot keys
- resource utilization
- Releases
- beta 2 out july 21 (yesterday)
- beta 3 out this quarter
- + -
Android hands-on
- building great apps
- speed & responsiveness
- use asynctasks & services
- no pauses
- quality & polish
- clean flexible UI
- feature completeness
- stability & error resistance
- system UX integration
- widgets, notifications,live folders, quick search box, accounts,sync, etc
- intuitive & correct navigation
- use of back, men, search buttons
- bonus - cross app integrations
- exposing public intents, content provders. etc
- you can detect if other apps are installed
- + -
UI Design Tips
- roman nurik
- dos & don'ts
- don't just port from another platform
- needs to look like an android app
- users should feel at home
- don't overuse modal progress & confirmation dialogs
- don't use rigid absolutely positioned layouts
- don't use px
- don't use small font sizes
- do create versions of graphics for high res screens
- do make large tap targets
- do follow android icon guidelines
- do use proper margins & padding
- do support d-pad & trackball nav
- do properly manage the activity stack
- do handle orientation changes
- do use theme/style dimension, color resources to reduce redundancy
- work with a designer!
- design philosophy
- choose clear over simple
- show proper feedback
- effects of actions should be visible
- unobtrusive progess indicators
- if complex instructions are required, rethink the design
- be fault tolerant
- undo vs. confirm
- don't make things irreversie
- content over chrome
- enhanced by the cloud
- maintain content across desktop & mobile
- considerations
- diff. screen sizes
- diff pixel densities
- portrait / landscape
- touch screen vs. trackball/d-pad
- soft vs. phys. keyboard
- be aware of device diferences
- read thru the CDD
- source.android.com/compatibility
- UI framework features you should be using
- <RelativeLayout>
- resource qualifiers
- drawable-hdpi vs. drawable-mdpi
- layout-port vs.layout-land
- 9-patch drawables
- similar to css3 border-image
- make both hi & med density versions
- 4-state buttons
- default
- disabled
- pressed
- focused
- new UI design patterns
- dashboard
- 3-6 major sections of the app
- "what can I do with this app?"
- put new stuff/news/updates here
- first impression
- action bar
- like a title bar, with buttons
- put primary functionality here
- "how can I do <common thing> quickly?"
- search, post tweet, refresh, etc.
- home button
- convey a sense of place
- quick actions
- better version of context menu
- "What can I do with <this object>?"
- icons &guidelines
- new android icon style, use it
- http://j.mp/androidfun
- balsamic(?)
- tool for doing UI mockups
- + -
Building a REST app
- native rest cllient vs mobile web app
- deep system integration
- run in background
- potentially faster
- do stuff that's not possible via html
- how NOT to do it
- run it in a background thread
- might get killed by the OS
- then you're in an unknown/inconsistent state
- the right way
- tell the OS you're doing something long-running
- start up a Service
- system might kill you, but it will restart you
- use persistent state storage (not just in-memory)
- use a Service API
- Activity
- The UI part
- add an operation listener in onresume, remove it in onPause
- consider these cases
- activity still active when resp.comes back
- activity paused, then resumed, then req comes back
- activity paused when req completes, then is resumed
- need to keep track of requests in persistent storage
- CursorAdapter handles the ContentProvider notifications by implemeting a ContentObserver
- service buffer
- singleton exposing async api to the UI
- prep. and send the service request
- see if it's already pending
- create request intent
- etc...
- return req. ID to caller
- handle callback & dispatch to UI listeners
- Service
- processor
- manages state of client side storage
- rest method
- run rest method in a worker thread
- use the apache http client
- enable gzip
- use a ContentProvider API
- maybe with a sync adapter
- sync adapters are important, use them
- new in 2.0
- system sync adapter
- queues syncs across system
- error handling plus retry
- battery efficient
- not instantaneous due to queueing
- impl. as services
- closely tied to content providers & accounts
- conclusions
- don't impl rest calls (or other network IO) in activities
- start long running ops from a service
- minimize network usage
- persist early & often
- Native development
- 160K Android activations per day
- Dalvik VM
- Thursday
- + -
Keynote
- State of the LAMP Stack
- ??? @ Facebook
- what fb has done with PHP
- HipHop
- compiles PHP down to C++
- open sourced recently
- 50% reduction in CPU for facebook
- They use lots of mysql
- not a lot of relational stuff
- few joins
- that stuff is mostly done in the php/hiphop layer
- hadoop, blah blah
- not very well organized talk
- SETI
- SETI Institute
- one of 100bn stars in one of 100bn galaxies
- astrbiologists look for evidence of life elsewhere
- we've actually done very little seti searching
- open cloud, open data
- john paoli
- microsoft interoperability lab
- Public Static Void
- Rob Pike
- Google
- languages are very verbose and complex
- mostly griping about C++ & Java
- how did we get here
- these languages are hard to use
- subtle
- intricate
- verbose
- their standard model is oversold
- every step must be justified to the compiler
- repetition as a substitute for safety
- Industrial programming
- other langs are a reaction to this
- python, erlang, scala, etc.
- generally it's dynamicaly typed & interpreted vs statically typed&compiled
- go tries to split the difference
- concise
- typed
- pleasant to use
- golang.org
- open source & the cloud
- rackspace.com
- openstack cloud software
- they donated their cloud platform
- believe that open source is the best way to build software
- open design
- design confs every six months
- open development
- open community
- open source
- apache license
- no dual licensing
- Invites the CTO of NASA up to the stage
- wants companies to build around openstack
- believes availability of an open cloud stack will bring innovation
- + -
Threading is not a model
- google
- The principle of sufficient irritation
- from a phillip k dick story
- python isn't java without the compile
- patterns are good
- may also be a sign of weakness in a language
- patterns are built into python
- ...
- concurrency models
- communicating sequential proesses - CSP
- all code single threaded
- communicate by channels
- actors
- code is single threaded
- objects are concurrent
- objects send and respond to messages
- differ only on what is concurrent
- didn't really get the point of the talk
- + -
powerful patterns in python
- alex martelli
- google
- what's a pattern
- closely related class of problems
- class of solutions
- may exist in different scales
- a patern's problems
- forces / constraints/ desiderata / side effects
- context
- including what tech can be deployed to solve
- identifying patterns helps others "up their game"
- recognizing is faster than inventing
- structured description aids recognition
- pythonic patterns
- well adapted to python's strengths
- dealing with python-specific issues
- idioms vs patterns
- what's an idiom?
- small-scale technology-specific common choice of name, arrangement or procedure
- only makes sense in a specific technology
- if __name__ == '__main__' is a python idiom
- anti-patterns
- commonly occurring
- and wrong
- + -
building an open source ecosystem for mobile tool developers
- paul beusterien
- symbian foundation
- symbian has 40% of world smartphone mkt share
- tools
- open source virtual cycle
- meh -- verysymbian specific
- + -
callbacks in python
- alex martelli
- elected to just lisiten...
- + -
K9 mail
- Jesse vincent
- best practical
- named after "mutt"
- and Dr. Who's robot dog
- K-9 is an android mutt...
- android 1.0 email client sucked balls
- the story of how he forked it and made a very successful project
- + -
node.js
- Tom Hughes-Croucher
- why js on the server?
- we're already doing js on the client
- why not do it server side too?
- we could all get really good at js
- "progressive enhancement" is free
- shows photoshop pic of unicorn riding a narwhal
- no, really
- dude is a *great* speaker
- photoshop of Crockford's head on chuck norris
- runtimes
- V8
- spider monkey
- rhino
- javascript core
- node.js
- any posix machine
- V8
- non-blocking
- callbacks & async everywhere
- event driven
- commonJS module format
- it's reeeeely fast
- almost as fast as nginx...
- why non-blocking matters
- not sitting around waiting for something to happen
- node ecosystem
- very fast growth
- lotsa packages
- node package manager
- still new, expect bumps
- node-repl
- what to use?
- mustache.js
- paperboy
- wargamez.mape.me
- multi-core
- http://speakerrate.com/sh1mmer
- Friday
- + -
Keynote
- Sam Adams, PDX Mayor
- Portland is very FOSS friendly
- top 5 beers in us are from pdx
- Simon Wardley
- cloud computing
- been talked about for 44+ years
- transition from innovation to commoditization
- happens to every technology
- from a product to a service
- IT is an arms race
- "Creative destruction" - economic term
- "shape"
- survival today vs. survival tomorrow
- inovate, leverage,commoditize
- you become what you disrupt
- + -
Practical Concurrency
- tim bray
- google
- conncurrency is hard
- chips have more cores
- and more and more and more...
- so we're gonna have to do concurrency
- "wide finder" project
- look it up on google
- project on his blog
- crowdsourcing of parallel solutions
- takes a lot more LOC to make is parallel
- threads are not the right solution
- just too goddam hard and complex
- shared mutable state is satan
- even if you sugar coat it, it still sux
- functional programming is the "righter" approach
- data is immutable
- but it's still hard
- haskell is hard
- erlang is the most common functional lang
- erlang
- works great
- limited string handling & IO
- clojure
- lisp on the JVM
- two big downsides right there ;)
- all variables are immutable
- has 'software transactional memory'
- compiles down to java bytecode
- so it's FAST
- has access to java libs
- many of which aren't thread safe...
- he believes that actors & message passing is the better way
- the node.js paradigm is also good
- if you have to do concurrency, use actors
- + -
ending poverty with software
- adam feur
- grameen foundation
- http://www.mifos.org/
- 2.7 bn people live on <$2/day
- believes that microfinance is the key to ending poverty
- microfinance loans mainly to women
- men generally spend on themselves
- women spend on family
- need scalable web based software
- sf.net/projects/mifos
- distributed, agile project
- docs on http://flossmanuals.net/Mifos
- communication bandwidth in team communication
- higher bandwidth makes a difference
- skype
- tokbox
- multi-person video
- facial expressions & body lang. add a lot
- good communication == good team
- good team == good product
- architecture now
- java
- struts
- hibernate
- BIRT
- tomcat
- arch. plans
- spring MVC
- freemarker
- OSGi for business logic