BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Key Takeaway Points and Lessons Learned from QCon San Francisco 2014

Key Takeaway Points and Lessons Learned from QCon San Francisco 2014

At the start of November around 1,200 attendees descended on the Hyatt Regency in San Francisco for the eighth annual QCon in the city.

The conference featured thought-provoking and engaging keynotes from security guru Bruce Schneier, 2013 Turing Award winner Leslie Lamport, Google Engineering Director Melody Meckfessel, and, for the first time at QCon, a set of 6 mini keynotes covering topics such as Password Security, Boosting Cognition, Skeletal I/O Tracking, VCs, Hacking Baby Monitors, and the Mythology of Big Data.

QCon SF attendees - software engineers, architects, and project managers from a wide range of industries including some prominent Bay-area companies - attended 108 technical sessions across 6 concurrent tracks, 19 in-depth tutorials, facilitated open spaces and, as at last year's confer had instant access to all filmed presentations from the event on InfoQ, with around half of all attendees making use of that facility.

This article summarizes the key takeaways and highlights from QCon San Francisco 2014 as blogged and tweeted by attendees. Over the course of the next 4 months, InfoQ will be publishing most of the conference sessions online, including 10 video interviews that were recorded by the InfoQ editorial team. The publishing schedule can be found on the QCon San Francisco web site, and you can see numerous photos from QCon on Flickr.

Keynotes

Track and talks

Applied Machine Learning and Data Science

Architectures You've Always Wondered About

Beyond Hadoop

Continuous Delivery: From Heroics To Becoming Invisible

Deploying at Scale

Engineering Culture

Engineering for Product Success

Java at the Cutting Edge

Modern CS in the Real World

Reactive Service Architecture

Real World Functional

Scalable Microservice Architectures

The Future of Mobile

Open Spaces

Training

Opinions about QCon

Takeaways

Conclusion

 

Keynotes

Twitter feedback on mini-keynotes included:

@techbint: You're storing passwords wrong! Use bcrypt. Friends don't let friends use sha1 passwords. #qconsf

@gravanov: #qconsf "I'm not Russian, I'm from Armenia, so it's ok to take security advise from me" LOL

@techbint: Learning how to hack baby monitors/ web cams. Terrifying how easy it is! #qconsf

@philip_pfo: Don't focus on making tech better, focus on how you can make _someone_ better with technology #qconsf #lightningtalks

@techbint: Don't automate the easy things, change behaviour. Lock the Xbox until surfaces are tidy. Lock iPad until I exercise. @jsoverson #qconsf

How DevOps and the Cloud Changed Google Engineering

by Melody Meckfessel

Philipp Garbe’s attended this session:

You think of code in a completely different way when you are up in the middle of the night dealing with an outage. - Melody Meckfessel, Google

Maybe because of that code reviews are mandatory for them. Your commit is not merged into the main branch until it was reviewed (e.g. with Reviewboard). One company told that they have also ownership for every file.

Andrew Hao attended this keynote:

  • The world is changing. Mobile is up and coming. Cloud platform is a huge market opportunity.
  • Google DevOps platform: supports fast builds, caching.
  • Every day, Google cranks out 800K builds, 2 petabytes of data…
  • Internally: single monolithic code tree
  • Code is open to any engineer
  • Variety of languages
  • Mandatory code review.
  • Need good tools to get information about system.
  • Deployment resource utilization

Twitter feedback on this keynote included:

@philip_pfo: Biggest cloud benefit - focusing on what you do best, rather than everything else. @mmeckf #qconsf #keynote

@aerabati: Innovation at Google - Tolerate failure and encourage risk-taking! via @mmeckf #qconsf

@charleshumble: Google's cloud infrastructure encourages internal experimentation. @mmeckf #qconsf

@aerabati: Google cloud platform is built on same infrastructure that powers Google! #qconsf #cloud

@aerabati: Devops - Writing code with a better understanding of how that code is operating in production! #qconsf

@aerabati: Google does 800k builds per day! #qconsf http://t.co/ff2dGFJS8y

@rchakra1: Everyday at @Google by @mmeckf #qconsf #devops http://t.co/RZiZJLJ3Ya

@dmarsh: Encouraging a testing culture helps us take more risks because testing has our back. @mmeckf #qconsf keynote

@charleshumble: Google has a single monolithic source tree, as opposed to distributed repos - simplifies global refactoring of code. @mmeckf #QConSF

@arburbank: Building better tests allows engineers to move faster. #qconsf

@rundavidrun: .@Google has single code tree, gives devs access to majority of code, allowing easy sharing (and critique) of code across projects.#qconsf

@arburbank: No matter how fast your build is, it's never fast enough. Users who once marveled at sub-minute builds soon ask for sub-second time. #qconsf

@jasondanales: $600 of cloud storage can store ALL of the worlds music. @mmeckf #qconsf keynote

@techbint: We overestimate what can get built in one year and underestimate what can get built in ten. @mmeckf #qconsf

@charleshumble: You think of code in a completely different way when you are up in the middle of the night dealing with an outage. @mmeckf #QConSF

@aerabati: A report that compares performance from release to release will be really nice to have! Google has it. #qconsf

@philip_pfo: Prod debugging is hard to scale. Log scraping doesn't scale; time series trends, low overhead tracing does. @mmeckf #qconsf #devops

@stonse: Google devs can attach to a running host and debug/inspect variables via @mmeckf #qconsf. Possible to block req thread via a breakpoint?:)

Programming Should Be More Than Coding

by Leslie Lamport

Andrew Hao attended this keynote:

  • We should be thinking harder before we start coding. Clear thinking can prevent errors. Fuzzy/wishful thinking can’t.
  • How do you think clearly? Write.
  • Specifications: help us think clearly.
  • Think like a scientist!
  • Best place to eliminate code is to think about what you need to do and what you don’t need to do.
  • Engineers starting to use TLA+ to describe system behaviors
  • debug 6 lines of specs better than debugging 850+ LOC.
  • when you write specs, you should write formal specs.
  • Before you write code, write spec.
  • Thus, you write better programs.

Twitter feedback on this keynote included:

@arburbank: No one just starts writing code and hopes it will implement a web browser. But we still don't spend enough time thinking up front. #qconsf

@arburbank: Clear thinking can prevent errors. Fuzzy thinking can't. And wishful thinking actually *causes* errors. #qconsf

@dtunkelang: Thinking is not just for hard programming problems. Thinking is necessary to determine whether the problem is easy or hard. #qconsf

@aerabati: Best way to learn something is to teach it - 'Programming is not just coding - talk!' - Leslie Lamport keynote on 2nd day of #qconsf

@hbrumleve: Leslie Lamport: incrementing an integer by one is harder than you think. #qconsf

@crichardson: Writing is nature's way of letting you know how sloppy your thinking is.” —Richard Guindon #qconsf

@philip_pfo: Think before (decide what, decide how) then do (implement). Clearer thinking will mean easier implementing. Leslie Lamport #qconsf

