All 4 entries tagged Web20Expoberlin

No other Warwick Blogs use the tag Web20Expoberlin on entries | View entries tagged Web20Expoberlin at Technorati | There are no images tagged Web20Expoberlin on this blog

November 06, 2007

Web 2.0 operations

Artur Bergman – wikia

  • Operations builds trust in a brand.
  • Ops is the stepchild of engineering – development gets the glory.
  • To do good ops, you need sysadmins manning NOCs etc, and engineers.
  • Good engineers * Detail oriented * Don’t aspire to work in development * Should work with development though, so that both sides can learn about each other
  • You must understand the product to run it successfully. Complexity kills
  • Rule 3: Look first. You must have good monitoring and good alerting.
  • Do not over-alert, and do not cry wolf.
  • Trending – long term capactity planning. Make alerts be timely – there’s no point alerting at 90% on a 10TB partion that grows at 1MB a day
  • Websitepulse – gomez alternative.
  • Nagios – doesn’t scale well for large installations; doesn’t keep state; over-alerts
  • Hyperic – looks much nicer
  • Cricket / MRTG / Cacti – impossible to configure
  • Ganglia – rocks – no configuration
  • load increase while running process stays the same – shows up blocking calls
  • custom gmetric scripts – can collect more or less anything
  • graphing stuff is a very good way of spotting problems.
  • tcpdump / wireshark – tells you where packets are going wrong.
  • rule 4: Divide and conquer. Look at the problems in turn, go in the order you suspect is most likely
  • change one thing at a time, and keep an audit trail. use version control
  • If you didn’t fix it, it aint fixed. If it goes away, it will come back and bite you later. Figure out what happened.
  • use strace/dtrace/truss/gdb
  • you need a little bit of process.
  • Design against complexity. Re-use components, define standards. Have a few machine images, re-image all machines periodically for the hell of it
  • MTBF is irrelevant. dealing with failure is more important. Target the right level of uptime.
  • Don’t kid youself. You don’t need 5 nines
  • The higher you aim for reliability, the higher complexity and cost you’ll get. If you need 2 nines and aim for 5, you’ll do worse than if you just aim for 2
  • MTTR – a much better metric. 1 minute downtime every week is still 4 nines
  • Problem management: Once a problem is found, start a phone conference. Use IRC or IM to communicate technical info. Have one person liase with non-technical people, and one person be in command.
  • Write down results of root cause analysis
  • Automation: All machines are created equal. If you manually make changes, you are wrong (usually)
  • Best practice: * Gold images * Centralised authentication * NTP time sync * Central logging * All applies for virtual machines too!
  • cfengine – ; puppet is much nicer
  • cobbler – linux version of jumpstart
  • datacentres: keep them tidy; label everything. have a switch in each rack if you can. Remote consoles / Remote power switches save a lot of pain.
  • Virtualisation: Use it. Managing becomes much easier. power consumption goes down, new test boxes can be quickly provisioned
  • Loadbalancers: Keep them simple and low level. LVS + Squid Carp. Log over UDP so you don’t block if the disk is full
  • Squid: Use for static stuff; use squid with a very short ttl (1 second) for non-logged-in-users and dynamic pages.
  • Databases: report slow queries. fear ORMs; understand what they are doing
  • If you’re small, outsource
  • : CDN
  • S3 for binlogs, datafiles, etc

Stowe Boyd: We build our tools, and they shape us


Marshall McLuhan – wrote about the way that mass-media was affecting society, and coined the term “global village” in the 60s to describe the way that society would change with the advent of worldwide communication networks.

Social Tools – as much of a revolution as email was 10 years ago

Lifestreaming tools – twitter, jaiku, facebook mini-feed. Hard to rationalise why these are appealing technologies; the only way is to try it.

Social == Me First. Social tools are primarily organised around self-interest, not altruistic participation in a community. Community, where it emerges, is a side-effect of the tools.

The Dunbar Constant (Robin Dunbar). An individual can only keep up with at most ~150 other people. Can technology increase that number?

In the US, since the 50s people have spending less and less time in social activities; the primary driver for this has been television. The internet has, to an extent, reversed this trend; as people switch from TV to social networking.

Lots and lots of skills are only learnable by spending time doing them, and can’t easily be achived by simply concentrating really hard. Stowe asserts that life-streaming apps, and immersion in the flow of social data, leads to a gradual change in outlook and capabilities, becoming better at socializing on the web.

Continuous Partial Attention: lack of personal productivity may be outweighed by the increase in productivity of the network as a whole.

Every time a new medium comes along, workplace management see it as an impact on productivity and resist it. This happened with phones, email, internet access, IM,... but eventually they give in and realise that people are smart, and will use the new tools to their advantage.

People will increasingly turn away from mass media and towards social networks as the primary mechanism for learning about the world; the media will move into social-scale applications to try to resolve this

Workstreaming – impact of social networking on the world of work. 2008 will be the year that stream-based apps move into business.

The War on Flow – there are lots of people who will argue against pervasive social networks; arguing that they’re less productive or less reliable (in information terms). Stowe believes that the rise of social networks, and the associated societal change (which will be every bit as disruptive as the effects of television, but much more positive), is inevitable however

November 05, 2007

Cathy Sierra: Creating Passionate Users

