SmartLogic Logo (443) 451-3001

The SmartLogic Blog

SmartLogic is a web and mobile product development studio based in Baltimore. Contact us for help building your product or visit our website to learn more about what we do.

Web 2.0 Expo NYC Wrap Up

November 23rd, 2009 by

John and I went to the Web 2.0 Expo in New York City last week to learn about new trends in Web 2.0 and to try meet interesting people in the industry. We had fun, and I even won a Flip Ultra HD from the folks at a party hosted by Rackspace and Neustar. This post includes my notes from various sessions from the weekend.

Ignite NYC


Web 2.0 Expo kicked off with Ignite NYC on Monday (11/16) night. We’re a big fan of Ignite talks (having created the websites for Ignites in Baltimore, DC, Annapolis and RailsConf) so it was exciting to check out Ignite in the Big Apple. The Ignite NYC website lists the speakers but doesn’t mention what they spoke about (we’d be happy to host your website). Unfortunately I didn’t take notes at this event and I’m not going to go through all the youtube videos right now, so I don’t have much to share.

Web 2.0 Sessions

NoSQL: The Shift to a Non-relational World

This talk, given by Dwight Merriman, was about non-relational databases, which is a different paradigm from traditional databases like MySQL, Oracle, MS Access, MS SQL Server, etc. Non-relational databases are interesting to me as I think they might be applicable to some of our client projects. My notes:

  • No joins
  • Uses map reduce instead
  • When considering scaling out – think about “CAP” – you can pick any two of the following but you can never achieve 100% of all three:
    • Consistency: ensuring that data on multiple database servers are consistent
    • Available: you want the database to be available when you need it
    • Partition-tolerant: partitioning the database to run across multiple servers
  • CAP constraints are most relevant when writing to the database. If you’re only reading from the database, it’s easy to have all three.

The Lean Startup: a Disciplined Approach to Imagining, Designing, and Building New Products

This talk was given by Eric Ries (@ericries), who blogs at Lessons Learned. He is someone with whom many tech entrepreneurs are smitten, and I must say I myself was impressed. My notes:

  • Continuous Deployment
    • Devs can check code in, gets deployed everywhere within 20 minutes
    • Cluster will detect bad changes to the code, revert them, email everyone
    • The example Eric gave was that if someone messes up the UI of the checkout
      screen, e.g. changes the "pay now" button such that users can’t see it
      and this causes the company not to receive payments, the system will automatically
      revert itself after 20 minutes or so.
  • Lean Startups
    • Commodity Technology Stack
    • Customer Development
    • Agile Product Development
  • Agile Product Development
    • Principles from Lean Manufacturing, Agile, and TPS
    • Unit of Progress: A line of Working Code (as opposed to advancing the plan in waterfall).  Problem: known, Solution: unknown.
  • Product Development at Lean Startup
    • Unit or Progress: Validated Learning About Customers ($$$)
    • Problem, Solution: unknown.
    • Hypotheses, Experiments, Insights feed into XP, which feeds Data, Feedback, Insights back into Problem Definition / Customer Development cycle
    • Problem team: (formerly sales, marketing, product development) – cross functional team
    • Solution team: (formerly engineering, ops) – but should also include marketing – cross functional team
  • Pivot: one turn through this feedback loop
    • Ideas – build – code – measure – data – learn – back to ideas
    • Minimize total time through the loop
  • AAA’s of metrics:
    • Actionable
    • Accessible – must make sense to anyone, and must be accessible by anybody in the company (everyone should be able to pull the report)
      • Most useful thing is to kill pet projects and help people see that pet projects are bad ideas.
    • Auditable – "metrics are people too" – reports come from tangibles
      – when someone sees a report, they must be believable and must stand up
      to any questions.  People must be able to audit them because initial
      human reaction is to doubt and deny, etc.
  • Measure the Macro
    • Always look at cohort-based metrics over time
    • Split-test the small, measure the large
  • Five Why’s
    • A technique for continuous improvement of company process.
    • Theory: behind every technical problem is a human problem
    • Example: imagine a server crashes.  Why?  Code got deployed
      that used some obscure API that caused it to crash.  Why?  Person
      that wrote the code was a noob engineer and didn’t know better and wasn’t
      trained.  Why?  Manager
      doesn’t believe in training.  Started with a server problem ended
      up with a management problem.
    • Ask "why" five times when something unexpected happens.
    • Make proportional investments in prevention at all
      five levels of the hierarchy.
    • Behind every supposed technical problem is usually a human problem.  Fix
      the cause, not just the symptom.
    • Helps us identify that we’re too busy to find out why we’re too busy
      or something
    • Acts as a natural speed regulator.  If we’re spending too much time
      fire-fighting – we’ll have to slow down to address problem, etc.  Regulates
      our speed.
  • Minimum Viable Product
    • What’s the absolute least amount of product we can build to engage the
      visionaries?
    • Instead of asking customers what they want (which they don’t usually
      know), we’re going to take our theory, put it out there, and TEST.
    • Visionary customers can fill in the gaps on missing features – if the
      product solves a real problem.
    • Fears:
      • False negative: customers would have liked the full product, but the
        MVP sucks, so we abandoned the vision
      • Too busy to learn: it would be faster to just build it right, all this
        measuring distracts from delighting customers
    • Must have an agreement with the team to iterate – just because clients
      don’t like the first version doesn’t mean they’re not going to continue
      to iterate.

Eric mentioned a book he’s publishing: Startup Lessons Leaned (book) – still in “beta.” He also recommended The Four Steps to Epiphany.