@jpetazzo: Productivity: "I wrote N lines of code today." Greater productivity: "I elimitated N lines of code today." — Leslie Lamport at #qconsf

@dtunkelang: The best way to eliminate code is in the spec. --Leslie Lamport #qconsf

@philip_pfo: Productivity isn't increasing code volume, it's reducing complexity without reducing functionality.Leslie Lamport #qconsf

@markmadsen: ~25 years ago at Bell, Mark Ardis introduced formal math to programmers by hiding it in programming language syntax, just like TLA+ #qconsf

@aerabati: 'It was a lot of easier to understand and debug 6 rules than 850 lines of code those rules produced!' - Leslie Lamport at #qconsf

@andrewhao: Leslie Lamport: write specs before you write code (formal specs in TLA+). How does this jive with Agile emergent design? #qconsf

@rundavidrun: The less well you understand what something is supposed to do, the more valuable writing a spec becomes. Lamport at #qconsf

@markmadsen: Every time code is patched, it becomes a little uglier, harder to understand, and harder to maintain Lamport at #qconsf

@vpothnis: if you dont have a spec, every piece of code you write is a patch - #LesllieLamport #qconsf keynote

Security Keynote

by Bruce Schneier

Andrew Hao attended this keynote:

  • We don’t have control over our infrastructure. Handing more data to the cloud
  • The future: we might see more vendor control over our OSes — app store updates, etc. Windows 8, Yosemite look more like mobile OSes.
  • Nowadays, there are a wider variety of attack(er)s. Hackers now have standard tools.
  • Advanced persistent threats: Hackers just trying to grab a block of credit cards. Targeted threats: politically motivated hacking.
  • IP theft as well as hacktivism
  • “The entire supply chain is now complete.” Stealing credentials –> turning account control

Increased gov’t involvment in cyberstates

  • infrastructure
  • legal involvement
  • cyber arms race: people building offensive weapons

We are risk averse when it comes to gains and we are risk seeking when it comes to losses. Evolutionary theory describes: short, guaranteed small gain is better for survival. This makes security hard to sell: we got by OK last time. Why do we need security now? This is the boss flipping the coin. If we get hacked, we all have to leave and get a new job. The economics for prevention are hard to sell. See analogy to selling insurance.

Principle: remove humans from the system as much as possible. Problem: humans cannot be completely eliminated from the process.

Tools and OODA

  • OODA loops: observe, orient, decide, act. Air Force captain. The faster you can eval this loop, the more advantage you have.
  • What I want in IR (Instant Response) is tools to get into the attacker’s OODA loops.

Twitter feedback on this keynote included:

@charleshumble: We are loosing control of our data. Bruce Schneier #QConSF

@dtunkelang: . @schneierblog: Attacks getting more sophisticated. Cyberwar is hype but escalation/commodification of tactics/capabilities is real #qconsf

@dtunkelang: . @schneierblog: Nation-states are big players in hacking game -- but they're increasingly hacking companies rather than each other. #qconsf

@dserodio: I'm still not on Facebook, but it's affecting my social life - Bruce Schneier #qconsf

@christianralph: #QConSF humans are risk averse when it comes to gains. And risk favourable to loss. Which makes selling security difficult @schneierblog

@dtunkelang: . @schneierblog: Conventional IT security wisdom: people are part of the problem, not part of the solution. Keep humans out of loop. #qconsf

@dtunkelang: . @schneierblog: But humans *have* to be in the loop for instant response, since that's when automated security tools break down. #qconsf

@rchakra1: Protection, Detection and Response are three key aspects of security @schneierblog #qconsf

@rundavidrun: .@Bruce_Schneier at #qconsf: we need real-time technology/tools that support, not replace people, in order to make them more effective.

@dtunkelang: . @schneierblog wants IT security tools to support the OODA loop: observe, orient, decide, act. https://t.co/MuS1nj4Rnd #qconsf

Applied Machine Learning and Data Science

Explore Your Data: the Fundamentals of Network Analysis

by Amy Heineike

Twitter feedback on this session included:

@dtunkelang: How to get started with network viz: force-directed layout, color for community detection, node size based on degree --@aheineike #qconsf

@arburbank: @aheineike points out that companies are partnering with universities on machine learning - as uncovered by network analysis #qconsf

@arburbank: Too much ink can get in the way of learning information -@aheineike #qconsf

@arburbank: To simplify network viz: remove weak nodes, dominant nodes, and weak edges. Most people don't tweet. Some never stop. @aheineike #qconsf

@dtunkelang: Filtering out weak data, varying layout algorithms, removing outliers -- all tactics to deriving value from network viz --@aheineike #qconsf

@dtunkelang: More relevant reading for @aheineike's talk: algorithms for detecting community structure in networks. https://t.co/1GM54Cwdl9 #qconsf

@arburbank: Cytoscape, gephi among the tools you can use for network viz if you don't work at Quid. @aheineike #qconsf

Inside Pandora: Ten Years After

by Oscar Celma

Twitter feedback on this session included:

@seanjtaylor: .@ocelma: Pandora keeps a 1% holdout set of listeners to measure effect of accumulated improvements. #qconsf best practice for experiments.

@seanjtaylor: .@ocelma: Pandora measures per segment treatment effects to see which model/product changes work for which groups. #qconsf #experiments

My Three Ex’s: A Data Science Approach for Applied Machine Learning

by Daniel Tunkelang

Alex Handy of SD Times attended this session:

Daniel Tunkelang advocated building machine learning with traceable and explainable building blocks first, then optimizing later.

As with traditional software development, building machine learning algorithms is an iterative process, said Tunkelang. He added that building a complex system from the start will leave you with only one way to measure its effectiveness: the accuracy of the data that comes out.

“Accuracy gives you a very coarse way of evaluating an algorithm,” he said. “It’s very much like debugging code. I’ve gotten a lot of value from linear regression and decision trees. The nice thing about these is that they very clearly favor explainability. The most valuable thing about explainability is that you don’t have to entirely trust your training data if you can debug in this way. But if you have a black box approach, the only indicator you get is that it’s not as accurate as you’d like.”

Daniel Tunkelang summarized his session:

Express: Understand your utility and inputs.

  • Choose an objective function that models utility.
  • Be careful how you define precision.
  • Account for non-uniform inputs and costs.
  • Stratified sampling is your friend.
  • Express yourself in your feature vectors.

Explain: Understand your models and metrics.

  • Accuracy isn’t everything.
  • Less is more when it comes to explainability.
  • Don’t knock linear models and decision trees!
  • Start with simple models, then upgrade.

Experiment: Optimize for the speed of learning.

  • Kiss lots of frogs: experiments are cheap.
  • But test in good faith – don’t just flip coins.
  • Optimize for the speed of learning.
  • Be disciplined: test one variable at a time.

Twitter feedback on this session included:

@arburbank: Defining the objective function may be the most important part of setting up your machine learning problem. @dtunkelang #qconsf

@arburbank: The precision metric in your objective function should include frequency weighting - but needs to value rare things too. #qconsf @dtunkelang