Creating Passionate Users – Cathy Sierra

  • Advertisers – best people to learn how to get rapid engagement from
  • Where there’s a passion, there’s a user seriously kicking ass. No-one is passionate about something they suck at
  • People who have a passion about/ are good at things get a richer experience from the activity than others
  • Once over the suck threshold, users are self-sustaining. Our job is to get users up the curve as fast as possible.
  • No-one wants to be an expert at spreadsheets. They want to be experts at loss adjusting, or cost prediction,, or whatever it is they want to do with the tool .
  • Can create passion by proxy – for example Red Bull have a Music Academy where they train dance musicians. Mis-attribution of Arousal creates a mental link between the product (Redbull) and the passion (Music) even though one shouldn’t exist.
  • The Most Important question: What can I help my users Kick Ass at ?
  • Understand the difference between how the brain works and how the mind works. Your brain’s job is to keep you alive, to filter out crap, and forward the tricky stuff on to the mind to make sense of your mind is trying to rationalize the data that the brain is pushing at it. Getting emotional buy-in stops the brain from filtering out stuff and allow the mind to engage.
  • How to beat the brain’s crap-filter…
    – Differentness, scary-ness, cute-ness, humor/joy, faces, keep engagement by providing micro-wake-ups every couple of hours. Faces get a double bonus because not only is any face image engaging, but you can use the emotion on the face to add weight.
    -Un-resolved questions in images are very good.
    – Conversational tone always beats formal.
  • Ways to get over the suck threshold:
    – compelling picture of what it will be like when you dont suck (why does anyone go snowboarding the second time?)
    – clear path to not sucking
    – easy first step
    – To get the compelling picture; you’ve got to know what it is that users want to do
  • Ask the questions: What does expertise look like?
  • Ask “Why ? Who Cares? So What?” Dont’ assume that because people can make the leap intellectually between what the product does, and what it means to them, they will do so. It’s your job to make that link for them.

– If you want then to RTFM, make a better FM
– You can never spend too much resource on user learning – manuals, tutorials, drop-ins, helpdesks, whatever. Out-teach the competition. Think learners, not users.
– A huge amount of brain chemistry is devoted to making you not remember stuff (otherwise your brain would fill up)
– Make people make choices – choosing between two things makes you remember both of them.
– Or use pictures. The pictures don’t even need to be very relevant.
– Lead people down the garden path; let them fall into pitfalls; this is more memorable than just being told what the pitfalls are.
– Look for “Oh Crap” or “Oh Cool” moments in each segment.
– Just in time learning vs. just in case.

  • Engagement
    – get users into the flow state
    – if something is too easy, you won’t get flow. But; that challenge should not be in using the interface!
    – understand the difference between funny and fun. Chess is not funny, but it’s still engaging.
  • What breaks the flow state?
    – Flow is a kind of fantasy; don’t bring people back to reality.
    – Make the right thing to do easy; make the wrong thing difficult.
    – what could your users do in flow? Is there a continuing challenge? Can you help them meet that challenge?
  • Game developers are better at this than anyone else in the software industry
    – UX spiral: Motivating benefit->Interaction->Payoff->Motivating benefit
    – Level/Reward pacing – exponential increase in gap sizes
    – If you can’t add features over time, add feedback. “Levels” equate to things that the user has learned to do, not things that you’re allowing them to access. “What are your super powers?”
    – Rewards should be frequent and small, not the opposite.
    – Hero’s jouney: Life is Normal->Something changes that->Things really suck->Hero overcomes things->Life returns to a new normal. Tech support are the helpful sidekicks and mentors in this journey. They should not be the Orcs :-). Key thing about the hero’s journey is that the hero changes as part of the journey.
  • What aspect of your product could be a part of a user’s identity or meaning?
  • T-shirt first development. Build the tribe. Create ways for your users to demonstrate that they belong to the tribe (c.f. thinkgeek’s pictures of people wearing their t-shirts)
  • Insider info is social currency.
  • Think about the stories that you can tell about people using your product to acheive something of value to themselves. We should do this
  • Building communities.
    – No dumb questions, and no dumb answers. Convert askers into answerers. Teach users how to create good content.
  • The kool-aid point; when people start to criticise what you’re doing as being cult-ish or over-hyped, you’ve acheived a certain measure of success.
  • Think about the disconnect between what we think, and what our users think of our product.
  • Users often ask for something different to what they want. Understand why users express the requirements that they do. When choosing between features, users give different responses if you ask them to explain their choices, and the responses are typically worse.
  • Marketing vs. user learning: Out-learn vs. out-teach.
  • It doesn’t matter what they think about you. It’s not about you, and it’s not about what you do. All that matters is how they feel about themselves, as a result of their interaction with your product. The user must have an “I rule” experience.

Cal Henderson: Scalable web architectures

  • Sessions: Bad. In order of badness: local sessions->mobile local sessions->remote sessions->no sessions at all.
  • No sessions at all: put all session data into a cookie; sign the cookie and timestamp it. 1K of data in a cookie is OK. (Make sure you’re not submitting it for static requests!)
  • Remote sessions; using the same database that you use for everything else means one less bit of infrastructure to maintain.
  • Functionality that won’t scale horizontally generally boils down to storage that won’t scale horizontally
  • Loadbalancers: software is hard to push more that 1GB/s (which would be a nice problem to have, for us!).
  • Wackamole – HA / Loadbalancing helper service – works by switching IP addresses.
  • Use queueing to manage long-running, CPU-intensive tasks

Can haz slidez?

Most recent entries


Search this blog

on twitter...


    RSS2.0 Atom
    Not signed in
    Sign in

    Powered by BlogBuilder
    © MMXXI