Now in its eighth consecutive year, QCon London 2014 featured thought-provoking and engaging keynotes from Perl Boffin Damian Conway, XML inventor Tim Bray, Atlantic Systems Guild Principal and Peopleware co-author Tim Lister and mathematician Dr. Gunter Dueck.
Around 1,100 team leads, architects, and project managers attended 120 technical sessions across 7 concurrent tracks, 11 in-depth tutorials, facilitated open spaces and, for the second time this year, had instant access to all filmed presentations from the event on InfoQ.
This article summarizes the key takeaways and highlights from QCon London 2014 as blogged and tweeted by attendees. Over the course of the coming months, InfoQ will be publishing most of the conference sessions online, including video interviews that were recorded by the InfoQ editorial team. The publishing schedule can be found on the QCon London web site. You can also see numerous attendee-taken photos of QCon on Flickr.
- Advanced Functional Programming by Erik Meijer
- Design & Implementation of Microservices by Jim Barritt, James Lewis
- Embracing Change: Building Adaptable Software with Events by Russell Miles
- Problem-solving and Decision-making in Software Development by Linda Rising
- Systems Thinking and Methods by Michael T. Nygard
- Back to the Future: What Old Thinkers Can Teach Us about Making Innovation Succeed Today by Emma Langman
- Does the Browser Have a Future? by Tim Bray
- Forty Years of Teams by Tim Lister
- Life, The Universe, and Everything by Damian Conway
- The World after Cloud Computing & Big Data by Gunter Dueck
Big Data Architectures - Handling Too Big, Too Fast Or Too Versatile Data
- A Research Agenda and Vision for Big Data at NASA by Chris Mattmann
- How Elasticsearch Powers the Guardian's Newsroom by Graham Tackley, Shay Banon
Bleeding Edge HTML5 & JavaScript - Taking The Web Platform To The Next Level
- Mobile Web Performance - Getting & Staying Fast! by Aaron Peters, Andy Davies
- Offline First: Re-Imagining Web Development for the Real-World by Caolan McMahon
Building Integrated Applications With Web Technologies
- Enterprise Integration Using REST: A Case Study by Brandon Byars
- From Parts to a Whole: Modular Development of a Large-Scale e-Commerce Site by Stefan Tilkov
- Maneuverable Architecture by Michael T. Nygard
- Migrating to Microservices by Adrian Cockcroft
Design To Exceed The Limit - High Scalable Architectures
- High Performance Reactive Applications with Vert.x by Tim Fox
- Real-Time Systems at Twitter by Brian Degenhardt
Everything You Wanted to Know About CS (But Were Afraid to Ask)
From Financial Risk To Booking A Cab, Technology Stories From Startups
- How Netflix Leverages Multiple Regions to Increase Availability: An Active-Active Case Study by Ruslan Meshenberg
- Using Docker in Cloud Networks by Chris Swan
- You Don't Need a PaaS; the Epic Search for Truth by Russell Miles
- Garbage Collection is Good! by Eva Andreasson
- Lambdas & Streams: Taking the Hard Work Out of Bulk Operations in Java SE 8 by Simon Ritter
- Practicing at the Cutting Edge: Learning & Unlearning about Performance by Martin Thompson
People Over Process In The Real World
- Deliberate Advice from an Accidental Career by Dan North
- Organizational Change Myths - Introduction and Sustainability by Linda Rising
Privacy & Security - Rebuilding Trust
- How I Learned to Stop Worrying and Trust Crypto Again by Graham Steel
- Identity Is the New Currency by Paul Simmonds
- Understanding & Managing your Digital Footprint by Robin Wilton
Real Agile Delivery with DevOps
- Dev "Programming" Ops For DevOps Success by Damon Edwards
- Development, Deployment & Collaboration at Etsy by Daniel Schauenberg
- DevOps at a Small International Bank - Contiguous Improvement over Continuous Delivery by Ola Ellnestam
- The Process, Technology & Practice of Continuous Delivery by Dave Farley
Stayin' Alive - Tales of Resilience, Fault Tolerance & Recovery
- Building Resilience: How Outages Shaped Etsy's Systems by Avleen Vig
- Exploiting Loopholes in CAP by Michael T. Nygard
- Fault Tolerance 101 by Joe Armstrong
- From Instability to Resilience: The Story of a Web Site by Richard Campbell
- Is It A Car? Is It A Computer? No, It's a Raspberry Pi Java Carputer by Simon Ritter
- Project Avatar - Server-Side JavaScript on the Java Platform by David Delabassee
- Keys to Continuous Delivery Success by Mark Warren
- The DevOps Maturity Curve - Where Are You on It? by Chris Rowett
- A Big Data Arsenal for the 21st Century by Matt Asay
- Connecting Everything - APIs & PaaS by Paul Fremantle
Training
Advanced Functional Programming
by Erik Meijer
Twitter feedback on this training session included:
@dthume: Turing himself switched to the lambda calculus, but we're still suffering - @headinthebox at #qconlondon
@timreid: @headinthebox: 'There is no escape from side effects, all our efficient code depends on them' #qconlondon
@simontcousins: think like a fundamentalist, code like a hacker Erik Meijer #qconlondon
@dthume: Enterprise development is grunt work. Functional programming is art - @headinthebox at #qconlondon
Design & Implementation of Microservices
Twitter feedback on this training session included:
@matlockx: @boicy says 'technical acronyms make us think the wrong way' #qconlondon
@rrasmo: objects should be no bigger than my head @boicy at #qconlondon
@jejking: If you don't know your business' goals "go and find them out" #qconlondon
@timreid: architecture principles... https://t.co/XuiEsfYrVA #qconlondon @jimbarritt
@jejking: If you take the metaphor of town planning for architecture, the self-similarity of towns gives rise to interesting patterns. #qconlondon
@dthume: Beware of shared serialization protocols @boicy at #qconlondon - so true!
@jejking: @adrianco: you can be more relaxed about service contracts on internal services. Use avro over json, bind to client libraries #qconlondon
@michaeldfallen: What I'm hearing is "first we kill all the DBAs" #microservices #qconlondon
@jejking: @boicy: use correlation ids to trace use cases across distributed services #qconlondon
@jejking: @adrianco - systems need support for error injection to demonstrate resilience. Cause failure and check it is contained. #qconlondon
@matlockx: @adrianco #netflix runs nearly 600 distinct services in production #qconlondon
@jejking: @boicy: you can leverage Conway's law to influence the evolution of a software architecture #qconlondon
Embracing Change: Building Adaptable Software with Events
Twitter feedback on this training session included:
@matlockx: @russmiles organize, reduce and encapsulate #qconlondon #antifragile
@jejking: @russmiles "snowman architecture" or "integrating at level of services". In contrast to "pizza boxes". #qconlondon
@jejking: @russmiles "DRY is coupling, when done between areas in an architecture that evolve at different rates" #antifragilesoftware #qconlondon
@jejking: @russmiles use of ThreadLocal - "the wormhole pattern" #antifragilesoftware #qconlondon
@jejking: @russmiles How do you exchange expectations about document syntax and semantics without strict typing? #antifragilesoftware #qconlondon
@jejking: @russmiles - we tend to discover services via DNS and well known names #antifragilesoftware #qconlondon
Problem-solving and Decision-making in Software Development
by Linda Rising
Twitter feedback on this training session included:
@pablojimeno: Stories and hype, that's all we got in agile development @RisingLinda #qconlondon
Systems Thinking and Methods
Dusan Omercevic attended this keynote:
He got us thinking about the systems and the problems they may cause. In particular he made a good case that since systems are amorphous and impersonal, something people cannot really understand and relate to, we tend to imagine that systems have architects, that large consequences result from large actions, and that systems have goals. But the problem with teleological explanations is that they make us abdicate our powers to change anything. If our enemy is Big Pharma, Militant scientists, or Illuminati, we are relieved of our duty to make the world around us a better place. The enemy is just too big and ourselves too powerless to really do anything. But if we accept that systems are built and operated by fallible humans, we might just see them for what they really are, a bag full of good intentions running amok.
Twitter feedback on this training session included:
@tolivern: Hiring bad programmers is like drinking sea water #qconlondon
@tolivern: The wisdom of crowds doesn't work at all if you are using a crowd of experts #qconlondon
@tolivern: Systems thinkers are not a happy bunch of people #qconlondon
@aviranm: Every large system that works started with a small system that worked. #qconlondon
@jaumejornet: 'Whatever the system's designed purpose (if there was one), it quickly becomes about preserving the system itself' - #qconlondon
Keynotes
Back to the Future: What Old Thinkers Can Teach Us about Making Innovation Succeed Today
by Emma Langman
Dusan Omercevic attended this keynote:
The moment we start discussing influencing other people ethical issues start kicking in and in particular the issue of influence becoming manipulation. Emma Langman certainly hasn't shied away from this issues but addressed them head on stating that is the intention of the influencer what separates good-intended encouragement from ill-intended domination.
Myself, I would go further. Being in a management role and with agenda on my mind, I found myself frequently in position of temptation to make people do something against their will and behind their back. Whenever I fell prey to such temptation, I got badly beaten and the things I did came around striking me like a boomerang in the back. Even though I did things with best of intentions, people always hated it if they felt manipulated. And that despite the fact that they in most cases appreciated the outcome and results my actions brought about.
Does the Browser Have a Future?
by Tim Bray
Alex Blewitt attended this keynote:
The key point he made is that most client-side developers end up developing applications three times; once for the web, once for iOS and once for Android. For iOS and Android the development toolkits are well developed and built, but the web sites have had a lack of tools.
Part of the problem is that there are too many libraries and problems with JavaScript and the DOM model. However, the URLs and HTTP as a underlying transport model are right; so the future might be there but perhaps JavaScript needs to be removed from that equation. He showed some Go examples and advertised how server applications could be built in Go taking advantage of concurrency.
Dusan Omercevic attended this session:
According to Tim Bray it might very well happen that the age of a web browser will be superseded with the age of augmented reality! And to prove his point he shown one of the 200 prototype dev kits that Google has built within the scope of Project Tango. And after his talk, I got a chance to hold the device in my own hands!
Twitter feedback on this keynote included:
@timanderson: Client software has to be written three times today says Tim Bray, diminishing productivity (iOS,Android,Browser) #qconlondon
@alblue: 2014 will be the year that access from mobile devices outnumber those from desktop clients @timbray at #qconlondon
@alblue: How many years have they been flogging the JavaFX dead horse? @timbray at #qconlondon
@dthume: It's a bloody full time job just to stay on top of what people _think_ you should be using for web development - @timbray at #qconlondon
@timanderson: Browser dev is building on sand says Tim Bray #qconlondon - DOM, CSS etc too broken
@DajanaGuenther: A day I have to program in Javascript is not a day that makes me happy. - @timbray at #qconlondon #keynote
@tastapod: The future is RESTful, the web has won, the problem is in the browser. @timbray at #qconlondon
@dthume: Not many professionals have a chance to go out there and change the world. We do" @timbray at #qconlondon
Forty Years of Teams
by Tim Lister
Alex Blewitt attended this keynote:
Tim's main observation was that most problems with projects are not a result of any single or sudden change, but of problems with people. He used the phrase "Dead Fish" to identify projects which were clearly identifiable as failures for years before the ultimate fail point, but despite being common knowledge the project is kept alive. Economic interests, power plays and a need to meet budgetary quota are some examples of where clearly failing projects are kept alive to achieve side-effects other than the project's success.
He mentioned the benefits of working in a great team - "it's great to know your colleagues have your back" was the phrase he used. Working for and with people smarter than you can result in successful delivery and learning; on the other hand, "if you don't have the trust of the team or you aren't excited to go to work then you should use your feet."
Finally he inspired many by talking about software and being one of the biggest changes in the last 50 years, and how conferences such as QCon are about moving an idea from one thick skull to another. He also suggested that writing is a great way to distill ideas and opinions (which reminds me, I need to blog more ...)
Twitter feedback on this keynote included:
@czapinho: Do you play well with others? #qconlondon #anothergreatman http://t.co/W6D3rd5AEj
@synodinos: Nobody can do anything substantial by himself, and it's not nearly as fun Tim Lister #qconlondon
@dthume: If you don't get innate pleasure from writing code, it's time to move on - Tim Lister at #qconlondon
@gjtaylor: Software making is deeply intellectual work - it's not just solving puzzles #qconlondon
@trisha_gee: "It's deeply exciting to work with someone who's waaaay better than you" #qconlondon
@andyhedges: Putting together a team is the most important thing a manager ever does - Tim Lister #qconlondon
@andyhedges: The team owns the project - Tim Lister #qconlondon
@gjtaylor: Code so beautiful it was proof that aliens have visited our planet...The Vermeer of 'C' - great descriptions from Tim Lister #qconlondon
@sf105: "This is your software family tree" @timlister #qconlondon
@yareeh: Having 'Best Practices' underestimates underlying complexities of things. Tim Lister #qconlondon
@grantjforrester: Forget "Best Practice". Anti-intellectual. Thought has been removed. Prefer "Pretty Good Practice" #qconlondon
@IsraKaos: don't waste your time in bad places, leave and make your own career Tim Lister #qconlondon
@IAT_Technology: Seriously epic and inspirational keynote by Tim Lister at #qconlondon "Life is short. Make your career" "Take the ride, bring your friends"
@yareeh: Really predictable companies do really boring software. They do the same thing over and over again. Tim Lister #qconlondon
@shanehastie: @qconlondon Tim Lister: You've got to surf the technology wave, or you'll drown
@roxanneinfoq: Agile methodologies are really about risk management, Tim Lister @qconlondon.
@shanehastie: @qconlondon Tim Lister: A crucial question for risk management: "do you know what's under the grass?"
@shanehastie: #qconlondon Tim Lister: Risk Management is about when you make decisions, if I wait for more information when do I lose options?
@sf105: "Risk management is not problem management". @timlister #qconlondon
@yareeh: When risk management becomes problem management time is managing your project. Not you. You are just reacting. Tim Lister #qconlondon
@shanehastie: #qconlondon Tim Lister: You can't run away from risk. Avoiding a risk usually devalues the product.
Life, The Universe, and Everything
Alex Blewitt attended this keynote:
He showed a Perl program for evaluating a set of starting rules and the evolution, and used that to explain a 'glider' and a 'glider gun' which are used to create repeating patterns.
He then talked about Turing machines and what they have been implemented in, including lego,meccano, and even the game of life.
Briefly he digressed into using Klingon as a programming language, saying that the word formation of Klingon is Indirect object, Object, Verb (IOV) which is the same as Reverse Polish Notation (RPN). As a result, he proposed a language using numbers and keywords derived from Klingon in order to run a program written in that language, in the same way he suggested writing a programming language in Latin from last year.
Twitter feedback on this keynote included:
@andyp1per: Damian Conway implements a Turing machine in game of life @qconlondon #awesome, then programs in #klingon !
@secboffin: Klingon and PostScript are grammatically interchangeable, says Damian Conway #qconlondon
@DajanaGuenther: TIL: Klingon is actually a functional language. #qconlondon
@rusmeshenberg: Flow control in Klingon - #qconlondon
@markgibaud: Game of Life in Lego, programming in KlingonScript and breaking laws of the universe: Damian Conway entertaining as always. #qconlondon
@danielespeset: @qconlondon off to an good start, keynote by Damian Conway disproved Maxwell's demon with a game of life written in functional Klingon.
The World after Cloud Computing & Big Data
by Gunter Dueck
Twitter feedback on this keynote included:
@DajanaGuenther: Why should I look for cheese when there's bacon? Get out of your comfort zone #qconlondon @wilddueck @... http://t.co/vjhwUdGaMn
@secboffin: Self-driving vehicles are the cloud computing of cars. @wilddueck at #qconlondon
@garichmond: #qconlondon Solar powered 3D printers using sand to make products in developing countries, interesting concept
@yareeh: If I was youg I would have a startup Robotbook, social media for robots. @wilddueck #qconlondon
@andyhedges: . @wilddueck at #qconlondon explain that if you aren't creating then your job can be automated/low paid, there is no expert between now
@DajanaGuenther: Computer scientists are more like cats. Think about that. - @wilddueck at #QConLondon
@eoinwoodz: Managers are dogs, engineers are cats! #qconlondon @wilddueck
@taidevcouk: A note for us techies from the @wilddueck #qconlondon keynote today "Make it simple" does not mean dumb it down. Think Apple UX :-)
Big Data Architectures - Handling Too Big, Too Fast Or Too Versatile Data
A Research Agenda and Vision for Big Data at NASA
Mike Salsbury attended this session:
NASA at JPL has been spending time researching how to handle big data. They are closely involved with Apache projects like Tika and Apache OODT.
These projects should help them to catalogue all NASA's planetary science data, triage incoming big data sets, and apply scientific algorithms to disparate big data sets in diverse formats.
All of which should help to absorb the 700 Tb/sec of data that is expected to be received from the Square Kilometer Array once it comes on line.
How Elasticsearch Powers the Guardian's Newsroom
Alex Blewitt attended this session:
To track user interaction with the website, an initial 24h 'hackday' project which grepped the Apache logs to show the top content in the prior few minutes was launched. The success fo that project led to the creation of an Elasticsearch backed infrastructure for performing the same thing over the period of the last few minutes to the last few hours, days, or weeks.
The Guardian website uses a form of invisible pixel tracking; when a page is loaded and rendered via the browser, an image is requested from the remote server. This causes an event to be posted to Amazon SNS to post a message into Amazon SQS which then loads it into an Elasticsearch database. By storing the time, referrer, and other geolocation data it is possible to build up a data set which richly describes who is using the site at any one time.
By using Elastic search to search the content for specific filters (e.g. all sport references in the last five minutes, or all references from the front page) it is possible to build real-time statistics of who is using the software and at what time. By capturing the geolocation data it is possible to get a heatmap of where readers are located in the world, and by using a set of graphs (displayed by D3 in the dashboard) be able to give a drill-down view of the data and to permit editorial decisions to be made about what content to promote or to follow up on.
Elastic search provides most of these search functions out-of-the-box, including the date histogram which can partition requests into different time-based buckets. The graphs can be used to correlate the information seen, including being able to find out what particular tweet caused an upsurge in information, or when a reddit page went viral to drive content.
Bleeding Edge HTML5 & JavaScript - Taking The Web Platform To The Next Level Track
Mobile Web Performance - Getting & Staying Fast!
Richard attended this session:
Phone radios also have a 1-2 second delay when waking up and negotiating a data connection with the base station and round trip times to the server are a lot longer on mobiles so latency can kill load times.
Web pages are also getting 30% larger year on year and whilst networks are getting higher bandwidth, 4G will only hit 20% of users by 2015. The new breed of cheap smartphones like the Alcatel Onetouch on Firefox OS means that not all users are getting the luxury of more processing power....
First lesson is to actually measure your page performance....
We went through some examples of bad sites. HTC.com loaded in 20 seconds on an HTC phone. NBC.com loaded resources from 115 domains over 30 seconds. There are some truly awful sites designed for mobile out there.
Fixing this
Standard web tactics like minimising the download, GZipping everything and aggressive caching apply here but it goes deeper. Web Fonts are really bad for mobiles, Google fonts download 4 separate files from the Google domain and your users have to wait for this to start using your site. If you have to use them, you can request a subset of a font vastly reducing the download. Tuning initcwnd = 10 on the server to send a larger number of initial TCP packets can have great effect. Meta tags to resolve DNS lookups ahead of time and prefetching images can be added to the header of your page to do stuff when the browser is idle.
Also prioritise more important resources over others. Content should come first so that text and useful images get on screen first. Enhancements can come next, such as that JavaScript that adds swipe functionality. Then the leftovers like ads should come last. That way the page is useful before it completes loading.
Finally, when you can't do anymore - add little tricks to make the user think that things are happening. Facebook proved that putting up a device-specific spinner makes users think that their phone is being slow rather than your page. You can also make actions appear instantaneous by updating the UI straight away then sending the message to the server. Only reverting if the action failed. Another trick is to start an upload whilst users fill out forms to go with the data.
Tim Sawyer attended this session:
BBC now has more traffic from mobile than from desktop. The internet is in our own image - obese, and pages are getting bigger. Out of 77 million mobile phone connections, only 2-3 million are 4G.
SVG is good. Icon font good. Can reduce size of webfont by removing glyphs. CSS Gradient Good. Do less requests, and less redirects.
160k of extra JavaScript at Etsy meant 12% bounce rate increase on mobile
Facebook experiment - Facebook branded spinner, users blamed facebook for slowness. Native looking spinner, people blamed the phone.
Offline First: Re-Imagining Web Development for the Real-World
Richard attended this session:
Offline first aims to make you design your app to make it as opaque as possible when your mobile app goes off the grid.
Caching
App Cache has long been touted as a way of storing pages for offline, but it has it's flaws. Mainly the fact that you have to update it every time a resource changes. A new ServiceWorker spec is in the pipeline to allow app developers to programmatically define where to load pages from. It seems cool, but very JavaScript heavy when all I want to do is load resources.
Connectivity
The offline API is pretty useless across devices and the only real way of detecting if your app is offline is whether your XHRs are reaching your servers.
Storing data
Local storage is also the default choice here, but there are limitations. It's synchronous so blocks user interactions and there's no way for you to tell if you are going to go over the nominal 5MB limit. IndexDB is more heavyweight, but has an awful API so there are a lot of wrappers on top of it.
- We also went through some great design maxims:
- Launching should feel natural. This has got to be done from the home screen of a phone rather than going to a browser
You shouldn't make your users plan ahead by having them click "sync" - Spinners are evil. If you are offline don't put one up. What is going to happen?
Dusan Omercevic attended this session:
As explained by Caolan McMahon, one of the authors of Hood.ie at his QCon talk, to go offline first is a great complement to mobile first approach. Not only it solves the issues with non-ubiquitous connectivity (that seem far from being a solved problem even in the developed world), but it provides for much better user experience on mobile devices by reducing lag in access to information and improving responsiveness of applications.
Building Integrated Applications With Web Technologies Track
Enterprise Integration Using REST: A Case Study
zeresht attended this session:
Brandon started out with a couple of comments and principles, starting first with the assertion that "most REST mistakes happen with: versioning, deployment, testing and service granularity"...
He then moved on to make an interesting observation:
You should value choreography over orchestration
... Next up were some key lessons to apply when implementing a RESTful SOA:
- Define logical environments for isolation - one for each need. Developers should work in isolation from one another unless it makes sense to share, or where the cost/complexity of the isolation doesn't actually give real benefit. ...
- Use versioning only as a last resort. ... When you do have to version, making use of semantic versioning to raise awareness of compatibility issues is helpful. ...
- Separate functional testing from integration testing and make full use of stubs, including over-the-wire stubs and stub-servers. Some modern stub-servers can record real data and replay these....
- Treating service end-points as user-stories forces you to test appropriately, and consider service granularity at the right level. Test Driven Design (as opposed to Development) forces you to have multiple consumers (since your test client is a consumer) which really forces better decoupling of the services in the system as a whole. ...
- Use bounded context to control complexity ...
Twitter feedback on this session included:
@NordinHaouari: The thing about orchestration is that it dramatically simplifies the architecture diagram, not the architecture - Brandon Byars #qconlondon
@ddanciu: consumer based service testing - the sum of all tests makes the contract @BrandonByars #qconlondon
@NordinHaouari: Avoid a single big domain. Propagate events from 1 domain and contextualize them in depending domains. #boundedcontexts #qconlondon #REST
From Parts to a Whole: Modular Development of a Large-Scale e-Commerce Site
Twitter feedback on this session included:
@dthume: The perfect interface between two systems is none - @stilkov at #qconlondon
Maneuverable Architecture
Alex Blewitt attended this session:
Michael Nygard talked about maneuverable architecture, and started by talking about maneuverability based on the investigation of John Boyd who looked at aircraft performance and how quickly they could respond in dogfights by converting kinetic energy to potential energy and vice-versa.
In addition, he proposed an Observe, Orient, Decide, Act loop (also known as OODA) which is the process of deciding what to do; specifically, by speeding this up or reducing the time taken to perform the actions can result in being able to react faster.
The same thing can happen in a business context, by being able to reduce the design/implement/test/release cycle. By being more agile (or maneuverable) it is possible to reduce time to market and thus costs.
One of his observations was that immutable data is easier to share and scale than mutable data.
Tim Sawyer attended this session:
Have scripts at a known URL. Each version of the script creates a new URL for that script. [You could HTTP 301 from a generic URL to the latest version]
Using hashes for perpetual strings, shopping carts. Break monoliths. Use URIs with abandon
Interesting ideas here for architecting generic components rather than just building to the requirements. For example build a service that does "At date time call this URL" rather than building specific scheduler code.
If you have a bare ID (customer serial) it has no context, it's just a number. If you have a URI, it has context - you know it's a customer.
Twitter feedback on this session included:
@jejking: Agile dev works well at micro level. Organisation level architecture needs manouverability says @mtnygard #qconlondon
@jejking: @mtnygard: Incremental compromises can lead to failure #qconlondon
@thought_forge: #MichaelNygard #QConLondon The typical IT architecture destroys tempo.
@dthume: Reducing from 3 platforms to 1 platform, in any arena, makes that one platform harder to evolve - @mtnygard at #qconlondon - So, so true
@thought_forge: #MichaelNygard #QConLondon "Independence of action between different groups is a key way to achieve manoeuvrability"
@tormodvar: Maneuverable Architecture. Yes the ESB does not enable maneuverability. @mtnygard #qconlondon http://t.co/aVcPpLTtnU
@tormodvar: Maneuverable Architecture. Yes all business descision are immutable. @mtnygard #qconlondon http://t.co/ty8xu4fuk7
Migrating to Microservices
zeresht attended this session:
So what are micro-services? Well obviously they are services that are "small", but interestingly it's the functional size that is limited, not the technical size (LOC, memory, whatever).
Adrian suggested one "verb" per single-function micro-service as a way of thinking about it, for example "put_document" might be a micro-service or"get_contacts". This single-verb mentality enforces a good separation of concerns. One developer independently produces a given micro-service, which is its own build, largely avoiding trunk conflicts. Related micro-services can be grouped, and developed by a team of developers....
Avoid (or abstract away) multithreading to keep the model simple, and use non-blocking calls to ensure scalability of the micro-service.
ESB/Messaging: Message buses are CP (consistency guaranteed) with big problems getting to AP (availability guaranteed), and should be used only for "send and forget" over high-latency links. See Brewer's Theorem for background.+
Service discovery: use Zookeeper or Eureka
Alex Blewitt attended this session:
His key enabler is that speed wins in the marketplace; by skating to where the marketplace will be you can out-innovate the competition.
To do this, reducing friction from product development is the key. Automating everything and trusting developers allows them to innovate without needing meetings, approvals, sign-offs, cross-checks, or anything else which gets in the way of the desired result - providing functionality to serve the business.
Importantly, by focusing on what you are good at (and what's core to your business) you can let go of things that you aren't; including using open-source tools instead of trying to fork/wrap your own APIs, and making the non-secret sauce parts of your environment as open-source applications. Doing so increases your reputation of the company - your company's repositories on GitHub is its on-line resume;. By licensing permissively (Apache, MIT, BSD etc.) you trade-off control for ubiquity.
Twitter feedback on this session included:
@matlockx: @adrianco: speed wins in the marketplace #qconlondon
@yareeh: Don't do your own *undifferentiated* heavy lifting. @adrianco #qconlondon
@alblue: Talking about things externally is a much better way if influencing what happens internally - @adrianco at #qconlondon
@SteveGodwin: You need a high trust, low process environment. @adrianco on micro services at #qconlondo
@dthume: We were about to copy 18TB from one region to another, then we thought perhaps we should call amazon and let them know @adrianco #qconlondon
@gjtaylor: 200Tb of disk across 6 locations in 2 regions available in 20 minutes. The beauty of having an effective framework. @adrianco at #qconlondon
@andypiper: Interesting. @adrianco says you should own your own client libraries to ensure your API is a high quality experience #qconlondon
@alblue: Migrating from Tomcat to Netty can give speed ups because of non-blocking IO. #qconlondon
@gjtaylor: Love the fact that Netflix security team are automatically scheduling penetration tests on new code as it goes to production #qconlondon
@ddanciu: Micro in micro services is not about the size of the service but about the functionally @adrianco #qconlondon
@alblue: Algebird is used to represent the statistics in twitter https://t.co/GNcZXG2sOu #qconlondon
@alanmcurtis: Twitter uses open source distributed tracing system "zipkin" based on Google's dapper paper. Stats used to track resp. times #qconlondon.
@a32an: If it's commodity, it's not a differentiator, so don't invest in it. @adrianco at #qconlondon
@yareeh: Build everything out of Apache licensed stuff and leave out all other code. @adrianco #qconlondon
Design To Exceed The Limit - High Scalable Architectures Track
High Performance Reactive Applications with Vert.x
by Tim Fox
Alex Blewitt attended this session:
Tim Fox gave an overview of Vert.X, describing it as a lightweight, reactive application superficially similar to Node.JS and inspired from Erlang. However, unlike Node.JS and Erlang, Vert.X is a polyglot language with implementations and libraries in many different languages and a common communication bus for passing messages between them.
At its core lies an enterprise bus that communicates with JSON messages and which subscribes many individual single-threaded processes called verticles. These can be written in any language supported by Vert.X; messages are passed between them as immutable data structures and so can be materialised into any supported format. In this sense, it is similar to the Actor model, except without any shared state.
Running a vert.x program can be achieved with vertx run followed by a class or function that implements the verticle. For interpreted languages such as Groovy or JavaScript the VM starts and begins executing the code directly; for compiled languages like Java and Scala a compilation process is kicked off to compile the code ahead of time. In development, these can be reloaded dynamically to facilitate development and debugging.
The event bus can be distributed between different JVMs, enabled by running with the -cluster flag. ...
Modules are also possible in Vert.X, using a mod.json descriptor file and zero or more resources or verticles. These can be run with vertx runmod and will start up any entry points discovered. ...
As well as clustered mechanisms it is possible to run vertx in a high availability mode, with -ha. This implies -cluster and allows multiple JVMs to take the load of individual vertx modules.
Twitter feedback on this session included:
@alblue: The modern 'real time' definition isn't hard or soft real-time, it's about pushing stuff to browsers - @timfox at #qconlondon
@alblue: Nice, vert.x can download and run modules from a Maven repository:vertx runmod io.vertx~hello-mod~1.0 http://t.co/6n5OjzRcI9... #qconlondon
@rolios: Wow the auto-redeploy on module failure is incredibly cool! #vertx #qconlondon
@alblue: It takes a bit longer to start up because that's Gradle - @timfox at #qconlondon (though he dislikes Maven as well)
Real-Time Systems at Twitter
Alex Blewitt attended this session:
Brian Degenhardt talked about some of the challenges when scaling Twitter. Initially developed as a monolithic application, by separating the system down into separate services meant that the components could be scaled independently from each other, both at the network layer but also the development layer. A MySQL database was used to hold everything with a rails app fronting the code.
The second generation twitter split up the monolith into different back-end data storage layers, using gizzard as a sharding mechanism for MySQL databases and a Redis instance for storing timeline information. Subsequent iterations replaced the front-end components with services as well, which allowed more heavily used services (such as the timeline and user tweet details) to be scaled horizontally when needed.
Fortunately when a request comes in to Twitter the request is composable into different services, and by using non-blocking futures it is possible to scale these by compositing the results of a series of lookups into one chain. By executing many requests in parallel but having that hidden by the underlying futures framework means that the code is easy to understand whilst still taking advantage of multiple threads.
When a write to Twitter happens, it gets split into a lookup of all the subscribers and then writes a copy of each into all the timelines. This involves a fan-out (lookup of affected destinations) and then a sharded write across the database. For providers that are subscribed to the firehose, the feed goes to them as well - around 30Mb/s in total. In the case of the Lady Gaga tweet replying to the Mars rover, this resulted in a set conjunction of around 1.5 million and 40 million followers, which took some time in the fan-out processing. ...
Twitter uses a distributed tracing system called Zipkin (demo) which performs tracing throughout the lifetime of a request, based on Google's Dapper paper which was written about but never open-sourced. As a result, Twitter re-implemented it based on the content of the paper and open-sourced it instead.
The underlying service calls use HTTP for external communication, and once inside the boundary use Thrift for passing RPC messages and using a standardised library that provides load balancing, service discovery and metrics generation and logging. These metrics are collected centrally and can be visualised using histograms or by using a view of the data points with percentiles that show when the system is suffering under a higher load.
Twitter feedback on this session included:
@ddanciu: Engineering is splitting into manageable pieces @bmdhacks #qconlondon
@alblue: It turns out that building a giant monolithic application isn't scalable - @bmdhacks at #qconlondon
@alblue: Twitter using multiple independent services for scalability and flexibility #qconlondon http://t.co/bU845xhdcu
@matlockx: The monolith challenges at twitter have been: #qconlondon http://t.co/uEO7AZBKyz
@adrianco: Twitter microservices map looks just like the Netflix one. We called this the "Death Star" diagram. #qconlondon http://t.co/aYQZ6eTztr
@alblue: This tweet caused the intersection of 3 million followers and 40 million followers #qconlondon https://t.co/VH9QolKgMr
@thought_forge: #Twitter took a scalpel to a monolithic code base, to create a service based architecture #SOA #QConLondon
@a32an: 300k requests per second is pretty normal @bmdhacks at #qconlondon
@pixelastic: One server = One function that accept a request and returns a (future) response. Makes them composable. Twitter @ #QConLondon
Everything You Wanted to Know About CS (But Were Afraid to Ask) Track
Impossible Programs
by Tom Stuart
Twitter feedback on this session included:
@timanderson: In the general case, you cannot tell whether a piece of software conforms to its specification explains @tomstuart #qconlondon a shame!
@robilco: Acceptance testing cultivates plausible deniability @tomstuart at #qconlondon ... Brilliant
Understanding & Using Regular Expressions
Tim Sawyer attended this session:
Regular expressions are subroutines, and they are explained here by graph traversal.
Always use ?x at the start of a regex, where supported. This allows you to format your regex with whitespace and comment it. If this is unavailable on your platform, build it - regex is a string with spaces, code processes this down to just the regex.
.* is greedy. .*? is non greedy
Twitter feedback on this session included:
@dthume: Whitespace arguably the most important part of any piece of code, but is a command in regexes - Damian Conway at #qconlondon
@pablojimeno: Stop thinking about regex as what you want and start thinking about them as commands to do Damian Conway #qconlondon
@mjpt777: Brilliant! - "Whitespace is the most important part of any code" - Damian Conway #qconlondon
From Financial Risk To Booking A Cab, Technology Stories From Startups Track
Lean Under Pressure
by Glen Ford
Tim Sawyer attended this session:
Lego themed slides - excellent! Chief Architect of ZeeBox. Talked about leadership vs management.
You build it you run it. No handoff to ops. Garden architecture. Chaordic system - can't always be predictable.
Suggested lunchtime tech talks, and guilds for grouping together people interested in a specific technology.
Making The Internet Of Things
Twitter feedback on this session included:
@andypiper: Here is the landscape for #IoT - there isn't one single solution #qconlondon @knolleary http://t.co/OzuVhPuUyG
@andypiper: We often spend more time on the plumbing than on the solution and idea itself - @knolleary says @nodered aims to reduce that #qconlondon
Next Gen Cloud Track
How Netflix Leverages Multiple Regions to Increase Availability: An Active-Active Case Study
Alex Blewitt attended this session:
He showed a pyramid of failures, with top incidents being those that caused negative PR (mitigated by active/active pairs and game day practicing), customer service incidents (mitigated by better tools and practices), metrics impact (mitigated by data tagging and feature enable/disabling), and automated failover/recovery processes.
The key should be about how to respond to failure; with enough systems, eventually at least one will have a hardware-related failure with a disk or CPU dying, or natural events such as a lightening strike taking out power to a data center. It's possible that human error will be involved (configuration, bad code push etc.) but the key is to be able to recover quickly and painlessly from any events that may occur.
Twitter feedback on this session included:
@alblue: The chaos gorilla can take out a whole zone at Netflix #qconlondon http://t.co/Ba7SaRlTyW
@alblue: And its bigger brother, chaos kong for taking out an entire region #qconlondon http://t.co/dxjeR3DS06
@andypiper: "Everything fails... eventually - when you're operating at web scale, you want availability" #qconlondon #cloud
@alblue: Netflix zuul is open source routing and filtering front-end for HTTP requests https://t.co/8He4tM3Ufe #qconlondon
@andypiper: The interesting part about Netflix technical talks is realising how much goes on behind the scenes, that users simply never see #qconlondon
@alblue: Netflix global consistency optimised for availability #qconlondon http://t.co/7dgmdmr8g1
@andypiper: New @NetflixOSS project (soon) announced at #qconlondon - Dynomite http://t.co/ffTNDIjupd
@adrianco: New Netflix project announced by @rusmeshenberg at #qconlondon Dinomite - memcached replication using Dynamo/Cassandra like protocols
@andypiper: With great power comes... great possibility of shooting yourself in the foot... #qconlondon #Netflix
@alblue: Hystrix is the circuit breaker that allows degraded services to be disconnected w/o downing the system https://t.co/Q4dnxo2lYI #qconlondon
@ddanciu: when you have a leaky boat, you don't start making a new boat right away, first plug the hole @rusmeshenberg #qconlondon
@kaimarkaru: A question to #netflix engineering team - how do you do capacity planning? Answer - we don't. #qconlondon
Using Docker in Cloud Networks by Chris Swan
Alex Blewitt attended this session:
Chris Swan talked about Docker as a container mechanism for software. Outside the box lies linux containers (using LXC) and some kind of union filesystem such as AUFS or a snapshot system such as ZFS or BTRFS.
By specifying a dockerfile, with a set of build instructions (with the RUN command) and an execution (with the CMD command) it is possible to automate the booting of a container inside an existing machine. Since many of the host OS libraries and functions are used it is possible to spin up many containers for invocations. ...
Docker is restricted to running on Linux, but in the most recent release a version has been made available for running on OSX using Virtual Box to host a Tiny Core Linux image.
You Don't Need a PaaS; the Epic Search for Truth
Twitter feedback on this session included:
@dthume: Logging has done a wonderful job in causing #bigdata to happen - @russmiles at #qconlondon
@andypiper: One of the most concerning parts of microservices is... that we could be building SOA again... says @russmiles with *eyeroll* #qconlondon
@julienvey: Agile is bad. "Adaptable" or "Able to change" is more adequate, says @russmiles. Totally agreed #qconlondon
@andypiper: Mmm @russmiles asks "who is using a PaaS today?" - I raise my hand... Nobody else? No? #qconlondon
@adrianco: #qconlondon @russmiles "I wrote a book on UML, I'm sorry. The preface says only use it for sketching..." < not me, Russ!
@adrianco: #qconlondon @russmiles "The elephant in the standup may be moving..." http://t.co/W3TDq24vlG
@adrianco: #qconlondon @russmiles on PaaS "As old as I am, a leaky abstraction would be awful..."
@dthume: I can draw triangles, squares and circles; that's all you need to be a consultant - @russmiles at #qconlondon
@juristr: #qconlondon #antifragilesoftware PaaS is like a framework. It creates coupling. You need to understand that http://t.co/9cv71bWmo1
@dthume: FaaS - Failure as a Service - #antifragile software design with @russmiles at #qconlondon
@jejking: I don't want another monolith in the shape of a PaaS, @russmiles rounding off #qconlondon
@russmiles: No PaaS was harmed in the making of this talk #qconlondon
Not Only Java Track
Garbage Collection is Good!
Trisha Gee commented on this session:
Eva took us through the fundamentals of Garbage Collection - this might not seem like a cutting edge subject these days, but it's one of the most misunderstood subjects for Java programmers. Eva gave us a really great, understandable view of the different types of garbage collectors, how they work, and their pros and cons. She left us with a call to arms to not simply let other people try and solve this problem, but to get stuck in and contribute ourselves, via the OpenJDK.
Twitter feedback on this session included:
@gjtaylor: Garbage [collection] is good because it helped programming become "mainstream" #qconlondon
@yareeh: Bad in garbage collection: The Desert of Tuning. Endless tuning and re-tuning. @EvaAndreasson #qconlondon
@mtaulty: @evaandreasson talking about having to tune/config the JVM GC as/when a workload changes #qconlondon - "JVM hell of too many options".
@trisha_gee: We gave JVM developers all these options and left you alone. I'm sorry. @EvaAndreasson on tuning GC at #qconlondon
@yareeh: There is no way you can put enough heap to current JVMs because of fragmentation and stop the world compaction. @EvaAndreasson #qconlondon
@gjtaylor: We need more innovation around compaction - @EvaAndreasson #qconlondon
Lambdas & Streams: Taking the Hard Work Out of Bulk Operations in Java SE 8
by Simon Ritter
Andrew Jones attended this session:
A run-through on the new Lambdas and Streams features coming up in Java SE 8. Looks like a good implementation that I look forward to using.
A side effect of implementing Lambdas is that Java now has something that looks a lot like Roles in other languages. Will be interesting to see how this feature gets used by Java developers, and if it will cause more problems that it solves.
Alex Blewitt attended this session:
For those that aren't familiar, the Lambda expressions will be able to provide a similar change as inner classes, allowing in-line functions to be assigned to a Single Abstract Method (SAM) type. These will actually be functional types rather than instances of classes, so they don't have this.
Runnable stuff = () -&> System.out.println("Hello Lambda");
He also covered the new streaming API which allows a sequence of collection elements to be processed in a stream, much like an iterator allows elements to be processed. However, by moving this into a stream it's possible to perform stream combinations such as map, filter and flatMap to construct different streams on the fly. Importantly, these streams are lazy and so aren't evaluated until the end of the process (the terminal condition) such as sum(), collect() etc.
Practicing at the Cutting Edge: Learning & Unlearning about Performance
Trisha Gee commented on this session:
Martin kicked it off with a great history lesson on the progress (or occasionally, lack of it) in Java. He begged us to study and understand Set Theory, to use async design, to think of the users of our APIs, and, most of all, to design nice, clean code.
Twitter feedback on this session included:
@charleshumble: Escape analysis promised so much and delivered so little @mjpt777 #qconlondon
@trisha_gee: 95% of performance is good, clean, nice design @mjpt777 at #qconlondon
@timreid: Design to be composable makes a massive difference to performance @mjpt777 #qconlondon
@sf105: "All storage is tape (including memory)" @mjpt777 #qconlondon
@matlockx: @mjpt777 networks are faster than storage. Start thinking of replication in a different way! #qconlondon
@trisha_gee: Better people will often tell you they don't know that much @mjpt777 at #qconlondon
People Over Process In The Real World Track
Deliberate Advice from an Accidental Career
by Dan North
Twitter feedback on this session included:
@portiatung: 99% of coaching is empathy... Meeting people where they are instead of where you are @tastapod #qconlondon
@shanehastie: #qconlondon @tastapod "Let me figure it out" - learn programming hygiene- your code must tell anyone who reads it what's going on inside
@shanehastie: #qconlondon @tastapod Beutiful, quality, unreleased software is worthless. Released bad code is also bad.
@shanehastie: #qconlondon @tastapod: Great senior exec says "you'll have to teach me"
@ndetoffoli: @tastapod @ #qconlondon: "focus on what matters"
@shanehastie: #qconlondon @tastapod Hiring great people is one of the most important skills and activities in any business."Don't hire yourself"
@shanehastie: #qconlondon @tastapod "How soon do you want feedback" - crucial question in coaching teams - meet people where they are
@shanehastie: #qconlondon @tastapod the way to have a good idea is to have lots of ideas
@shanehastie: #qconlondon @tastapod practical trumps inspirational, every time!
Organizational Change Myths - Introduction and Sustainability
by Linda Rising
Tim Sawyer attended this session:
Great presentation listing four myths of organisational change:
Myth #1: Smart People are Rational. Be an evangelist not a fanatic. I don't know, I believe it will work. Cold learning cycle.
Myth #2: Good always triumphs over evil. Fight for it. Feed them.
Myth #3: If I just had power I could make people change. Compliance not change. "What's in it for me?"
Myth #4: You should sack people who won't listen. Use resistance to your advantage. Champion skeptic -> devils advocate.
Myth #5: You're smart, you don't need help from others. Just say thanks.
James attended this session:
Linda says:
- If you want to persuade people to change you need to believe in your proposed change
- Persuade people by feeding them - literally. But the food has to be the right food!
- Listen to people's fears and learn all you can. Conversations are not fencing matches.
- Appoint a "champion skeptic" to play devils advocate
- Ask for help, and don't forget to say thanks!
Twitter feedback on this session included:
@rusmeshenberg: If you want to convince people - feed them! @RisingLinda at #qconlondon http://t.co/fpsClOSbM5
@rusmeshenberg: Just listen. Really listen. @RisingLinda at #qconlondon http://t.co/sG7cpjzAlo
@jimshep: Remember, people of #qconlondon (and indeed the world):"Just Say Thanks" - @RisingLinda http://t.co/48mUday6yw
Privacy & Security - Rebuilding Trust Track
How I Learned to Stop Worrying and Trust Crypto Again
by Graham Steel
Will Hamill attended this session:
Graham started his talk addressing this: "The tinfoil hat brigade were right" but follows up with a quote from Snowden - "Encryption works. Properly implemented strong crypto systems are one of the few things that you can rely on." Obviously the key parts here are the definitions of "properly implemented" and "strong". ...
The next part of the talk covered how to judge crypto implementations - what makes a good crypto API? Graham suggested a number of points: to be wary of proprietary implementations that can't be subject to review by the community; support of modern crypto primitives; support for flexible and secure key management; mistake resistance; interoperability. ...
Graham touched on a number of crypto systems in his assessments, providing breakdowns of each one against his criteria for judgement described above. I'll attempt to give a micro-summary of his thoughts on each one here.
PKCS#11: Standard loose, implementations different. Relies on old SHA-1 hash. Good interop. Not very mistake resistant. Pre-2013 not clear though new versions more modern but contain lots of legacy stuff.
Java JCA/JCE: Standard crypto interface used across many enterprise Java apps. Hardware support limited. API under Oracle control but providers often open (e.g. Bouncycastle). Not very mistake resistant. Support for modern and a lot of legacy stuff, good interop.
OpenSSL: Originally just used for TLS and SSL, not used for lots of crypto. Source available but decision making process murky. Contains legacy crypto as well as modern extensions. Minimal key management. Easy to get wrong. Interop ok.
MS CAPI/CNG: CNG slowly replacing CAPI on MS platforms. Proprietary software and most providers closed. CAPI a lot of legacy code. No key management. Plenty of things to get wrong. Not very interoperable.
W3C Crypto API: New crypto API for HTML5 apps. Contains mostly modern crypto but despite fresh start also legacy crypto. Some key management though currently WIP. Some efforts to make easier to use (SubtleCrypto vs WorkerCrypto, IV management).
Others mentioned: A quick look at NaCl and Cryptlib ...
He mentioned avoiding using legacy modes or weaker algorithms as the default settings for some crypto tools, e.g. ECB mode being used by developers because it has the least params and doesn't ask for an IV to be set up. Graham warned against using improperly initialised random number generators and reuse of stored random values. Graham also warned against blindly letting the app or API handle IV management and also warned about unauthenticated encryption (e.g. forgetting to validate certificates, not requiring HTTPS) to ensure we know we've got a real ciphertext from the expected source.
Graham concluded his talk by advising us to use mature, open, checked protocols rather than making our own. He suggests that we favour open API standards over proprietary ones and avoid common pitfalls and legacy defaults. He finished by advising that we get our security choices and implementations reviewed by a third party - "it's easy to write crypto that you can't break" (which strikes me as a logical extension of one's inability to even proof-read one's own writing!)
Identity Is the New Currency
Mike Salsbury attended this session:
Paul Simmonds has a lot of experience, and that showed through in a very comprehensive and assured talk, delivered with no little humour (plenty of cartoons). Check the slides for the funnies, but there were also serious points to be made around the Jericho Forum commandments, and the Security Guidance for critical areas of focus in cloud computing v3.0 from the Cloud Security Alliance. Overall Paul showed that the more data is externalised, then the more that security from the network becomes irrelevant and the security of data needs to increase. Don't protect your perimeters, protect your data wherever it may go.
Understanding & Managing your Digital Footprint
by Robin Wilton
Twitter feedback on this session included:
@timanderson: If you have nothing to hide you are not a social being says Wilton, good response to "you don't need privacy" brigade #qconlondon
@skipper69: not all information is appropriate to every audience - we tend to forget this when going online @futureidentity #qconlondon
@timanderson: We have no technical control over data beyond first disclosure observes Wilton #qconlondon
@timanderson: Paying for a service is no assurance that your data is not mined observes Wilton we should review the bargain regularly #qconlondon
@timanderson: We lack the means to separate work and personal contexts online says Wilton #qconlondon boundaries eroded
@timanderson: We are bad at assessing risk that is remote in time and place hence cannot easily evaluate risk of giving away data says Wilton #qconlondon
@timanderson: When a guy (Max Schrems) made a Subject Access Request to Facebook in 2012 he got 1200 pages of data held about him #qconlondon
Real Agile Delivery with DevOps Track
Dev "Programming" Ops For DevOps Success
Alex Blewitt attended this session:
Damon Edwards talked more generally about Continuous Delivery, including the process by which continuous delivery can be enabled, including looking for waste (when a process adds little value that could not be collected from automated systems) as well as being able to tie the original business request to the set of changes that are subsequently deployed into production.
By measuring key performance indicators (such as the length of time it takes from an original request to the change occurring in production, as well as the mean time to detect problems and mean time to repair problems) it is possible to see how any benefits are translated into the company.
Tim Sawyer attended this session:
Three steps to DevOps success:
- Have an Operations First mindset. Devs own the app, Ops owns infrastructure. Other stuff (Security, Quality etc) is shared.
- Build organisational alignment. Alignment is where different people come to the same conclusion. Visualise the system. Waterscrumfall.
- Establish a new model for working with ops. Replace tickets with self service interface. Pull rather than push.
Twitter feedback on this session included:
@shanehastie: @qconlondon @damonedwards Put operational requirements into your backlog as first class citizens. Your software is only valuable it it runs
@shanehastie: @qconlondon @damonedwards Your company doesn't make money from software - it makes money from a working service.
@shanehastie: @qconlondon @damonedwards Definition of Done: Value is derived when the product is running, it's managed, it's customer accessible.
@shanehastie: @qconlondon @damonedwards to get started with DevOps use a value stream map to visualise the actual end to process of development/deployment
@shanehastie: @qconlondon @damonedwards starting with DevOps then identify the wastes in the flow, pick the metrics that matter and empower people to fix
@taidevcouk: Developers, if you want [operational] freedom, [you must] take responsibility via @damonedwards #devops #qconlondon
@llopacki: Dev programming Ops for DevOps: See the system, focus on flow, recognise feedback loops, continuous improvements #qconlondon @damonedwards
@RobertSloss: silos kill flow in any organisation @damonedwards @qconlondon #simplifyops #DevOps #continuousdelivery
Development, Deployment & Collaboration at Etsy
Chris Laughlin attended this session:
At the time of creating the slides, Etsy had 60 million monthly visitors, 1.5 billion monthly page views and averages 50 deployments a day!
The best way to find out if you have the infrastructure to handle this is to ask yourself the following question "how comfortable are you with deploying a change right now?". In most cases the answer is not very comfortable. Not to fear - I agree with that. At Etsy it's not so much the change but the size of the change. The term small change is used a lot here. With a mix between small changes and configuration flags, deployments can be performed at any time with very low risk to the application and users. The work environment at Etsy provides a brilliant learning ground as mentioned by Daniel, "if it's your first day at Etsy you deploy the site". For most people (myself included) this would be a terrifying experience. First days are normally very stressful, but then also having the responsibility of deploying the sole product that the company offers is taking it too far.
But as you have guessed the team at Etsy have made this an extremely smooth and simple process. The entire application stack can be run on a generated VM. All developers use these VMs to provide consistency across the team. The CI is also handled by a VM - a cluster of build VMs running Jenkins are used to run the test suite and all other associated tests, freeing up the development VM for new workloads. Once all the tests have passed you are able to then move onto what they call the "deployment train" and use the in house developed and open sourced deployinator. Deployinator gives two simple buttons - "run tests" and "deploy". This allows the developer to quickly deploy and get on with the next block of work.
At Etsy they take pride in the fact that everything can be monitored. Once a build goes live, you then watch a number of tools including supergrep and the monitor dashboard for any flux or strange change. This will usually indicate if something was missed in testing and if there is a bug....
IRC [is used] for almost all communication. There is a channel for everything and probably the most important is #warroom. The "war room" is for build issue resolutions. Daniel talks about how this is a place where issues are analysed, resolved and a perfect place to "lurk" if you're new and want to see pro's at work. This is another place where the learning attitude at Etsy shines through. New joins and junior developers are encouraged to watch in rooms while people are working on an issue to let them see the thought process and pick up tips and tricks that other developers have homed over the years.
he last part of CI process which I loved and want to try out on my own project is the "post mortem" - This takes place after the live issue has been resolved and is an open blameless forum where the team can discuss the issue. A large part of this process is not"who did this?" but "what can we learn from this?".
Twitter feedback on this session included:
@rusmeshenberg: Etsy avg 50 deploys / day for the monolith site app - are you comfortable deploying right now ? #qconlondon
@alblue: Etsy uses config flags to enable individual features for users or groups of users #qconlondon http://t.co/cgAqR14X6s
@matlockx: First thing you do on your first day at #etsy: deploy the site #qconlondon
@alblue: Etsy's supergrep is on GitHub at https://t.co/W5mINgJEXF #qconlondon
@shanehastie: #qconlondon at Etsy every developer designs and builds the monitoring component for their changes. They know what it should do! @mrtazz
@jimshep: @mrtazz - "We have A LOT of dashboards" #etsy #qconlondon http://t.co/6e2KV0OXDJ
@czapinho: Etsy has internally the three-armed sweater award for most spectacular mistakes @mrtazz #qconlondon http://t.co/h0kQAC9EaG
@pedrowaty: Post Mortems are important, because We don't want to be surprise by your technology stack @mrtazz #qconlondon
@webdizz: Restart fixes several types of bugs just for free #qconlondon
@adrianco: Etsy at #qconlondon make it clear to me why monolithic apps are a dead end. Use microservices for continuous scalable deployments
DevOps at a Small International Bank - Contiguous Improvement over Continuous Delivery
zeresht attended this session:
Ola's talk was very interesting, though it felt very unreal to me as the entire staff of this bank is 12 - with only 3 people in IT ...
Ola said that working in such a small environment forced people to take on responsibility that might not be defined by their nominal role, and that it was essential to focus on Activities not Roles. ...
Operating at such a small scale also forces Ola to focus on minimalism and pragmatism. ... Ola also espouses a need to look at Holism - the understanding of the whole, and when this is also brought into the equation it's possible to look for really powerful but Lean solutions. ...
Ola talked about the need for reducing the time taken to roll-back, and he described this brilliantly as having a Ctrl-Z strategy. We always undotypos and mistakes when we're working at a computer, so why should doing releases/deploys be any different? Being able to do this would certainly give more confidence in an ability to "release now"...
Ola achieves this Ctrl-Z approach by investing in a pure build - i.e. building and releasing from scratch rather than in an incremental fashion. Clearly an approach like this commoditizes the "running instances" and can be useful in other scenarios - e.g. failover to BCP locations, etc. If you always release by doing a "virgin" build, then it's easy to have confidence in doing the same in an extenuating, disaster-like situation.
Other techniques Ola mentioned were to do with database changes. It's imperative to make these easy to roll-back as well, so they need to be non-destructive where possible, e.g. by use of shadow-copies of DB tables, and by adding columns and renaming old ones, allowing the reverse operations in case of roll-back.
Interestingly he moved his team from Subversion to Git and explained that the focus of development should be on conversations rather than complex-locking. I
Twitter feedback on this session included:
@_brush_: Activities not Roles. Might be a key to thinking about DevOps. "I mainly do X" and not "I'm X". #qconlondon
@juristr: You have to have a "holistic" approach, view the whole thing, not only code; #devops #qconlondon http://t.co/SuXT7vFgfP
The Process, Technology & Practice of Continuous Delivery
by Dave Farley
Alex Blewitt attended this session:
The key points were:
- Once a release candidate is built from a commit, it is not rebuilt again
- The state of each release candidate is a property of the artifact repository
- Triggers listening to state changes in the repository drive the process
- Having everything automated (testing, setting up environments, deploying) reduces the chance of human error
- Stateful processes can be migrated if there is more than one host (for redundancy) and it's possible to dump and re-load the in-memory state
Will Hamill attended this session:
Dave started his talk by going over the basics of CD and then followed up with principles and practices.
Why should businesses embrace CD? In order to reduce the feedback loop between business idea and customer reaction; in order to iterate on value faster. CD brings out the pain; the slow, inflexible, risky, costly parts of the traditional software life cycle to address these issues. CD uses lean thinking to deliver fast, build quality in, optimise the whole system, eliminate waste, amplify learning and empower the team.
This is done, in theory, through smart use of automation - through creating a repeatable, reliable process for releasing software beyond just tooling. In order to create this process you must automate almost everything and keep everything under version control. If some part of the deployment process hurts: do it more often and find a way of making it better. 'Done' no longer should mean 'code complete' or 'tested' but released to production. Dave advocates making everyone involved responsible for the process and encouraging a culture of continuous improvement. ...
What I found particularly interesting was that Dave mentioned that when he coined the term 'deployment pipeline' he didn't intend it as a single-stream like a huge oil pipeline, but more like process piping. He illustrated this by showing the deployment pipeline as a star-shape rather than a line, with performance tests, exploratory tests, acceptance tests, staging tests all running in parallel on an artifact. A deploy would only proceed once all test suites had tagged the artifact as passing.
Twitter feedback on this session included:
@webdizz: Repeatable and reliable it means could be done not by human @davefarley77 #qconlondon
@adrianco: #qconlondon @davefarley77 says "done" is when code is in production. For me "done" is when it's removed from prod. Run what you wrote.
@jimshep: @davefarley77 Principles of Continuous Delivery:RepeatAutoVersionPainQualityDoneEverybodyImprove#qconlondon http://t.co/OlLBb12HcF
@thought_forge: Dave Farley, "Use precisely the same mechanism to deploy to every environment". #QConLondon
@_gev: So true about continuous delivery. If it hurts, do it more often - bring the pain forward! @davefarley77 #QConLondon #failfast #DoD
@gjtaylor: Without security, it's just devop, not devops #qconlondon
@gjtaylor: Devops is quality driven; security is a quality #qconlondon
Real Data Science Track
A/B Testing: Avoiding Common Pitfalls and Lessons Learned at Spotify
Mike Salsbury attended this session:
A fascinating look into the world of how to optimise testing the efficacy of new versions of web pages. Not just the functionality, but the customer impact versus a 'control' page. Spotify has 24 million users, and knowing which new page is more efficient at attracting their attention is potentially big business. A/B testing allows that to be tested, and the talked highlighted a lot of statistics to prove the point. It also highlighted some of the major pitfalls, and related the significance back to the statistics.
Stayin' Alive - Tales of Resilience, Fault Tolerance & Recovery Track
Building Resilience: How Outages Shaped Etsy's Systems
by Avleen Vig
Alex Blewitt attended this session:
Avleen talked about how Etsy scaled their deployment systems, mainly by identifying bottlenecks in their existing deployment process and being able to speed those up.
The Etsy codebase is a collection of PHP files which are deployed and pushed to the Etsy servers, with an Apache front end displaying them. The deploy time of this data set is around 15 minutes, so to enable more pushes per day they combine several unrelated changes in each push and synchronise between the members of those changes to increase the velocity of changes going out. In addition, by separating out configuration changes versus code changes, two parallel streams of pushes could occur, which freed up more resources for being able to push content out. ...
The key deliverable was that if a process is slow, identify through measurement where the bottlenecks are and then design a system around those bottlenecks as a way of increasing throughput and decreasing latency for the system.
Twitter feedback on this session included:
@pixelastic: There is no such thing as human error when building resilient systems. #QConLondon
@jejking: There is no such thing as human error. Just the start of an investigation #qconlondon
@tastapod: If you don't have a resilient organisational culture you won't build resilient systems. Wisdom from @avleen at #qconlondon
@jejking: Information needs to circulate across departments to avoid unintentional errors @avleen #qconlondon
@a32an: Feeling envious but grateful on how open Etsy people are allowed to be about their outages. #qconlondon @avleen
@tastapod: It took us a really long time to figure out the problem. 5 minutes for us is a really long time. @avleen at #qconlondon #perspective
@zootalures: @avleen : "If it moves, graph it; if it doesn't movegraph it anyway, it might move" #qconlondon
@jejking: Etsy prefers fix forward over rollback says @avleen #qconlondon
@ddanciu: If you make sure that changes in your deployments are small enough you can also always fix forward when problems occur #qconlondon
@ddanciu: Take a look at github project Morgue... support for doing post-mortem on problems. #qconlondon
Exploiting Loopholes in CAP
Dusan Omercevic attended this session:
Nygard presented 10 approaches how to simultaneously achieve consistency, availability, and partition tolerance by changing the definitions of these terms, something that can be done in many real-life scenarios. For example, if we limit ourselves to use only Conflict-free Replicated Data Types (CRDT) we can still have a consistent and available system even in the case of system's partition since CRDTs blend seamlessly once the system unifies again. Similarly, if we assume that 100% system's partition is impossible (e.g. by relying on GPS as Google Spanner does), we can build quite consistent and available system even if network itself is partitioned.
So, next time when you'll be using the CAP theorem in an argument, think again if the premises required for CAP theorem to hold are valid in your specific case, too.
Alex Blewitt attended this session:
Michael talked about various 'loopholes' (really, just relaxing some constraints) to improve certain aspects of the problem:
- Since reading mutable state is the problem, if reading is not required then the problem goes away by default, though this is not particularly useful!
- If the content is written but never modified (WORM) then reads will always be consistent.
- If the databases are always self-consistent - in other words, all database constraints are met - then reads will always be consistent even if some are out-of-date.
- Partition consistency and available within a subset can be performed, if the subset is in a well-defined area (e.g. within a data center) connected by potentially disconnectable devices.
- Bounded consistency - the core may be consistent (e.g. read/write data) whilst external mirrors will be eventually consistent (e.g. caches).
- Stop using distributed systems (as useful as option 1).
- Use a more reliable network that provides guaranteed connectivity.
- Use an external reference point (such as GPS time signal) to ensure that operations can be linearized, as used by Google Spanner
- Redefine availability to mean read but not write; so reads always succeed but writes may fail in the case of a partition.
- Consider observable consistency, in which provided that the updates occur and results are visible when the system is consistent.
Twitter feedback on this session included:
@tastapod: I can easily design a system that is neither consistent nor available. Beware bad logic! @mtnygard abusing CAP at #qconlondon
@tastapod: TIL "Consistent" in CAP doesn't mean nodes have the same value, but that they have the same /history/ of events." @mtnygard at #qconlondon
@tastapod: Some historical shared atomic object is the "Once upon a time..." of distributed systems. @mtnygard at #qconlondon
@vnadgir: Consistency is not a property of your database but of your entire application @mtnygard #qconlondon
@jejking: Use knowledge of domain to reason about what guarantees needed where, @mtnygard #qconlondon
@pedrowaty: In networking there is no difference between too slow and pass away @mtnygard #qconlondon
@tastapod: Of course for a metaphysical state explanation why wouldn't you use a 1930s Porky Pig cartoon as your illustration? @mtnygard at #qconlondon
Fault Tolerance 101
Twitter feedback on this session included:
@stilkov: "Programming is the act of turning an inexact description of a problem (a specification) into an exact one (a program)" @joeerl #qconlondon
@tastapod: You can't buy the carpet because our computer is broken "But the carpet is fine!" @joeerl unhappy with non-fault tolerant shop #qconlondon
@timreid: @joeerl - cornerstones of fault tolerance - detect errors, correct errors, stop errors from propagating #qconlondon
@tastapod: Nice. If you build for fault tolerance, you effectively get scaling for free. People are using Erlang for scaling! @joeerl at #qconlondon
@tastapod: Abstract of @joeerl's PhD thesis:Q: Can you build reliable applications out of unreliable components?A: Yes.#qconlondon
@tastapod: Defensive programming is a complete and utter waste of time. LET IT CRASH! @joeerl putting the world to rights at #qconlondon
@tastapod: The job of the OS is to maintain invariants (e.g. tidy up after a crash). Got my money's worth already :) @joeerl #qconlondon
@tastapod: Compendium of bugs. Thanks @joeerl #qconlondon http://t.co/ThaLjZ13op
@skipper69: when a program crashes send the noisy error message to the programmer and the polite one to the user @joeerl #qconlondon
@webdizz: Defensive programming is a consequence of bad concurrency model @joeerl #qconlondon
@rolios: Facebook started his chat in #erlang, dropped it for c++ in 2009, and then... Bought #whatsapp, using erlang, 5 years later. #qconlondon
@yareeh: Fault tolerance implies distributed computing implies parallel computing implies scaling up. @joeerl #qconlondon
From Instability to Resilience: The Story of a Web Site
Twitter feedback on this session included:
@tastapod: When a tree falls in the forest there is no Big Red Button - @richcampbell explaining resilience at #qconlondon
@tastapod: Everybody's got an opinion, let's start with facts! @richcampbell explains how to start diagnostics. #qconlondon
@mtnygard: In a crisis, your character determines how you respond. @richcampbell #qconlondon
@tastapod: Let's move the app to the cloud == "Let's pay for failure by the hour". @richcampbell tells it like it is at #qconlondon
@tastapod: As developers we don't try to own the RoI - we aren't used to facing the business consequences @richcampbell at #qconlondon
@tastapod: If you're on one server, you are one What's that button do?" away from failure" @richcampbell at #qconlondon
@ufried: we need to be willing to give up some performance for better scalability @richcampbell at @qconlondon ... abolutely!
True Mobile & Beyond Track
Modifying Treasure Island
Twitter feedback on this session included:
@yareeh: Hide the technology so it feels like magic. @alysonf #qconlondon
@swardley: Like this (2008)? - http://t.co/eLSdLGV825 -> RT @yareeh: What if a book became a magical, gesture-responsive object? @alysonf #qconlondon
@pablojimeno: Hardware is becoming less about screens and more about objects that interact...@alysonf #qconlondon
Solutions Track Wednesday 1
The Wisdom of Clouds: Building Applications not Platforms
by Mandy Waite
Twitter feedback on this session included:
@andypiper: . @tekgrrl asks "what happens if you want to use PaaS but need a language GAE doesn't support?" - answer #cloudfoundry! :-) #qconlondon
@andypiper: Interesting that GAE uses yaml (Ruby inspired config file) for config #qconlondon nice to hear shout outs for RabbitMQ and Redis.
@andypiper: Sounds like Node and Ruby "may" come to Google App Engine soon #qconlondon - this is why buildpacks are better as a standard approach.
Solutions Track Wednesday 2
Is It A Car? Is It A Computer? No, It's a Raspberry Pi Java Carputer
by Simon Ritter
Alex Blewitt attended this session:
Simon Ritter talked about how to use a Raspberry Pi to graph data collected from a modern car's electronics, using an ELM327 to plug into the car's on-board OBD diagnostic port, and provide the results over either WiFi or Bluetooth. It provides an AT-style command set (pdf) including AT MA to monitor all communication, and AT MT x to monitor communications for a specific device id.
Combining this with an accelerometer (MPU9150) via the Raspberry Pi'sI?C interface and using the i2c-dev and i2c-bcm2708 modules, along with i2c-detect -y 1 to list the addresses of the components on the bus, was able to read the accelerometer data and display that in measured G load in the device itself.
Simon then demonstrated a standalone Raspberry Pi with a touch-screen HDMI device and a data track, along with a video of the device in action in a real car. Simon plans to write a blog post describing this in the near future.
Project Avatar - Server-Side JavaScript on the Java Platform
Mike Salsbury attended this session:
Project Avatar is taking Nashorn from Java 8, and using it to allow you to access java objects directly from your JavaScript. Given that we at Caplin are very interested in JavaScript then we were fascinated to see what the latest was on this 'work in progress'. There were plenty of slides highlighting that the old way of writing webapps let the work be done on the server. And that the new way is to create single page web apps where most of the work can now be done on the client. There was also a CLI demo of running Nashorn and writing JavaScript code to run a Java Thread object, and then interrogating that threads state. Finally we were given the timeline on future developments which shows Nashorn available for Glassfish now, and Weblogic in the next year. However, Tomcat or any other webapp support would need to be added 'by the community'.
Solutions Track Thursday 1
Keys to Continuous Delivery Success
by Mark Warren
Twitter feedback on this session included:
@mtaulty: @mark_warren says Pixar use Perforce to store every frame of an animated movie. Hadn't even occurred to me. #qconlondon
@timanderson: A glimpse at NVidia's #perforce repository 556 million files, 1.3 billion revisions, 88% of employees use #qconlondon
@timanderson: #Salesforce has 10 million #perforce transactions per day and 5,000 testing VMs says Mark Warren #qconlondon
The DevOps Maturity Curve - Where Are You on It?
by Chris Rowett
Tim Sawyer attended this session:
Use service virtualisation, and mock external resources that aren't always available. Remove the bottleneck of an external dependency.
Five levels of continuous deployment: 1 - Manual 2 - Scripting; brittle 3 - Automation; typically 2-3 weeks work from level 2 4 - Continuous; end to end process. This is an organisational transformation and can take weeks or months. 5 - Optimisation
Director sponsorship required for success. Pick a first project to evangelize.
Test team need to code tests, rather than manual testing.
Drive continuous improvement from devops metrics.
Solutions Track Thursday 2
A Big Data Arsenal for the 21st Century
by Matt Asay
Andrew Jones attended this session:
One of the key points was to build on open source tools. This is important for many reasons - one of which is to avoid large upfront costs, as that increases the cost of failures.
Almost all of the new data technologies in the past 10 years are open source (the only exception is Splunk). Open source has moved from imitator to innovator.
You also want something flexible, as data is messy, and getting messier. NoSql technologies are a much better fit for this than traditional databases.
Connecting Everything - APIs & PaaS
Alex Blewitt attended this session:
Paul Fremantle talked about APIs and platform as a service (PaaS) as being the next stage in the evolution of virtualisation. Instead of VMs and OSes being virtualised (Infrastructure as a Service) the next layer up (Platform) is being virtualised. An API is like a virtualised service itself; by providing a connection point between two services. He also linked to A company without an API is like a computer without internet.
Paul also observed that having an API and a way of monetising that API is necessary for being able to ensure growth. ...
To build an API-first system, start with developing an API and ensure that all clients go through that API. That way, the system's contents is exposed via the same API that everyone uses, which means that there aren't first-class versus second-class applications. In addition, as new features are added to the API then all clients can take advantage of it. ...
He concluded by noting that everything is evolving to virtualisation.
- APIs are the virtualisation of functions
- PaaS is the virtualisation of application development
- Forge/Cloud toolchain is the virtualisation of development
- DevOps is the virtualisation of deployment
- Enterprise Store is the virtualisation of application delivery
Twitter feedback on this session included:
@andypiper: . @pzfreo "PaaS is the virtualisation of applications and application constructs - capabilities and deployment" #cloud #qconlondon
@andypiper: Brian Koles "A company without APIs is like a computer without Internet" quoted by @pzfreo #qconlondon http://t.co/xAfMzBcXNu
@alblue: A business model around APIs is equally important #qconlondon
@andypiper: "have hackathons, see if people like your API and can build interesting things with it... monitor social media and forums" #qconlondon @pzfreo
@andypiper: Think about API ecosystem; versioning; "minimal viable API" #qconlondon @pzfreo
@andypiper: API First - start with the API, external devs should be first class citizens, be mobile-first-friendly #qconlondon @pzfreo
Opinions about QCon
Opinions expressed on Twitter included:
@futureidentity: Ideally this kind of thing shouldn't be necessary, but all credit to QCON for publishing an event code of conduct: http://t.co/yqXkcFCLNi
@julienvey: By the way, #qconlondon has a great buffet, and great food/drinks all day long. A well fed geek is always a happy geek !
@ufried: . @qconlondon not only is a cool conference. it also has a great wi-fi, working nicely even in the session breaks (wanted to mention that)
@cosh23: Wow what a great conference. Met so many awesome people #qconlondon (@ London @HeathrowAirport (LHR) w/ 93 others) http://t.co/NEbBTZCcWk
@eriklindgren: Beside all the techie stuff at #qconlondon I must say that the #trifork coffee was outstanding. http://t.co/RgxIm4MQhp
Takeaways
Alex Blewitt's takeaways were:
Micro-services are big. It's not just SOA in a different guise (which was really about RPC with giant XML SOAP messages) but rather URIs and message passing or JSON data structures.
Agile companies are deploying components many times per day.
Failure happens. Failing to plan for failure happening is to plan for failure.
The GPL is effectively dead for corporate sponsored open-source projects.
Andrew Jones' takeaways were:
- Microservices - It's clear any big application these days ought to be split into microservices.
- The lambda architecture - Another trend was the discussion of the lambda architecture as a way to build your Big Data applications.
- Open Source - All the Big Data technologies over the last 10 years are open source (with the exception of Splunk), which is great!
Tomasz Lepiorz's takeaways were:
- Cloud Computing has been living on the market for few years and possibly it is not worth still waiting for employing it, now is time to do
- Java is on top but this is not the only used language
- NoSQL databases market share is getting bigger and bigger
Impressions on QCon London included:
@sonosen: Leaving a great #qconlondon 2014. My favorite talk was the one by @tastapod giving advise from his accidental career.
@pixelastic: After seeing 4 talks about Etsy at #QConLondon, their awesomeness just seems normal. Return to the real world on Monday will be hard.
@rolios: What I really liked at #qconlondon: speakers were mostly speaking about ideas, concepts or architecture rather than new framework/language!
@taidevcouk: Many thanks to entire @qconlondon team for an excellent conference! The venue & food was great, but most importantly the talks were awesome!
@alysonf: Great day at #qconlondon. Inspiring people, ideas and conversations.
@jhberges: A few thoughts after QCon London 2014 http://t.co/LRCNBEDenI #qconlondon
@glen_ford: Enjoyed #qconlondon lots of good talks, great people and interesting conversations
@sekarmdu: Thank you to @CreditSuisse for choosing to let me participate in @qconlondon. In short, 3 days at QCon has helped me evolve !
@cartwrightian: very good #qconlondon, lots of new things I need to learn about and lots of catching up with friends I've not seen for too long
@charleshumble: #QConlondon has been a blast. Looking forward to New York and SF later in the year.
@DajanaGuenther: Current Status: Relax and watch all the talks I couldn't see at #qconlondon thanks to @InfoQ who made sure they were recorded.
Conclusion
The eighth annual QCon London brought together over 1,100 attendees - including more than 100 speakers – that are spreading innovation in software development projects across the enterprise. 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.
QCon London 2014 was co-produced by InfoQ.com and Trifork – producer of the GOTO conference in Denmark. QCon will be back in London March 2-6, 2015.
The next QCon this year will be in Sao Paulo, Brazil, in April 2014. Then in June 2014 the third QCon New York event will be held at the New York Marriott just outside of Manhattan (at the Brooklyn Bridge). Tracks include Applied Data Science and Machine Learning, The Latest Trends in Java Technology, functional programming, big data, cloud and continuous delivery. Finally we’re in San Francisco in November.