@aerabati: This is the thing with grownups - they always need explanations :) via @dtunkelang #qconsf

@ocelma: #qconsf @dtunkelang talking about ML explainability. Black boxes like deep learning don't help much http://t.co/tpkmGaDZik

@aerabati: Machine learning algorithms wont tell you that your training data is systematically skewed! via @dtunkelang #qconsf

@arburbank: Even if you don't use linear regression or decision trees as your final model, they can be valuable when iterating. @dtunkelang #qconsf

@arburbank: Kiss more frogs faster: better to run many experiments than to spend too much time coming up with one perfect idea. @dtunkelang #qconsf

@dtunkelang: It's true that iterating with small experiments takes time. But big changes will be slower than you anticipated. --@arburbank #qconsf

@COlivier: @dtunkelang on experimenting with ML: "No matter how brilliant you are, your brilliance is often no competition for volume" #qconsf

@aerabati: Optimize your search experiments for the speed of learning! #failfast via @dtunkelang #qconsf

@christianralph: #QConSF Explainability trumps accuracy, start with simple models (linear regression,decision trees) before upgrading @dtunkelang

@christianralph: #QConSF corollary to that. Simple models are easier to explain but less accurate. Iterate towards better accuracy @dtunkelang

Putting the Magic in Data Science @ Facebook

by Sean Taylor

Twitter feedback on this session included:

@arburbank: Data work is basically counting stuff, figuring out the denominator, and making that process reproducible. -@seanjtaylor at #qconsf

@arburbank: data science: finding the niche between analysts and creeping people out in a way that surprises and delights. -@seanjtaylor at #qconsf

@dtunkelang: Data scientists should be more than accountants. Data science should drive decision making. --@seanjtaylor #qconsf

@arburbank: continuum from "maybe this'll be useful" to "I built it; only I can use it" to "people can use this!" is data science @seanjtaylor #qconsf

@dtunkelang: Good question from @seanjtaylor: what is the most magical thing you've seen in data science? Answers span the entire stack. #qconsf

@arburbank: Data can't do anything. *People* do things. Communicating with data is a key part of your job. -@seanjtaylor #qconsf

@markmadsen: Surprise (to me) basis layer for data science underlying amazing tools at Facebook is SQL access - Hive, Presto, Scuba #qconsf

@dtunkelang: Magic: The Gathering of Data -- awesome plug by @seanjtaylor for the value of data collection from novel sources. #qconsf

@markmadsen: Novel sources of data are a source of magic. Data collection infrastructure is a key capability #qconsf

@dtunkelang: Making your own quality data is better than being a data alchemist. -- @seanjtaylor #qconsf

@arburbank: Facebook uses document clustering, dimensionality reduction to understand huge volume of incoming bug reports. -@seanjtaylor #qconsf

@dtunkelang: Another "trick" @seanjtaylor uses for estimating probabilities of rare and new events: James-Stein estimator https://t.co/TsvzeE4DXf #qconsf

@dtunkelang: Distributions are much more powerful than point estimates because they communicate uncertainty, so use a bootstrap. --@seanjtaylor #qconsf

@arburbank: Use the bootstrap to get a sampling distribution on any statistic. Always use confidence intervals. -@seanjtaylor #qconsf

@dtunkelang: More about boostrapping: https://t.co/FDEiSdePi2 #qconsf

@arburbank: Everything is linear if you use enough features. -@seanjtaylor #qconsf

@arburbank: getting data science to be adopted #1: reliability. how do you anticipate when the data will break your product? -@seanjtaylor #qconsf

@arburbank: getting data science to be adopted #2: latency & interactivity. Test more things per second if your system moves fast. @seanjtaylor #qconsf

@arburbank: yes! the easier you make it to get answers, the more questions people will ask. @Pinterest's data-driven culture exactly. #qconsf

@arburbank: getting data science to be adopted #4: unexpectedness. Is your data telling people something they don't already know? -@seanjtaylor #qconsf

@dtunkelang: Great idea from @seanjtaylor: test-driven data science -- test-driven development https://t.co/NP8A9XAOPs for data scientists. #qconsf

@dtunkelang: Speed doesn't just provide more answers per second. It gets people to ask more questions. --@seanjtaylor #qconsf

@dtunkelang: Show people the most interesting things. --@seanjtaylor Also see @avinash's 2012 #strataconf keynote http://t.co/WKWpnPlKdf #qconsf

Too Big to Fail: Running A/B Experiments when You're Betting the Bank

by Andrea Burbank

Twitter feedback on this session included:

@dtunkelang: It's true that iterating with small experiments takes time. But big changes will be slower than you anticipated. --@arburbank #qconsf

@dtunkelang: Companies need to recognize & reward incremental change vs over-rewarding big changes. Let's call it "faster learning". --@arburbank #qconsf

@aerabati: Recognize incremental change is faster than big change! Incremental change should actually be called "faster learning"! #qconsf

@dtunkelang: Do incremental changes constrain us to local maxima? Maybe, but big changes can be big losses, not just big wins. --@arburbank #qconsf

@dtunkelang: Making a big change all at once is a gamble that things will be better, and it masks negative components of the change. --@arburbank #qconsf

@dtunkelang: Argument against running an experiment: "we've already told the press about it". I've lived through that one. :-) from @arburbank at #qconsf

@dtunkelang: Opt-in features nice but no substitute for controlled, randomized experiments. Esp since opt-in users are more engaged. --@arburbank #qconsf

@dtunkelang: You need to set the goal posts for ship decisions in advance. Otherwise you'll always be tempted to move the goal posts --@arburbank #qconsf

@aerabati: Purpose of experimenting is to figure out when we/you/companies can ship! via @aburbank #qconsf

@dtunkelang: Shipping a redesign doesn't mean that you're done. Ship and keep iterating. --@arburbank #qconsf

Architectures You've Always Wondered About

Etsy Search: How We Index and Query 26 Million One-Of-A-Kind Items

by Aaron Gardner

Twitter feedback on this session included:

@aerabati: Etsy dont do/need real time indexing at this point. Good example of not over engineering when not needed! #qconsf

@philip_pfo: Downside of microservices - silo risk. Interesting that etsy favors larger services for eng culture benefits. #qconsf @aargard

@aerabati: Etsy likes to kill not-so-simple architectures eg: turbocharging solr index proj #qconsf

Software Development & Architecture @ Linkedin

by Sid Anand

Andrew Hao attended this session:

Startup mode

  • Systems built during startup lifetimes can’t stand public growth.
  • 300+ code projects in a single SVN repo
  • Testing code locally meant deploy every service locally!
  • 24 hrs of integration testing – you find you broke master
  • 3 hours writing code, you check it in, 3 days to commit it.

LinkedIn Search

  • LinkedIn archives several indices
  • each search engine has its own search score
  • LI tries to guess your intent when you search and query the right indices.
  • query rewriting: “sr swe” can be “senior software eng” or “sr soft engineer”
  • Galene Architecture: built on lucene. real time indexer, updates indices between hadoop builds

