barcamp san diego 5: “monitoring websites and iphone apps”

– levels of monitoring
— cust experience
— synthetic api
— synthetic ui
— server health
— jbosss/jvm
— db

– strategy
— build a mesh of monitoring, eg great customer experience even though a jboss server failed

– quicken iphone experience
— built on top of an existing service
— mobile app services need to be decoupled from any underlying product
— recording, logging, and monitoring transactions need to be captured in such a way as to determine new info, eg device type
— building and testing on an iphone is very different from the traditional web model
— put app and provision file on a server so all testers can install the app remotely
— apple approval process is a black box

– operation and design considerations
— apps must be designed to handle variables beyond backend’s control
— network failure
— failure of required external services, eg google maps
— crash logs sent back to server
— accepting call in the middle of transaction will close app

@dmkanter on twitter

– tools
— nagios
— used for monitoring databases
— bigbrother
— gomez
— used for synth ui testing

barcamp san diego 5: “hotruby + jquery”

– how to use ruby in the browser w/ using jquery
– history of js
— created by brendan eich in 1994
— based on scheme and lisp
— netscape got partnership w/ sun, so the language had to look like java
— IE duplicates it
— netscape tries to standardize it
— prototype -> implemented -> deployed -> standardized very quickly

– js is not dead yet
— most common platform (now on server w/ rhino)
— the most common programming lang
— the lang of the internet
— most problems aren’t so bad

– hotruby
— may be more performant than interpreted ruby
— write in ruby, compile it, and exec it in js vm
— not much changed after 2007
— original hotruby on github
— takes ruby bytecode as an input and runs it via js in the browser(!)
— now plugin req’d

– speaker’s work
— speaker has been updating it to ruby 1.9.1
— app.srtd6.com/compile
— run this and look at response in firebug to see ruby bytecode
— sends text boxt content to server, compiles it to ruby bytecode, sends it back, and runs it using hotruby interpreter
— will run in all browsers
— look for “hotruby” in github.com/strd6/

barcamp san diego 5: “cloud computing on EC2”

– rightscale alternatives
— chef
— sponsored by att
— an opensource ruby project
— puppet
— cfengine
— scalr.net
— way cheaper than rightscale

– ec2 alternative
— eucalyptus
— opensource project on a private cloud
— akamai now hosts applications on their edge servers

– load balancer
— haproxy (http://haproxy.1wt.eu/)
— software based
— allows us to route all traffic to a new cluster once it’s launched and running
— red5
— hardware based
— algorithms
— round robin

barcamp san diego 5: “hbase, cassandra, bigtable, simpledb discussion”

– amazon dyno (dynamo?)
– cassandra
— latest time stamp wins

– managing distributed records
— use checksum to verify data health

– why use an hbase
— random reads on disks are slow; reading from sequential data on disk is the only way to go
— simple fetch queries are roughly equivalent to an hbase lookup

– hdfs / hbase division?

– how to update record?
— hbase is not replacing relational dbs; they are used in conjunction.
— they can replace relational dbs, if the data we’re storing is normalized by nature, eg we’re just using it for user records
— if the data is actually normalized in the hbase, the update is straightforward.ย  If the data is denormalized in the hbase, we’re better off having the data normalized in a relational db, updating the normal db, and then updating the hbase in a batch process later.

– memcache vs hbase

– db sharding
— painful because it’s application logic and relational dbs are optimized for joins.
— hbase is optimized for sharding