Sketchboards & Prototyping – Method for Rapid Design

This talk, given by Todd Zaki Warfel (@zakiwarfel), described a process his company uses for prototyping ideas for applications. It was my favorite talk from the conference. Todd’s website is at http://zakiwarfel.com/. My notes:

  1. Prototyping is a process
  2. People often say "I think I get it but I’m gonna have to see it" –
    need to see prototypes
  3. Todd’s company doesn’t do wireframes.  Their wireframes are their
    prototypes.  Wireframes
    might be sketched out on paper.  Click-through wireframes are their
    prototypes (XHTML/CSS).  They do production-level prototypes, not recommended
    for anybody else.
  4. Two main reasons for sketching / prototyping in the process
    1. Sketches are a great communication tool – don’t write notes – sketch
      them out
    2. Pics have less room for interpretation than text
    3. Lo-fi is cheaper, generally speaking, than doing AI, etc.
  5. No written requirements – just visual requirements
  6. "Agile Conference" – 1500 – 1600 people show up. Todd’s group
    made some app in two days, for charity, and raised a few thousand bucks with
    the app.
  7. Design Studio Method
    1. Industrial design / architecture method
    2. A methodology where you build something, sketch something – create an
      idea – and then show it to people, let them critique it and tell you what’s
      good and bad about it.  Then iterate.  Take an idea, put it out
      in front of people, rip it to shreds, etc.  But you get to do that
      to their designs as well.
    3. They’ll do the Design Studio Method sessions with their clients and get
      paid for it.
    4. Write down a few keywords to describe the product today
    5. Write down a few keywords to describe the product 6-9 months from now
      – print this out, put it in big words in the room
    6. –> allows them to see their goals –> see what it is now, and
      what they’re targetting
    7. Personas – people that are going to 
    8. Inspirational printouts – stuff that looks aesthetically good or stuff
      that has good interaction – stuff to aspire to include in the next version
      of the product
    9. Break into teams
      1. One BA
      2. One speaks to dev
      3. One designer
      4. One sales or marketing person
      5. Represent all the different viewpoints
      6. Give them a design challenge and have them sketch out – generate –
        their ideas
        1. Building blocks of design: square, circle, triangle, line
        2. Generate ideas and pitch them: 3 minutes to present them, 2 minutes
          to critique.  Say 2 things that are strong about the idea and 
      7. Process:
        1. Sketch -> present -> critique
        2. -> prototypes
        3. -> and again: sketch -> present -> critique
        4. -> validate
        5. -> iterate
    10. Get started ASAP
    11. Messy is okay
    12. Quantity then quality –> generate lots of ideas and then refine
      1. Peer review then pitch -> critique process
    13. Templates that they use:
      1. The 685 – an "8 up template" – can put 8 sketches in there.
        1. First round you do by yourself – then critique (use red and green
          marker to denote what’s good and what’s not)
        2. Second round your sketches are up on the wall
        3. 5 minutes to draw 6-8 sketches
        4. Can also be used as a storyboard
        5. One or two rounds with 8 ups – sketching, critiquing, etc.
      2. Then a 1 up
    14. Three rules:
      1. Know your audience and intent (are you going to give sketches to a
        CEO?)
      2. Plan a little.  Prototype the rest.  This guy does about
        70% in sketches / planned out, then starts prototyping.
      3. Set expectations – to combat questions like "why is this B&W" or "what
        about the admin" etc.
    15. Closing thoughts:
      1. You can sketch.  No BS, anybody can sketch.  Anybody can
        sketch, good enough to put their idea down on paper.
      2. It’s [sketches] not the mona lisa.  Just needs to be good enough.  Not
        going to live forever in Moma or the Louvre, etc.
      3. If you can’t make it then fake it.  E.g. if you can’t get it to
        work in Javascript, use Keynote.
      4. Prototype only what you need.  Prototype the unique parts, not
        the entire system.
      5. Reduce risk.  Prototype early and often.  Do about 2 weeks
        of design studio sessions with their clients.  Then they jump right
        into prototyping.  Then they do weekly releases.  Whole agile
        argument – small and rapid iterations.

"You can fix it now on the drafting board with an eraser or you can fix
it later on the construction site with a sledge hammer." – Frank Lloyd
Wright

Todd was promoting his new book: Prototyping – A Practioner’s Guide – by
Todd Zaki Warfel
, which I’ve added to my wishlist at Amazon. He mentioned that it has 6 tutorial chapters, a bit on how to sell prototyping, and some other interesting stuff.

Freeing and Visualizing Financial Data

This talk was given by Toby Segaran (@kiwitobes) and Jesper Andersen (@jandersen). They put the slides from the presentation up on slideshare. My notes:

  1. Why visualize?
    1. To form a hypothesis
    2. To tell a story
  2. Single variable – shows you that a variable is moving but doesn’t tell you why
  3. Data Sources
    1. XBRL – put forth by SEC – to put all corporate-filed reports into the open domain in an XML readable format
      1. Capital IQ – data vendor
      2. Requirement – in 3 years everything will have to be encoded in XML
    2. BSYM – Bloomberg Open Symbology
      1. Unique keys of finance -> links symbologies in finance.  Problem is that different data vendors have different keys and it’s a mess.
      2. Competing standard is CUSIP – very expensive – but they own the data standard
    3. Yahoo! Finance data – downloadable via CSV – data goes back
    4. Amazon Web Services -> Category: Economics -> lots of data feeds
    5. "Trader Work Station" – some Java thing
  4. Freerisk – site they created
Yair Flicker is the President of SmartLogic.

Yair Flicker's posts