Twitter feedback on this session included:

@aerabati: Partition your user base across the data centers! #linkedinarchitecture #qconsf

@aerabati: Intent detection done by SearchFederator #LinkedinSearch #qconsf

@aerabati: So, what does Linkedin use for their search federation? Galene! #qconsf

Tumblr - Bits to GIFs

by John Bunting

Andrew Hao attended this session:

  • sharding: jetpants
  • php, haproxy, hdfs
  • s3 for image storage
  • Scala services: 90% of the time. Built in a world where Go didn’t exist
  • finagle –> colossus
  • Thrift
  • Protobuf
  • hbase stores notifications
  • firehose
  • job queue: gearman
  • Varnish caching: using DJB2 hashing for consistent hashes – balanced against

Deployment

  • deployment used to take an hour for 500 servers
  • DUI is deployment tool
  • Need 2 people from your team + staff/sr engineer
  • get into an IRC deploy queue
  • Deploy canary first
  • Tumblr deploys over 40x a day
  • Fibr is a graphing tool. so everyone can feel empowered to see root problems
  • your engineers need to be empowered to understand tools.
  • func is installed on any server at any point in time. “give me the server”

You Won't Believe How the Biggest Sites Build Scalable and Resilient Systems!

by Philip Fisher-Ogden &Jeremy Edberg

Andrew Hao attended this session:

  • 20% of org is dedicated to maintaining platform — internal PaaS
  • Microservice architectures organized around teams
  • Automate everything you can: tools, builds, images.
  • You want your revenue to grow faster than your org
  • Continuous integration – code deployed as soon as possible.
  • Self service: Try to make everything as self-service as possible. Make it easy for engineers to set up their own deployments, their own monitoring.
  • Monitoring: Do it from the beginning! Emitting events. See Etsy. Open sourcing the system soon. Make sure that they own the dashboard, so they can
  • Break things on production: Embrace failure. See: Netflix Simian Army.
  • Incident review: Blameless culture
  • Caching. Huge way to give users best experience. Write data to cache + queue.
  • Cassandra: used for consistent key hashing multi data center Think of SSD as cheap ram, not expensive disk

Lambda/Kappa Architecture

  • Lambda: Idea of having two parallel data streams. One is accurate, slow, one is approximate, fast. Have queries combine the two.
  • Kappa: Always use the correct stream

Twitter feedback on this session included:

@aerabati: Make it easy to for your teams to Monitor their own stuff. Netflix does this! #qconsf #selfservice

@aerabati: Do you break things in production to test resiliency of your own systems? #architecturetalk #qconsf

@aerabati: Shared state should be stored in a shared service! #notetoself #qconsf

@aerabati: Monitoring should be a firstclass citizen and not a afterthought! #qconsf

@rchakra1: Netflix gen4 architecture -> Stateless #microservices #qconsf

@flaviavanharten: Netflix did 3 redesigns in 6 years. Inspiring talk on scalable architectures at #qconsf

@portixol: .@philip_pfo at #QConSF Netflix organise their teams like microservices, small and with an API contract between teams

@QConSF: .@jedberg @philip_pfo on design patterns the most successful companies use to go from nothing to billions. #qconsf http://t.co/XWEHoBBcuW

Beyond Hadoop

Unified Big Data Processing with Apache Spark

by Matei Zaharia

Twitter feedback on this track included:

@rchakra1: Map Reduce lacks efficient data sharing @matei_zaharia #ApacheSpark #Qconsf

@rchakra1: Data sharing in #MapReduce is slow due to data distribution and disk I/O @matei_zaharia #ApacheSpark #qconsf

@davidgev: Nice results from Apache Spark, I guess time to rewrite map-reduce jobs #qconsf #ApacheSpark http://t.co/WBulg7NqpV

@rchakra1: MapReduce can emulate any distributed system @matei_zaharia #ApacheSpark #Qconsf

@rchakra1: In Apache Spark, users can control data partitioning and caching @matei_zaharia #qconsf

@rchakra1: #ApacheSpark can leverage most of the latest innovations in databases, graph processing, machine learning. @matei_zahara #qconsf

@vpothnis: Apache #Spark - Unified engine for #batch, #streaming, #interactive processing. Awesome talk by @matei_zaharia at #qconsf

Continuous Delivery: From Heroics To Becoming Invisible

Twitter feedback on this track included:

@bjorn_fb: Continuous Delivery: if you're doing it right, nobody knows you're doing anything - @sdether #QConSF

@dserodio: Continuous Delivery is about removing the bottlenecks that stop you from delivering faster #qconsf

Continuous Delivery for the Rest of Us

by Lisa Van Gelder

Twitter feedback on this session included:

@sdether: Problem w/ many release processes: the person causing the pain isn't the one feeling the pain -- @techbint #qconsf

@sangeetan: A release should be a non-event. @techbint #qconsf #continuousdelivery

@jstnm: Ignoring "blocked" status on your board is like ignoring your tests, it is telling you something is wrong @techbint #qconsf

@QConSF: .@techbint on successful #continuousdelivery: culture and process are as important as tools and automation #qconsf http://t.co/xFgSfSmTqI

How We Learned to Stop Worrying and Start Deploying the Netflix API Service

by Sangeeta Narayanan

Twitter feedback on this session included:

@sdether: Netflix API team motivation for adopting Continuous Delivery: Stop being the Bottleneck! @sangeetan #qconsf

@aerabati: 3 week major release + weekly incremental release cycle helped netflix gain some sanity! #qconsf

@mshah_navis: Get rid of the code freeze #qconsf

@modethirteen: Weekly release cadence @netflix with every 3rd release for big features and all others for fixes @sangeetan #qconsf http://t.co/fwAHznx6JI

@sdether: Netflix API runs tests for each pull request and if no reviewers were explicitly specified, auto-merges passing pull requests #qconsf

@staffanfrisk: 1500+ metrics compare the new code with the old in the Netflix CI-chain. Impressive! #QConsf http://t.co/fuKnju0rhF http://t.co/Duo9lQibRk

@aerabati: Having an agile architecture makes continuous delivery lot easier at netflix #qconsf

@techbint: How do you test in the cloud when everything is changing all the time? Many levels of canaries. Dependency testing. @sangeetan #qconsf

@portixol: 'We don’t have an Ops team as such, each team does their own ops’ @sangeetan on Netflix continuous deployment #qconsf

@portixol: Having developers doing their own ops doesn't decrease velocity, they'd be involved anyhow, just makes it more efficient #qconsf @sangeetan

@LeneHedeboe: #continuousdelivery: Netflix deploys services to multiple AWS regions many times a week #qconsf @sangeetan http://t.co/vdpYnGnxOH”

The Art of the Builds

by Hans Dockter

Twitter feedback on this session included:

@sdether: Don't build frameworks. Build toolkits. Then you can create lightweight frameworks on top of those toolkits/via @hans_d #qconsf

@techbint: Your build system should be domain driven just as much as the code - don't throw away domain knowledge at build time. #qconsf #gradle

@flaviavanharten: #ddd as an inspiration to modeling n building #gradle. Awesome talk by Hans Dockter at #qconsf on "the art of builds"

Deploying at Scale

Containerization Is More than the New Virtualization

by Jérôme Petazzoni

Alex Handy of SD Times attended this session:

Petazzoni explained that the benefits of Linux containers extend beyond the ability to host multiple applications on a single server.

“Containers are just processes isolated from each other,” he said. “When I start a container, I am starting a normal process, but it has a stamp that says it belongs to a container. That extra stamp is very similar to the User ID you have in a process. It can belong to root, or UID 1000.”

Petazzoni added that in sharing information between containers, the path to communication is much simpler than when using virtual machines. Virtual machines often have to use networking in order to communicate between VMs even when they are hosted on the same machine.

Because containers use fine-grained namespaces, Petazzoni said that individual containers can be isolated, or they can share the same namespace as other containers, and thus be allowed to communicate across the namespace.

Real-World Docker: Past, Present, and Future

by Jeff Lindsay

Twitter feedback on this session included:

@jsoverson: dokku was the gateway drug for people getting into docker #qconsf via @progrium

@sangeetan: docker not all about containers;its a primitive for building modern platforms/architectures @progrium #qconsf

@SashaO: #qconsf Jeff Lindsay @progrium : you don't want config managers (Chef, Puppet, Salt) with docker installs. CM is for non-docker systems

@vivekvaid: @progrium likes lightweight @docker vs @OpenStack #qconsf Reminds me of the @Gartner_inc hype cycle. Time to ditch VMs already?

Engineering Culture

Building Conscious Engineering Teams

by Rob Cromwell

Twitter feedback on this session included:

@aerabati: Biggest threat to engineering teams is hiring DIVAs (D.I.V.A - Difficult, Infallible, Victim & Arrogant) - via Rob Cromwell #qconsf

@rundavidrun: Having a "gifted" dev is like meth, says @robertcromwell, on it he can do anything! When he comes down you've got a horrible mess. #qconsf

@johnscattergood: 3 traits required for high performing teams #qconsf http://t.co/a8aokFAlzl

@arburbank: When a pen falls, is it due to gravity or because I dropped it? Choose the answer that will help solve the problem. @robertcromwell #qconsf

Careevolution: Building a Company through Ambiguity, Judgment, Trust, and Worklife Fusion

by Vik Kheterpal

Andrew Hao attended this keynote:

  • Completely decentralized. Decisions made by consensus
  • culture of overwork in silicon valley
  • Do we need Scrum masters? we don’t trust people to do things themselves
  • Self-directed teams can STILL apply to mission critical systems and important industries.
  • Individuals are center: process serves the individual. all individuals yearn to be productive.
  • Teams are nothing more than individuals working toward a common goal with trust in one another
  • if we can’t trust each other then we need to start over. Lack of trust is a mortal weakness.
  • Management is not a title or role, but an activity to be performed by the individual. We are all managers!
  • Work and life are not two opposing forces: it’s both.
  • size brings complexity
  • ambiguity and the need for judgment: embrace ambiguity. with time, the org is less capable of doing things, instead of doing more
  • you can’t tie compensation to titles
  • Doing good is good business
  • Run the business as if it’ll be there for 100+ years. Beyond you. So be wary of professional investors who want to see short term gain. Question if there really is a first mover advantage.

Netflix: “Responsible person”

  • Self-motivating
  • Self-aware
  • Self-disciplined
  • Self-improving
  • Acts like a leader
  • Doesn’t wait to be told what to do
  • Never feels “that’s not my job”
  • picks up the trash lying on the floor
  • Behaves like an owner

Twitter feedback on this session included:

@dmarsh: Find simplicity in complex things ... helps self-directed teams make good choices. #qconsf Engineering Culture

@dmarsh: Work exists to serve the needs of the individual and their family not the other way around. Vik Kheterpal. #qconsf Engineering Culture.

@rchakra1: self directed teams should believe in work-life fusion says Vik Kheterpal #qconsf Engineering culture

@dmarsh: Measures of success are independent of size. Vik Kheterpal. #qconsf Engineering Culture.

@dmarsh: Trust people to deal with ambiguity. Develop their judgment muscles. #qconsf Engineering Culture.

@rchakra1: The traditional link between compensation and title/role is flawed. Vik Kheterpal at his Engineering culture talk #qconsf

@johnscattergood: Seek to hire people with these characteristics #qconsf http://t.co/jpmy2bOkFS

@rundavidrun: As a leader, demand that bias be turned to action and devs will realize that arguing a lot about something is volunteering to do it. #qconsf

Growing Up Spotify

by Simon Marcus

Twitter feedback on this session included:

@arburbank: Spotify is an adhocracy. It's specially designed for innovation and fostering dissent. @lycaonmarcus #qconsf

@arburbank: Growing up Spotify: while we like incrementalism and testing, we also try to keep an eye on where we are headed. @lycaonmarcus #qconsf

@arburbank: Being an adhocracy also makes it very difficult to get things done, and we talk for a long time to achieve consensus. @lycaonmarcus #qconsf

@philip_pfo: Ideas are better built together. Innovate ideas require debate to evolve; discouraging dissent risks mediocrity. @lycaonmarcus #qconsf

@techbint: You can't build a unified experience with silo'd teams - feature squads help. @lycaonmarcus #qconsf

@arburbank: Spotify wanted to be able to spin up new missions quickly. A tribe is 70-130 folks, with dev, PM, design leader trio. @lycaonmarcus #qconsf

@dmarsh: Mentoring at Spotify is critical given that they hire a large number of junior staffers. @lycaonmarcus #qconsf

@rundavidrun: .@lycaonmarcus at #qconsf: @Spotify focuses on long-term effectiveness over short-term efficiency.

@ShoReason: When something goes wrong, we don't play the blame game we look to see what in the system allowed it to happen - @lycaonmarcus #qconsf

The Evolution of Engineering Culture: Oh, the Places We've Been

by Melissa Pierce

Andrew Hao attended this keynote:

  • Grace Hopper: Ph.D in mathematics at Yale
  • Babbage machine
  • 1842-1843: she wrote elaborate set of notes
  • Look at ads and how they portray women. Women as commodities, cheap
  • women were strong in math. it wasn’t perceived as being professional enough. engineering was masculine. CS moved to be an “engineering” degree
  • the drop and decline in women in CS happened around the time of its alignment with engineering

Takeaways:

  • How can our field recognize the contributions of women in CS? How can we make our field more inclusive and accessible to women in tech?

Engineering for Product Success

Engineering the Resolution Center to Drive Success at Airbnb

by Alvin Sng

Twitter feedback on this session included:

@philip_pfo: More data -> more opportunity. Bring structure to formerly unstructured data, gather where not gathered. @alvinsng #qconsf

Evolution of the PayPal API Platform: Enabling the Future of Money

Andrew Hao attended this session:

Paypal used to have a fragmented, legacy API ecosystem. Circa 2012, they began an initiative to standardize and modernize their API infrastructure.

  • API first
  • API as a product
  • REST first

Architecture:

  • Built using facades
  • Facades coordinate between internal services (microservices?)
  • Tiered approach: experience APIs (facades) and capability APIs (core services)
  • How did they assess success? Did a maturity model. Level 1-5
  • People got into competitions
  • Used DDD – bounded contexts – shared language
  • Evolution is more than technology

Experimenting on Humans

by Talya Gendler & Aviran Mordo

Twitter feedback on this session included:

@techbint: A/b tests don't mean that new feature has to win - it just has to not do worse than existing features @aviranm #qconsf

How Ebay Puts Big Data and Data Science to Work

by Mike Mathieson

Twitter feedback on this session included:

@arburbank: You no longer need a SAS license to do data science. The competitive edge is in how you use your data. - Mike Mathieson at #qconsf

@arburbank: It's easy to create a lot of data reports without actually creating a product that leverages your data. - Mike Mathieson #qconsf

@randyshoup: Data science is relevant iff it is put into practice in a product (not just answering a question) - Mike Mathieson #qconsf

@arburbank: Bad data science has long periods of silence. Someone hides in a corner and you don't know when they'll come back. - Mike Mathieson #qconsf

@arburbank: People aren't very good at coming up with heuristic weighting schemes when there are more than a dozen variables. -Mike Mathieson #qconsf

@arburbank: Advantage of switching from heuristics to machine learning: can devote your efforts to finding new sources of data. -Mike Mathieson #qconsf

@arburbank: It's better to start simple and go from there than to try to design the perfect thing up front. - Mike Mathieson #qconsf

@arburbank: As infra improves, you spend more time on features and less on experimental tools, modeling, and data acquisition. -Mike Mathieson #qconsf

@randyshoup: Real world data science is almost all about data and feature selection instead of algorithm development - Mike Mathieson #qconsf

@randyshoup: Need engineering discipline in data science: speed of model execution + experimentation, training data generation - Mike Mathieson #qconsf

@arburbank: Celebrate failed experiments - but only if you learn something! -Mike Mathieson #qconsf

@dtunkelang: Question for all you data scientists: do you need to ethically justify having a holdout set that doesn't benefit from improvements? #qconsf

Metrics-Driven Prioritization

by Sam McAfee

Twitter feedback on this session included:

@rchakra1: Innovate or Die says @sammcafee in his "Metrics driven Prioritization" talk at #qconsf

@aerabati: Good product is at the Intersection of Usable, Feasible and Valuable! via @sammcafee #qconsf

@aerabati: Modern day engineer not only needs to understand the business model of the company but also must understand growth model! @sammcafee #qconsf

@aerabati: Information value = Economic impact * uncertainity #qconsf

Java at the Cutting Edge

Stuff I Learned about Performance

by Mike Barker

Twitter feedback on this session included:

@flaviavanharten: If you cannot talk about trade offs, then you are just a fan person waving a coffee mug... Talk on performance by @mikeb2701 at #qconsf

@flaviavanharten: Java vs C/C++ ... Java is fast. Certainly no reason to choose C/C++ over Java for performance reasons. Talk by @mikeb2701 at #qconsf

@absynthmind: Let the problem define the solution. Design without bias… And not just for high-performance software #qconsf

@rzanner: @mikeb2701: Try to solve problems w/o bias, i.e. w/o bringing your favorite tools #qconsf

Modern CS in the Real World

The Evolution of Testing Methodology at AWS: from Status Quo to Formal Methods with TLA+

by Tim Rath

Alex Handy of SD Times attended this session:

Tim Rath discussed testing strategies used at the company. He echoed keynote speaker Leslie Lamport by admonishing developers in the audience to write specifications for their code.

“Every class I turn in has to have some specification to it,” he said. “You should be writing things that you know about in the code: How does this interact with other parts of the system? What is its purpose in life? I will put the interaction diagrams in there. Ultimately, I am looking for those truths that I can test and describe, and describe them well.”

The Quest for the One True Parser

by Terence Parr

Alex Handy of SD Times attended this session:

Terence Parr, professor of computer science at the University of San Francisco, enlightened QCon attendees about the power of his parsing research. Parr has devoted his research to increasing the strength of the simple and efficient top-down LL parsers, culminating in the powerful ALL(*) strategy of ANTLR 4.

“I’ve made this as powerful as possible, and I’m trading that last bit of generality for performance,” he said.

Parr’s ANTLR parser optimizes itself after a successful parse, and given the same file a second time, it can parse it significantly faster than more generalized parsers. Parr said he’s finally completed his work on parsing science after 25 years of work, and he’s not quite sure what he’ll be working on next.

Reactive Service Architecture

Philipp Garbe’s attended this track:

Microservices were everywhere. Even startups showed how they use a microservices based architecture. To ensure the code quality you often heard about dependency tests which are part of the build pipeline. If you break these tests you cannot deploy your service.

When you have microservices you also need a strong ownership. Teams own few services and are completely responsible for them. This also includes that devs are on call rotation.

Comparing Elasticity of Reactive Frameworks

by James Ward

Twitter feedback on this session included:

@hbrumleve: @_JamesWard rocking reactive elasticity @QConSF ... Way more to it than just scaling hardware. #qconsf http://t.co/5pCOFJ3nXv

@hbrumleve: @_JamesWard may have just coined the term "going reactivist" @QConSF #qconsf http://t.co/mMzrxRSCdJ

Concurrency at Large-Scale: the Evolution to Reactive Microservices

by Randy Shoup

Andrew Hao attended this session:

Microservices: loosely-coupled service oriented architecture with bounded contexts

  • single purpose
  • simple well-defined interface
  • modular and independent
  • more a graph of relationships than tiers
  • isolated persistence!
  • each unit is simple
  • helps your company scale. people can hold it in their heads.

Reactive microservices:

  • first tenet is to be responsive, fail latencies, async nonblocking calls from client
  • resilient: redundancy, timeouts, retries. hystrix
  • “release it” book my michael nygard
  • elastic: can scale up and down according to load.
  • message-driven: message passing
  • FRP patterns: actor model
  • scala/akka + rxjava

How to do this?

  • Don’t migrate in one big bang. do it incrementally.
  • find your worst scaling bottleneck
  • wall it off behind an interface
  • replace it
  • then do it again

Twitter feedback on this session included:

@vpothnis: 'no shame in matching architecture to problem scale' - @randyshoup at #qconsf

@philip_pfo: Architecture should match the problem - don't over engineer from the start; evolve as you grow. @randyshoup #qconsf

@sammcafee: No shame in simple 3 tier app if that's where you currently are. @randyshoup #qconsf

@codingjester: If you don't end up regretting your early technology decisions, you probably over-engineered #qconsf @randyshoup

@vpothnis: if you get to re-architect, thats a sign of success - @randyshoup talk at #qconsf

@SashaO: #qconsf @randyshoup Google Cloud Datastore example: Cloud Datastore (6 people) -> Megastore -> Bigtable -> Colossus -> Cluster mgt infra

@sangeetan: Layered microservices allow very small teams to achieve very great things @randyshoup #qconsf

@vpothnis: predictable performance at 99th percentile trumps low mean latency - @randyshoup talk on #reactive systems at #qconsf

@SashaO: #qconsf @randyshoup Kixeye's microservices framework: https://t.co/hWrKomvDJf ; sync, async using a lot of Netflix OSS stack

@philip_pfo: The only thing you are guaranteed to get with a big bang arch evolution is a Big Bang @martinfowler via @randyshoup #qconsf

@philip_pfo: Build one to throw away (prototype). Next one will be better, less risk of second-system syndrome. @randyshoup #qconsf

@philip_pfo: Set the goal, not the path. #leadership @randyshoup #qconsf

@SashaO: #qconsf @randyshoup microservices in the org: many relationships become vendor-customer

@vpothnis: cost allocation and charging can help motivate both customer and provider to optimize - @randyshoup on building #microservices #qconsf

@stonse: Charge users of your #MicroService for usage of your service -> great point for gaining efficiency by @randyshoup at #qconsf

@christianralph: #QConSF @randyshoup describes an internal service cost structure at google to create a market economy encouraging fair usage/behaviour

Reactive Programming with Rx

by Ben Christensen

Andrew Hao attended this session:

  • Observables vs Iterables. Push vs Pull.
  • Observable is at the core: abstraction of events over sets.
    • Prefer Observable over Future because Future is still fragmented in Java ecosystem.
  • Using Rx services that aggregate granular APIs.

Error handling

  • Flow control: You need backpressure when you hop threads. what do you do when you consume slower than producer? Often necessary in UIs
  • Hot vs Cold source: Hot: emits whether you’re ready or not. mouse event.Cold: emits when requested: HTTP request.
  • Approach: block threads. like iterables.
  • Hot streams: use temporal operators: like sample or debounce
  • Buffer, debounce, buffer pattern – can group signals by temporal
  • Reactive push: hot infinite stream: Buffer by time window, drop some samples if appropriately, do map/reduce on windows

Mental shift

  • imperative –> functional
  • sync –> async
  • pull –> push
  • Rx doesn’t trivialize concurrency. You need to reason about what’s going on underneath.

Philipp Garbe’s attended this session:

Reactive Extensions (Rx) is definitely a technology I have to evaluate further. Netflix showed how they use Rx to solve problems with race conditions, uncaught exceptions from async calls and concurrency.

“Concurrency and async are non-trivial. Rx doesn’t trivialize it. Rx is powerful and rewards those who go through the learning curve.”

Real World Functional

Functional Systems @ Twitter

by Marius Eriksen

Andrew Hao attended this session:

  • Key component is managing/reducing incidental complexity
  • (scala): Futures: containers for value. Use composition operations.
  • Presenter demonstrating how to build a search engine in scala with composable operations
  • FP helps in “separating mechanics from semantics” – the bind function
  • A service is an async function: takes a request and returns a Future reply.
  • “your server as a function”: http://monkey.org/~marius/funsrv.pdf

By modeling apps as composable services, you can reason well about your programs. Example is finagle, which is just a composition of services

  • “composability is one of the great ideas of functional”
  • Good tool for enforcing modularity

Scalable Microservice Architectures

Building and Deploying Microservices with Event Sourcing, CQRS and Docker

by Chris Richardson

Andrew Hao attended this keynote:

Microservices

  • Corresponds to a DDD aggregate
  • requests from outside world => commands
  • Processed by svc, generates events
  • Can also subscribe to events over the bus

CQRS

  • commands process aggregates
  • queries build views from events
    • view is a store
    • view updater service syncs the view with events
    • view query service generates the view from the view store

Docker

  • Jenkins deploy pipeline: Build & test code + build & test docker image + deploy docker to registry
  • Smoke test the image:
    • POST /containers/create, POST /containers/{id}/start
    • ping /health URL
  • tag image, then push image
  • takes seconds to build, deploy!
  • Jenkins is on Docker, too!

Deployment to prod

  • Diffs running dockers against build dockers, then deploys the changed containers.
  • Mesos + marathon + zookeeper

Twitter feedback on this session included:

@echinopsii: #microservices : use dedicated DB for each modules according to functional needs. #qconsf

@rchakra1: @crichardson explaining Event Sourcing. Before: Update State + Publish Events. Now: Persist and Publish Events #microservices #qconsf

Organizing Your Company to Embrace Microservices

by Paul Osman

Andrew Hao attended this keynote:

First thing: changed search/infrastructure

  • naturally asynchronous, off the critical path part of our infrastructure
  • rewrote the indexer in go
  • used to take 20hr to do a full build, now it takes 20m in Go
  • wrote search service layer – extracted out of app

Next: uploads

  • EC2-based go uploaders
  • Natural pair with S3

Lessons

1) DevOps

  • Do 12-factor apps
  • Monitor everything. They use datadog — hosted graphite
  • Implement an on-call rotation
  • Measure MTTD (detect), MTTR (resolve). Work to implement changes
  • Test your failover scenarios

2) Automation

  • Automation
  • Use circuit breakers
  • Michael Nygard: use circuit breakers. Try to recover from external failure scenarios.

3) Design for business capabilities

  • Break app into biz capabilities (search, reco, uploads)
  • Tempting to design around tech layers. don’t
  • treat each biz capability as a team

Twitter feedback on this session included:

@aerabati: Failures happen in prod - Optimize for 'Responding to failures' and not 'avoiding failures' ! #micro-services #qconsf

@aerabati: If possible - deploy in one command and provision hosts in one command! #oodaloop via @paulosman #microservices #qconsf

@aerabati: Embracing Microservices Tip - Dont design around technology layers - frontend, backend etc #qconsf via@paulosman

@aerabati: Big benefit of cross functional teams - You can easily move people around when required! #embracing-microservices #qconsf

@techbint: Need to balance autonomy of team against feeling of neglect. Align tribes & chapters. @lycaonmarcus #qconsf

@zimmermatt: Even if you don't (yet) have the size, treat each business functionality as a team @paulosman #QConsf

Scalable Microservices at Netflix. Challenges and Tools of the Trade

by Sudhir Tonse

Twitter feedback on this session included:

@philip_pfo: Production outages produce the best learnings. We've converted those into hardened #NetflixOSS offerings. @stonse #qconsf

@ShoReason: Netflix supports more than 500 micro services @stonse #qconsf

@philip_pfo: Distributed systems are inherently complex - microservices doesn't solve that but does expose it. @stonse #qconsf

@techbint: Only three things are certain in life: death, taxes and outages in production. @stonse #qconsf

@zimmermatt: Microservice best practice: Reduce/avoid hot spots @stonse #qconsf

@zimmermatt: Microservice best practice: Use red/black deployment @stonse @NetflixOSS #asgard #qconsf

@rzanner: @stonse monolithic apps like trains: when 1 wagon catches fire, you have to stop the whole train #qconsf

The Future of Mobile

Building Pinterest's Mobile Apps

by Mike Beltzner & Garrett Moon

Twitter feedback on this session included:

@rundavidrun: .@beltzner at #qconsf: Pinterest builds in special feature for employees dogfood-testing the next mobile release: shake to report bugs.

@arburbank: You are the only person who is desperate for your new feature. @beltzner on experimenting before shipping at #qconsf

@arburbank: Users who review your mobile app before you ask them to are often angry - but their feedback will help you improve. @beltzner at #qconsf

@arburbank: Predictability of the mobile app release schedule ensures that no bug is too costly and helps feature planning. @beltzner #qconsf

@rundavidrun: .@beltzner at #qconsf shows @Pinterest's release "train" 3-week cadence. Large features are split over a few cycles. http://t.co/yBYsabu9A2

@arburbank: Apps hanging may be even worse than apps crashing because users don't know how to escape. @garrettmoon at #qconsf

@arburbank: Reducing the app startup time on android tablet increased the number of pins viewed by 30%! @garrettmoon #qconsf

@aerabati: Avoid unwanted image requests and API calls on app startup ! Pinit talk at #qconsf!

@arburbank: Many crashes are specific to particular device/OS combos, so more specific crash reporting is key. (Also for AB tests!) #qconsf @garrettmoon

@aerabati: Pinit guys use cocoapods to manage their external dependencies! #qconsf

Facebook’S iOS Architecture

by Ari Grant

Twitter feedback on this session included:

@GMilano: iOS Facebook team use a declarative "objc++" to declare feeds in order to avoid maths, threads, etc when programming #qconsf

Less, But Better

by Michael Garvey

Twitter feedback on this session included:

@rundavidrun: .@michaelgarvey at #qconsf: bad design surprises us with disruption, good design surprises us with beauty. Same is true for code.

Open Spaces

Twitter feedback on open spaces included:

@rkasper: 95 people at our first #openspace! #qconsf rocks! http://t.co/Q25ltQjYpu

@rkasper: Wherever it happens is the right place #openspace principle in full use! #architecture #qconsf

@rkasper: All it takes is a little passion... and they rush the center of he circle! Amazing #OpenSpace in the #qconsf #continuousdelivery track!

Tutorials

Domain Driven Overview

by Eric Evans

Twitter feedback on this tutorial included:

@zimmermatt: Why bother with models? The critical complexity of many software projects is in understanding the domain itself. @ericevans0 #qconsf

@zimmermatt: DDD Guiding Principle: Focus on the core domain @ericevans0 #qconsf

@zimmermatt: DDD Guiding Principle: Explore /models/ in creative collaboration with domain practitioners and software practitioners @ericevans0 #qconsf

@zimmermatt: DDD Guiding Principle: Speak a ubiquitous language within an explicitly bounded context @ericevans0 #qconsf

@zimmermatt: We want models that allow us to make simple, clear assertions; we can only do this within a bounded context. @ericevans0 #qconsf

@zimmermatt: It's not simply having a model, it's having one that fits the scenario. Use http://t.co/7nD4I7ZviB @ericevans0 #qconsf

@zimmermatt: Not all of a large system will be well designed. @ericevans0 #qconsf

@zimmermatt: If the Chief Architect has convinced the CTO there is "the one true model," run away... it's not going to end well. @ericevans0 #qconsf

@zimmermatt: Distill the core domain @ericevans0 #qconsf http://t.co/jPGzNXlrpp

Opinions about QCon

Opinions expressed on Twitter included:

@philip_pfo: Hacking the conference UX - love the format variation at #qconsf: lunch together or alone, open space, early adopter technology focus

@rundavidrun: This year at #qconsf, they have a "hallway track": long breaks to facilitate peer sharing, which is sometimes more valuable than speakers.

@eduardk: Woke up to this view. Not a bad way to start the day at #QConSF /C @HyattRegencySF http://t.co/wxfh61Q62p

@aerabati: Veg Biryani for lunch? How often do you see that at tech conferences in US? Thanks #qconsf

Philipp Garbe’s opinion on QCon was:

It seems that people in San Francisco are very healthy. There were no soft drinks, just water, tea and coffee. Also the food was more for vegetarians. I missed some good old American steaks :)

Karan Parikh’s opinion on QCon was:

QCon was an incredible conference, and I learned a lot. Can’t wait for QCon 2015.

Takeaways

Andrew Hao’s takeaways were:

  • Big trends in continuous delivery and deployment — deploy more often, smaller feedback loops
  • A lot of emphasis on event driven architectures + microservices. Lots of emphasis on DDD as a design tool.
  • Reactive systems with functional implementations were widely discussed as a scaling tool (backpressure-sensitive) and as a coordination tool between multiple async services.
  • A lot of talk about microservice orchestration tools — acknowledging the pain of configuration and management of many services.
  • Scala got a lotttt of attention. Probably because of its presence in bigger companies like Netflix, Twitter, LinkedIn. Wonder what smaller startups are using.
  • Web Components were a big upcoming trend in frontend technologies. Strong modularization of views + behaviors in HTML documents.

Philipp Garbe’s takeaways were:

If I had to describe the conference this year in three words it would be: reactive,functional & microservices. Obviously that´s my opinion. There were also a lot of other talks about engineering culture, continuous deployment and architectures and and and. Unfortunately, I couldn’t attend them all. …

To enforce communication the organisators of the QCon came up with nice ideas. One idea was a new designed badge. Sounds not like a big thing, but somehow the big first name forced you to look on the badge. I came in contact with many guys just because I or he looked on it….

Second idea was topic tables. During lunch they prepared some smaller tables (max 4 persons) with a topic (e.g. Big Data, Culture, Functional). So you had the chance to come in contact with others because you were interested in the same topic.

And there was also the traditional conference party at Thirsty Bear on Monday evening. The whole bar (2 floors) was crowded by nerds and beer and food was for free.

@pgarbe: I have to go to #qconsf again to become gold alumni and get the fancy q-tshirt. Of course that´s not the main reason. When you work as web developer this conference is a must. Not only they provide trending topics and interesting insights but you have also the chance to extend your network with smart people.

Conclusion

The eighth annual QCon San Francisco brought together 1,200 attendees and more than 100 speakers in what was the largest ever QCon to be held in the US. QCon's focus on practitioner-driven content is reflected in the fact that the program committee that selects the talks and speakers is itself comprised of technical practitioners from the software development community.

Presentations and interviews from the event will be posted on InfoQ over the coming months.

QConSF 2014 was produced by InfoQ.com. Other upcoming QCons include:
• QCon London March 2-6, 2015
• QCon São Paulo March 23-27, 2015
• QCon New York June 8-12, 2015
• QCon Rio De Janeiro August 24-28, 2015

Visit http://qconferences.com/ to see a complete list of our upcoming events.

Rate this Article

Adoption
Style

BT