The third annual QCon New York brought together over 500 team leads, architects, project managers, and engineering directors. Over 100 practitioner-speakers presented 80 technical sessions and 14 in-depth tutorials over the course of five days, providing deep insights into real-world architectures and state of the art software development practices, from a practioner’s perspective.
This year we introduced a discussion café at lunch with seating for 50 at 4 person tables. Topics included scalability, continuous delivery, and web + mobile UX. We also introduced a new HTML5 offline-capable conference guide for mobile devices, and a new social networking feature to help attendees connect better with each other and get updates from the conference.
In addition, for the first time, we were co-located with OSGi DevCon 2014, the premiere North American OSGi event, with speakers including Peter Kriens, Tom De Wolf, Neil Bartlett and Tim Ward.
Videos of most presentations were available to attendees within 24 hours of them being filmed, and over the course of the coming months InfoQ will be publishing these sessions as well as 24 video interviews that were recorded by the InfoQ editorial team. You can see our publishing schedule here.
There are also numerous QCon photos on our Flickr page.
- Domain Driven Overview
- Learn Kanban Essentials in a New York Minute
- Functional Programming in JS with Focus on Reactive Programming (Rx in JS)
- Your Hiring Process is Broken (and How to Fix It)
- Engineering Velocity: Shifting the Curve at Netflix
- NoSQL Like There is No Tomorrow
- Software is Dead; Long Live Software!
- Whither Web programming?
- Architectures You've Always Wondered About
- How Facebook Scales Big Data Systems
- Scaling Foursquare: From Check-ins to Recommendations
- Scaling Chartbeat from 8 Million Open Browsers to Real-time Analytics and Optimization
- Scaling Gilt: from Monolithic Ruby Application to Distributed Scala Micro-Services Architecture
- Solidifying the Cloud : How Google Backs up the Internet
- Continuous Delivery
- Creating Culture
- Everything as a Service (XaaS) - Web APIs
- Hot Technologies behind Modern Finance
- Java Innovations - The Latest Trends in Java Technology
- Lean Product Design
- Modern Big Data Systems
- Real World Functional Programming
- Software Architecture Improvements
- Taming Mobile
- The Evolving Cloud
- The Hyperinteractive Client
- Solutions Track
- OSGi Track #1
- OSGi Track #2
Training
Domain Driven Overview
Bas Eefting attended this training session:
I’ll try to sum up his session with the following points:
- agree on the terminology (get an Ubiquitous language for your project)
- don’t overdo it, stop modeling after a few iterations
- the critical complexity of many software projects is in understanding the domain itself
- re-evaluate your model when new problems arise
- use ‘code-probes’ more often, to inexpensively evaluate some assumptions
- split your model into ‘aggregates’, groups of ‘classes’ which logically belong together, and can be changed disjunctive of other aggregates.
- accept not all data changes have to be applied over your entire model IMMEDIATELY. Engage the business into discussing what parts of your model need to be updated ‘real-time’, and what parts can be updated in a later stage.
- again, don’t shy away from creating a new model, when your current model, although perfect for its current use, is not up for the job.
- it’s important to understand the relation between the different aggregates in your model, and what strategies to use on these relations (working together, just re-using the other model, translating between models or several other strategies).
- try to focus your modeling effort on your core-business, which might be just 10% of all the software you develop
- use your best developers and modelers to improve your core domain
- and again, when your business changes and new problems or opportunities arise:
- either re-evaluate where your core business is (and where to focus on)
- re-evaluate the models to your current issues
- re-evaluate the strategy on relationships between your aggregates.
Learn Kanban Essentials in a New York Minute
Tim Prijn attended this training session:
It was also really nice to see that the presenter often made a side note in which he also addressed questions like how to sell and change culture and thinking. The primary tip being: make sure the most important impediment is transparent to every stakeholder and they understand the consequences for their expertise. Wait for momentum (which can take a while especially if your rather impatient) and show that it can be different.
Functional Programming in JS with Focus on Reactive Programming (Rx in JS)
by Jafar Husain
Tim Prijn attended this training session:
Jafar clarified what we learned so far with a couple of key points:
- “The future of computing is describing WHAT we want to do, not HOW” referring to the difference between writing down code to loop over a collection versus only describing what we want from the collection.
- “With functional programming you write code, you come back two years later and it will run faster” making a key point to the fact of parallel and concurrent programming and that the computer itself will best know in which runtime conditions it’s in.
- There is no need for a garbage collection; this is garbage collection on steroids meaning that someone or something else manages the state and you don’t need to be bothered with it and only think about what you want.
Your Hiring Process is Broken (and How to Fix It)
Bas Eefting attended this training session:
Pete Soderling started out with stating that most software engineers are attracted to their jobs for two reasons:
- they like to solve difficult problems
- they love to work with smarter people
Now, knowing what engineers appreciate, it’s all about ‘telling the story’ about what unique opportunities exist at your company/project, and using the right ‘channels’ to share your story.
Keynotes
Engineering Velocity: Shifting the Curve at Netflix
Twitter feedback on this keynote included:
@kfirondev: Free the people & optimize the tools #netflix #qconnewyork
@floydmarinescu: Netflix culture from #qconnewyork keynote - "loosely coupled tightly aligned" http://t.co/xjtZLRSAgr
@darinrs: Managers role: Context not control. Loosely coupled, tightly aligned. @dmarsh from @netflix at #qconnewyork
@darinrs: Support parallel & independent paths of exploration. @dmarsh #qconnewyork "Waste" can lead to epiphany & benefit local team & entire org
@charleshumble: Blameless culture at #Netflix means everyone taking responsibility - @dmarsh from @netflix at #qconnewyork
@charleshumble: Support parallel, independent paths of exploration. @dmarsh #qconnewyork
@ebullientworks: Building a blameless culture... So important, sometimes hard to foster and maintain. #QConNY
@darinrs: In blameless culture: No one leaves with blame, but everyone leaves with action items towards improvement @dmarsh @netflix at #qconnewyork
@charleshumble: #Netflex @dmarsh announces new build language - Nebula - based on Gradle at #qconnewyork - http://t.co/tQXs12tXzy
@nzben: .@dmarsh reminds me that the @netflix culture slide deck is an absolute classic must-read for technical managers. #qconnewyork
@DataMiller: The great thing about Netflix engineers is they don't suffer pain for very long. They fix it. Dianne Marsh #QConNY
@DataMiller: I'd really not like to break the whole world! Dianne Marsh on regional isolation for deploys #QConNY
@sdempsay: Not all members of a team make take the same path, but as long as they are going the same direction it may be good enough. #qconnewyork
@jessitron: Netflix's Engineering Tools team has a goal: increase availability without slowing the rate of change. @dmarsh #qconnewyork
@dtunkelang: Nice insight from @dmarsh's keynote: continuous deployment may feel risky, but it decreases risk by preserving continuity and flow. #QConNY
@jessitron: The person who made the change knows best what to test and how to fix problems. Why do people throw it over the wall? @dmarsh #qconnewyork
@jessitron: Incident review at Netflix: everyone reaches for blame, leaves room with action items of their own devising. @dmarsh #qconnewyork
@jessitron: A developer's responsibility is widening to the whole lifecycle. Great tooling gives us visibility to make good decisions. #qconnewyork
@jessitron: Manage by context, not control: a manager brings the customer context to the team. @dmarsh #qconnewyork
@jessitron: Know your service. @dmarsh #qconnewyorkEvery Dev is responsible for testing impact of changes they make, and releasing responsibly.
@jessitron: Netflix open sources tools, helping cloud practice grow together with them. They don't release the secret sauce. @dmarsh #qconnewyork
@jessitron: Free the People. Optimize the Tools. @dmarsh #qconnewyork Every dev deploys, and tools help them do this carefully and watchfully.
Dennis Doomen attended this keynote:
Dianne Marsh, director of engineering at Netflix shared how Netflix ensures their engineers get the independence to innovate. Their basic vision is to let free of charge of the people and to improve the resources. They do that by having their professionals provide context fairly than management the men and women and consider to attract and keep talent. Clearly engineers have the tendency to go any which way they can, so professionals are intended to aid them to have some sort of alignment.
Jessica Kerr attended this keynote:
Dianne Marsh's keynote and Adrian Cockroft's session about how services are implemented at Netflix emphasized developer responsibility through the whole lifecycle of the code. A developer's job ends when the code is retired from production. Dianne's mantra of "Know your service" puts the power to find a problem in the same hands that can fix it. Individual developers implement microservices, deploy them gradually to production, and monitor them. Developers understanding the business context of their work, and what it means to be successful.
It'd be wonderful to have all the tech and business knowledge in one head. What stops us is: technical indigestion. Toooo much information! The Netflix solution to this is: great tooling. When a developer needs to deploy, it's their job to know what the possible problems are. It is the tool's job to know how to talk to AWS, how to find out what the status is of running deployments, how to reroute between old-version and new-version deployments. The tool gives all the pertinent information to the person deploying, and the person makes the decisions. Enhanced cognition, just like Engelbert always wanted (from @pwang's keynote).
"When you have automation plus people, that's when you get something useful." – Jez
"Free the People. Optimize the Tools."- Dianne Marsh
NoSQL Like There is No Tomorrow
by Khawaja Shams, Swami Sivasubramanian
Twitter feedback on this keynote included:
@charleshumble: “Build services, not software” - Amazon’s Swami Sivasubramanian at #qconnewyork
@seancribbs: OH: "Never compromise durability for performance." #amazon #qconnewyork
@adrianco: #qconnewyork @swami_79 @ksshams sacred tenets in services. Scalability, fault tolerance, blast radius, correctness http://t.co/QgKiBuAKql
ancribbs: Consistent performance is important, average performance is not good enough. #amazon #qconnewyork
@adrianco: #qconnewyork @swami_79 @ksshams Blast radius: fault independence using zones and regions to avoid correlated failure
@seancribbs: Insist on correctness. #qconnewyork #amazon
@randommood: fault tolerance is a lesson best learned offline @ksshams #qconnewyork
@adrianco: #qconnewyork @swami_79 @ksshams using formal methods based on a precise description of the design using TLA+, not reading the code.
@randommood: Law of large numbers is your friend, until you hit large numbers so design for scale @swami_79 #qconnewyork
@adrianco: #qconnewyork @swami_79 @ksshams AWS SREs learn PlusCal to work on TLA+ in a few weeks. Not an esoteric research only tool.
@adrianco: #qconnewyork @swami_79 @ksshams one in a trillion problems happen all the time at Amazon scale.
@adrianco: #qconnewyork @swami_79 @ksshams understand how your service will be abused by creative users
Dennis Doomen attended this keynote:
They insisted on planning for both scalability as well as failure. The former is usually something that doesn't get immediate attention, but that's usually still more than what we do with the latter. … How many companies actually monitor performance day by day? In my experience dev teams only start addressing performance when there's an immediate issue. One interesting concept they introduced is the Blast Radius. During their failure testing they explicitly analyze how far that failure reaches into the application landscape. With that information, they've tried to tune the interfaces between components to become a bit more resilient.
Software is Dead; Long Live Software!
Twitter feedback on this keynote included:
@roxanneinfoq: I have a big data problem means "I hurt" as per Peter Wang #QCon NY
@janerikcarlsen: Amateurs think about functions, professionals think about bandwidth - Peter Wang #qconnewyork
@jgrodziski: Building software = achieve state mutation over time in spite of complexity #qconnewyork from Peter Wang, great keynote btw!
@QuyJitsu: The fact that software changes rapidly puts the "soft" in software. Ironically this fact makes what we do so damn "hard". #QConNewYork
@jessitron: There is a collective temptation to stick our heads so far up our own abstractions we lose sight of the greater goal. @pwang #qconnewyork
@jessitron: It pretty much is 1979 for a lot of things we do. @pwang on single machine software. #qconnewyork
@jessitron: An unreliable airplane doesn't sell. But even bad software is pretty good. Low hanging fruit all over the place! @pwang #qconnewyork
@jessitron: Moving, copying, managing data is more expensive than computation. Math is no longer the hard part. @pwang #qconnewyork
@jessitron: Your code is going to be a thorn in someone's side eventually. @pwang and that's a win; otherwise it's unused. #qconnewyork
@jessitron: Computer science can't eliminate complexity any more than rocket science can eliminate gravity. @pwang #qconnewyork
@jessitron: We are no longer insulated from the inherit complexity of computing. @pwangThe Stable Dependencies Principle dissolves under us #QConNY
@jessitron: How much of what we do is rallying around broken abstractions from the 1970s? @pwang #qconnewyork
Jessica Kerr attended this keynote:
Peter Wang told us we've been sitting pretty on a stable machine architecture for a long time, and that party is over. The days of running only on x86 architecture are done. We can keep setting up our VMs and pretending, or we can pay attention to the myriad devices cropping up faster than people can build strong abstractions on top of them. The Stable Dependencies Principle is crumbling under us.
Really we haven't had a good, stable architecture to build on since applications moved to the web, as Gilad Bracha reminded us in the opening keynote. JavaScript has limitations, but even more, the different browsers keep programmers walking on eggshells trying not to break any of them. The responsibility of a developer is no longer just their programming language. They need to know where their code is running and all the relevant quirks of the platform. "It isn't turtles all the way down anymore. We are the bottom turtle, or else the turtle under you eats your lunch." @pwang
Whither Web programming?
Twitter feedback on this keynote included:
@jessitron: There is a huge choice of programming languages for the web, and very restricted choice of viable languages" @Gilad_Bracha #qconnewyork
@QuyJitsu: Gilad Bracha at #QConNewYork quips that #Javascript is waiting for all integers values before adding them to the language.
@charleshumble: Watching @Gilad_Bracha demonstrating an experimental, incrementally compiling version of Dart at #qconnewyork
@jessitron: In Dart, you can add types and get a compiler error AND still run your tests. Type errors don't break your flow. @Gilad_Bracha #qconnewyork
@jessitron: Tight standards for <200k app sizes on the web, it feels like we're living in 1979 again. @Gilad_Bracha #qconnewyork
@adrianco: Fun with Lively - messing with the UI at runtime #qconnewyork http://t.co/Kn6vQUcI3P
@charleshumble: Lively's GUI object editor is itself a GUI object, and you can edit it - @Gilad_Bracha #qconnewyorkhttp://t.co/QWLVY1jzkg
@adrianco: Leisure is a cool live edit web based homoiconic presentation manager with built in functional language #qconnewyork http://t.co/eyBVIbe2A8
@jessitron: The basic architecture of Leisure is way ahead of any other editor. It's about self-application. @Gilad_Bracha #qconnewyork
@seancribbs: Not sure how "offline" is ever going to happen for web apps without admitting they are distributed systems. #qconnewyork
Joab Jackson reported on this keynote for Network World:
Web applications may one day surpass desktop applications in function and usability -- if developers have more programming languages to choose from, according to a Google engineer.
"You should have more choices of viable languages," said Gilad Bracha.
"I think the Web platform could make Web applications as good or better than native applications," Bracha said. "Ultimately it has to do that. Otherwise, the proprietary app stores will come and eat us all."
The ability to run Web apps offline will be critical … Any Web programming language, and its associated ecosystem, must have some way of storing a program for offline use, Bracha said. The Web programming language in the future must also make it easier for the programmer to build and test applications. …
One of the reasons that Google started work on the Dart programming language, which Bracha helped author, is to provide the Web with an industrial-strength programming language. Google did not design Dart "to replace JavaScript, but to give you options," Bracha said….
Bracha pointed to some other lesser-known and still experimental languages that show promise as well. One was Elm, a functional programming language for building GUIs…
Bracha also demonstrated Lively. Lively is even more responsive than Elm. The developer, when viewing a draft of their program in the browser, can simply click on any part of the application on the screen and Lively will bring up to the screen the specific object code that rendered the object….
Bracha showed off other responsive languages, Leisure and Newspeak, the latter of which Bracha created.
Architectures You've Always Wondered About
How Facebook Scales Big Data Systems
Twitter feedback on this session included:
@charleshumble: Jeff Johnson from Facebook announces Apollo at #qconnewyork: distributed database for strong consistency at scale.
@adrianco: #qconnewyork Facebook Apollo basically uses CP locally and AP between remote sites. C++11 and Thrift code. http://t.co/Q6nM8oCKJD
@adrianco: #qconnewyork Facebook Apollo uses Raft for consensus and RocksDB and MySQL for storage layer. CRDTs. http://t.co/tKZByZ5y5C
@adrianco: #qconnewyork Facebook Apollo Fault Tolerant State Machine uses cases http://t.co/qyEMJwQQZZ
@charleshumble: User and Apollo system code use fault tolerant state machines for load balancing, data migration, shard creation etc. #qconnewyork
@adrianco: #qconnewyork Facebook Apollo uses CP within a shard in a Datacenter and CRDTs to handle AP between datacenters as needed.
Sander Mak attended this session:
Apollo is a system Facebook has been working on for about a year in their New York office. The tagline of Apollo is 'consistency at scale'. Its design is heavily influenced by their experience with HBase. …
Apollo itself is written in 100% C++11, also using thrift2. The design is based on having a hierarchy of shards. These form the basic building block of Apollo. Essentially like HDFS (regions) are the building block for HBase. It supports thousands of shards, scaling from 3 servers to ~10k servers.
The shards use Paxos style quorum protocols (CP). Raft is used for consensus. Fun side note: this turned out to be not much simpler than multi-paxos, even though that was the expectation.
RocksDB (a key-val store, log-structured storage) or MySQL can be used as underlying storage….
The apparent sweetspot for Apollo is online, low-latency storage of aforementioned data structures…. Every operation on the Apollo api is atomic…. Atomicity works across shards, at varying levels… The idea is that Apollo provides CP locally and AP between remote sites….
In addition to just storing and querying data, Apollo has another unique feature: it allows execution of user submitted code in the form of state machines. These fault tolerant state machines are primarily used for Apollo's internal implementation. E.g. to do shard creation/destruction, load balancing, data migration, coordinating cross-shard transactions. …
One of the current applications of Apollo at Facebook is as a reliable in-memory database. For this use case it is setup with a RAFT write-ahead-log on a Linux tmpfs. They replace memcache(d) with this setup, gaining transactional support in the caching layer.
Currently, Apollo is developed internally at Facebook. No firm claims were made during the talk that it will be opensourced. It was mentioned as a possibility after internal development settles down.
Scaling Foursquare: From Check-ins to Recommendations
Twitter feedback on this session included:
@kfirondev: Foursquare has 15 Mongo clusters over 600 replicas. Check in grows exponentially #QConNY
@charleshumble: Zookeper will become the indispensable glue that holds everything together at Foursquare - @hoffrocket at #qconnewyork
Scaling Chartbeat from 8 Million Open Browsers to Real-time Analytics and Optimization
Twitter feedback on this session included:
@azat_co: The secret technical sauce of @Chartbeat success @qconnewyork #qconnewyork http://t.co/dWgPq96y1d
Scaling Gilt: from Monolithic Ruby Application to Distributed Scala Micro-Services Architecture
Twitter feedback on this session included:
@matthurne: If you want to adopt a microservices architecture, "build your next feature in a new service" @yoni_goldberg #QConNewYork
Dennis Doomen attended this session:
Gilt, a US fashion outlet site, decided to break their monolithic website into about 50 micro-services each owned by a separate team. They used Docker to ease deployment of those services on shared Amazon VMs. According to the speaker they were very successful in that migration, but were now facing the more operational challenges of supporting so many dependent services. Apparently he has taken the same conclusion that tooling for supporting that, as well as continuous deployment, are becoming more important by the year. He concluded the talk with the advice that if you consider moving to micro-services, just start building every new feature as a micro-service and add the required tooling along the way.
Solidifying the Cloud : How Google Backs up the Internet
Twitter feedback on this session included:
@GavinInNY: Data reliability does not have four nines. It needs 1 1 and 2 0s. #QConNY
@QuyJitsu: 99.99% availability is 54 minutes of downtime. No biggie. But 99.99% data integrity can mean a corrupt tax return @raygeeknyc #QConNewYork
@GavinInNY: Automation IS scalability #QConNY http://t.co/emlWgikKAi
@QuyJitsu: Sending an exobyte over a single SATA II connection, assuming no overhead, will take 115 years. Lesson: #Shard and #MapReduce. #QConNewYork
@kaimarkaru: #mapreduce helps to bring backup times down to the realistic realm from required 115 years or so :) @raygeeknyc #qconnewyork
Continuous Delivery
DevOps Culture And Practices To Create Flow
Twitter feedback on this session included:
@jessitron: Screwing it up and procrastinating are necessary prerequisites of learning. @jezhumble #qconnewyork
@MurrMarie: Continuous integration is a practice not a tool. ~ Jez Humble #qconnewyork
@jessitron: If the developer doesn't build quality code, you can't build quality in afterward. @jezhumble Not in QA, not in Operations. #qconnewyork
@feragile: Jez Humble ~ DevOps Culture And Practices To Create Flow #qconnewyork http://t.co/jjsP2Cw6Xn
@Sander_Mak: Code stays around longer than people. Data stays around longer than code. Plan accordingly. #qconnewyork
@MurrMarie: Detailed planning is a sign of low trust. ~Jez Humble #qconnewyork
@kaimarkaru: #leadership principles #QConNewYork @jezhumble http://t.co/Adi5szspoe
@MurrMarie: Job of managers is to enable their reports, not to tell them what to do. ~Jez Humble. #qconnewyork
@shirmondconway: “@feragile: Lean means investing on cutting waste, not cutting costs ~ Jez Humble #qconnewyork”
@jessitron: Align responsibility with power to fix the problem. @jezhumbleThat power often is writing code.No wonder devs are in demand.#qconnewyork
@jessitron: When trunk is always releasable, there is no feature freeze. This changes the relationship between devs and marketing. @jezhumble #qconny
@jessitron: The things Toyota does are not best practices. They are reactions to the problems that team was having at that time. @jezhumble #qconnewyork
Jessica Kerr attended this session:
As programmers and teams are going off in their own bounded contexts doing their own deployments, Jez Humble emphasized the need to come together -- or at least bring the code together -- daily. You can have a separate repo for every service, like at Netflix, or one humongoid Perforce repository for everything, like with Google. You can work on feature branches or straight on master. The important part is: everyone commits to trunk at the end of the day. This forces breaking features into small features; they may hide behind feature flags or unused APIs, but they're in trunk. And of course that feeds into the continuous deployment pipeline. Prioritize keeping that trunk deployable over doing new work. And when the app is always deployable, a funny thing happens: marketing and developers start to collaborate. There's no feature freeze, no negotiating of what's going to be in the next release. As developers take responsibility of the post-coding lifecycle, they gain insight into the pre-coding part too. More learning can happen! …
Dianne and Jez both used "Highly aligned, loosely coupled" to describe code and organization.
Migrating to Cloud Native with Microservices
Twitter feedback on this session included:
@suriyanto: Whenever you find you need to have a meeting between parties, find a way to eliminate that meeting. #QConNY #adrianco
@9muir: #QConNewYork @adrianco on storage: 'None of your technologies are interesting to me. I don't need a SAN, I don't need backup...'
@9muir: 'Software provisioning is undifferentiated heavy lifting, replace it with PaaS', @adrianco #QConNewYork
@charleshumble: Building apps is undifferentiated heavy listing - replace it with SaaS - mendix, platfora etc. @adrianco #qconnewyork
@charleshumble: DevOps is a re-org, not a new team to hire. @adrianco #qconnewyork
@toddlmontgomery: Follow developer adoption, not IT spend. @adrianco #QConNY
@charleshumble: The most advanced, scalable, stable code you can get is on Github. It's also your company's on-line Résumé. @adrianco #qconnewyork
@GavinInNY: Nothing wrong with pushing code that's inefficient so long as it is functional and moves the business forward @adrianco #QConNY
@charleshumble: Microservices are Loosely coupled SOA with bounded contexts. @adrianco #qconnewyork
@DataMiller: Relatively large number of relatively small nodes for availability. @adrianco #QConNY
@9muir: The cattle vs pets analogy absolutely sounds best when described by a deadpan Brit. 'Cow died, oh well, buy another' @adrianco #QConNewYork
@charleshumble: If you have a machine, and it has a name, it’s a pet. @adrianco #qconnewyork
@janerikcarlsen: Think of your services as cattle, not pets. @adrianco #qconnewyork
@DataMiller: Mechanism to display latency should be less than the human attention span (~10s) @adrianco #QConNY
@jessitron: Immutable code: you're not replacing your codebase every release, you're adding to it. @adrianco #qconnewyork
@tomtheguvnor: Incredibly thought-provoking talk from @adrianco on migrating to microservices. Of most interest was the focus on changing the org. #QConNY
Why Your Team Has Slowed Down, Why That's Worse than You Think, and How to Fix It
Twitter feedback on this session included:
@jezhumble: I think of monitoring as the sadder, wiser cousin of tests @tomheon #qconnewyork
@jezhumble: .@tomheon just motivated continuous improvement using an allegory of fork-lift drivers, jugglers and ninjas. Awesome. #qconnewyork
@azat_co: “@MurrMarie: Carve out a constant percentage of time to speed things up. ~Edmund Jorgensen #qconnewyork”
Dennis Doomen attended this session:
Edmund Jorgensen delivered a refreshingly fun session on the latency of teams and how bringing down latency is best thing an organization can do. So many managers are focusing on the short-term needs rather than understanding how expensive any form of latency is. Think of technical debt, manual deployment steps, or anything else that prevents a team for speeding up. His basic approach is that reducing latency creates information earlier and early information is worth a lot of money. In fact, it saves money, so why do managers still persist on spending all their capacity on building features rather than having a good balance between functionality and reducing latency?
Creating Culture
Climbing Off The Ladder, Before We Fall Off
Twitter feedback on this session included:
@HakkaLabs: Standing room only for @Spotify Chapter Lead Chris Angove's talk about new models for engineer career growth! #qconny http://t.co/IBgU2jzSRG
@nardras: don't train people to leave the company - spotify's @_chrisangove about why you should get off the ladder #qconnewyork
Dennis Doomen attended this session:
Chris Angove … explained how he tried to find the balance between alignment and autonomy (or "do what I say" vs "do whatever"). They quickly discovered that this is destined to fail, simply because these two ends should be orthogonal. Instead of that, they tell their engineers what to do, but don't tell them how to do that. Somehow this freedom brings along a lot of responsibilities. To help the teams know their part in the big picture, they can give them missions, short-term goals and a product strategy. …
Traditional companies generally use a linear ladder where a software engineer can potentially climb to senior software, architect or even CTO. This provides a clear structure for promotion, and thus more salary and status. However, according to Chris this model can also be a factory to eject people due to limited management positions or by promoting people beyond their capabilities. In short, it provides simplicity for the manager, not the engineer.
Alternatives exists. For instance, some companies use two ladders; one for management positions and one for software engineering positions. Although it provides a technological track, and it clearly sets up easy ways to recognize accomplishments, it still looks like a linear ladder. Similarly to the previous model it assumes that the only way to grow is to take more responsibility or control. It still doesn't answer how to experiment or switch between roles.
Spotify believes that people that add value should be paid more money regardless of their role or position. To support that they stimulate engineers to try something new, which doesn't necessarily mean they stop what they are doing. In other words, they try to get them out of their comfort zone, to acquire a new skill and to push themselves in a new direction. More specifically, to shake things up a bit and see what talents or skills somebody really has. So instead of this rather rigid ladder, they've introduced add-ons that add both personal value as well as business value aligned with the skill-set and interests chosen by the engineer. In a sense it is engineer-driven but supported by company. The manager must work with the engineer to help him or her to find those challenges or even define a completely new add-on, or even giving them some time off to attend trainings, sessions or workshops. And those add-ons don't have to exist upfront. It is perfectly fine for an engineer to come up with another add-on that adds value to the company. Some the add-ons currently being tried at Spotify include a speaker, a road manager, coach, evangelist, mentor, trainer, writer or even open sourcer. Even an architect is treated as an add-on, simply because they help in alignment rather than to make decisions. If you ask me, this sounds like a great model.
Creating Culture Open Space
Dennis Doomen attended this open space:
Another slot in this awesome conference with an open-space session on culture. This included a great discussion on mentoring and how important this is for your career. Several of the participants shared their opinions on how a junior engineer needs to be taught on how to get the most out of this skills and how to advertise him- or herself within an organization.
Another discussion was about how to determine if somebody is going to match your organization's culture during an interview. Inviting somebody for lunch helps to see how somebody behaves in a new group was one suggestion. Having full-day interviews to allow the person to relax was another. However, one participant said they stopped doing that because candidates would be completely drained at the end of the day. Another participant told us that upon arrival of the candidate, they first asked about there private life, kids, etc. and then came back after 5 minutes or resulting in a much more relaxed interview. Doing code assignments from home is also very popular, but some mentioned they were worried the candidate would game that system.
The final topic dealt with introvert colleagues. I explained how something like Flowdock seems to help those people that have great ideas, but just don't feel comfortable enough to share that in an open discussion.
GitHub Communications Culture and Tools
Twitter feedback on this session included:
@ddoomen: So Github rents Airbnb apartments to have team binding sessions... Now I understand the recent news about Airbnb ;-) #qconnewyork
@darinrs: Optimize engagement by allowing serendipitous discovery of topics / conversations / meetings @matthewmccull @github #qconnewyork
@darinrs: Support group, know what working on is important to company, have plan to move goal constantly forward @matthewmccull @github #qconnewyork
@darinrs: This is the best place you have ever worked": What you need/want friends and family to be saying" @matthewmccull @github #qconnewyork
Dennis Doomen attended this session:
I already knew that GitHub employees can spend 20% of their time on innovations, learning new things, but I didn't know that on average 70% of the people work remotely. That explains the amount of energy they put on building tools and offices that support that.
For instance, they've build an internal app that provides a central location for discussions, sharing ideas, their internal communications handbooks and having live video chats. They also organize mini-summits where two engineers can do an internal talk which is then shared through that same app. Even cooler, they build tools to allow them to listen to the same music all over the world. So if somebody makes a remark about a cool song at the other side of the world, it's almost as if they work at the same office.
They also pro-actively build small offices with a living room or café-styled look as well at different places in the world to allow people to have a nice place to meet informally. Those offices also have some kind of phone booths to work in. In fact, to better understand how it is to live outside of the US and in a different time zone and to work on a global project, the CEO decided to move to Paris for a year or so. They also organize beer:30 meetings where teams have informal virtual meetings with other global teams.
While discussing the communications guide, Matthew shared some of the foundational principles Github. First of all, teams make decisions about what they do, not committees of carefully selected people. Egos are not allowed in discussions. In the end, the best argument wins. That's an interesting statement, especially considering my own challenges to give somebody enough room to make their point sometimes. But even more striking is that everything is open within GitHub. The financial situations, salaries, expenses and even meetings that deal with the future and strategy of the company.
Learning from Building and Scaling Gilt
Twitter feedback on this session included:
@darinrs: Management structure, technology architecture: all constructed to attract and retain great people @mbryzek @gilttech #qconnewyork
@darinrs: Move fast with minimal risk. Remember that it is very easy to underestimate the risk of doing nothing. @mbryzek @gilttech #qconnewyork
@darinrs: Any time you sit down at the keyboard, you are creating the tech debt of the future. @mbryzek @gilttech #qconnewyork
@darinrs: By default strive for no coordination outside of team for success. Make required coord very explicit @mbryzek @gilttech #qconnewyork
@darinrs: Startup to Dunbar - Ratio of services to headcount should be increasing @mbryzek @gilttech #qconnewyork
@darinrs: Testing in production: Do everything else for verification but provide safe way to validate in production @mbryzek @gilttech #qconnewyork
@darinrs: If it is hard to quickly figure out what a micro service does, likely time for mitosis @mbryzek @gilttech #qconnewyork
@darinrs: With smart, autonomous people you need to make the room for them to fail towards improvement @mbryzek @gilttech #qconnewyork
@QuyJitsu: Insightful definition of a "great coworker" from @mbryzek: Someone better than me (in some way). These are the people to hire. #QConNewYork
Mentoring Humans and Engineers
Twitter feedback on this session included:
@kendaleiv: Getting the strongest people at any level and keeping them is the single hardest thing in any organization. @dblockdotorg #qconnewyork
@roxanneinfoq: Mentorship=setting expectations & letting the person know what is expected as the outcome. "Mentoring Humans and Engineers" #qconnewyork
Dennis Doomen attended this session:
Daniel Doubrovkine showed us how he approaches mentoring new employees within his current organization. …
This all starts by promising an interesting learning experience, both on the job as well as outside the job. For instance, new employees are also shown around in New York. What places they should visit. Where to find a nice place to stay. How to meet-up with new people. Next to that, they pick their mentors from the most experienced, pragmatic AND patient people that understand starting with clear milestones and then gradually moving to goals is the best. They know that fostering ownership and trust is essential, the room for self-exploration is required, while not overwhelming them with both information and too much freedom.
Even more important (and something I often forget in my desire to help teams) is that failing is okay, as long as you learn from it. You should really create an environment that provides feedback, but take responsibility to protect them from anything that would de-motivate them to try new things in the future. At the same time, teach them how to fail by given them an assignment that is difficult or impossible to do. And don't forget to advertise them within your organization. Always introduce them to whoever you run into and openly praise them for any accomplishments. Daniel's closing statement was particularly interesting since he warned us not to underestimate a young new colleague. They might be much smarter than you are….
Everything as a Service (XaaS) - Web APIs
10 Reasons Why Developers Hate Your API
by John Musser
Twitter feedback on this session included:
@azat_co: Number 1 your API sucks is documentation @qconnewyork #qconnewyork #QConNY http://t.co/tMICItNR2C
@jgrodziski: What's your TTFHW? Time To First Hello World? @johnmusser #qconnewyork http://t.co/6emzhAyrOO think of it as "0 To 60 mph" for your API
Hot Technologies behind Modern Finance
Python: Why Are the Big Dealers Making Big Bets?
by Andy Fundinger, Mario Morales
Twitter feedback on this session included:
@qconnewyork: #Python's strength is in its flexibility, which is why the big banks are investing in it: @Andriod at #qconnewyork http://t.co/LBFDCCo75E
Java Innovations - The Latest Trends in Java Technology
Evolving Java
by Brian Goetz
Twitter feedback on this session included:
@charleshumble: Why add closures to #Java? Languages have to evolve or they become irrelevant - @BrianGoetz at #QconNewYork
@charleshumble: Lambda expressions enable you to specify the what and let the library take care of the how. @BrianGoetz #QconNewYork
Nashorn - Native JavaScript Support in Java 8
by Viktor Gamov
Twitter feedback on this session included:
@vgrazi: #QConny I always wondered why project Nashorn? Just heard a great answer-we have front end JavaScript engineers we need for server-side code
@QuyJitsu: Shell scripting with #JavaScript using the REPL built-in with #JDK8 #Nashorn!"#! /usr/bin/jjs -scripting" #QConNewYork
Lean Product Design
Roadmap to the Lean Enterprise
by Trevor Owens
Dennis Doomen attended this session:
He showed us that a lot of the current successful startups were founded by prior Google developers. So why did they leave and became so successful? Well, according to his findings, using equity instead of salary as an incentive really gets people to innovate while most organizations have a rather traditional reward system. He also used a lot of fun facts from the world of the venture capitalists and how they never bet on a single horse. In fact, their entire investment strategy is based on the approach that one of the investments is going to be paying the losses made by the others. So he advices organizations to have multiple teams work on innovation at the same time. Or even better, let them leave the company, do their innovations autonomously and then buy them back, just like Google did.
The Product Design Sprint and Test-Driven Design
by Alex Baldwin
Twitter feedback on this session included:
@qconnewyork: The 5 phases of a Design Sprint: Build, Diverge, Converge, Prototype, Test. @alexbaldwin #lean #agile #qconnewyork http://t.co/3yJoe7wQlB
Modern Big Data Systems
Analyzing Big Data On The Fly
by Shawn Gandhi
Twitter feedback on this session included:
@Sander_Mak: Amazon AWS generates tens of millions of billing events/second. Hence they created Kinesis for realtime stream processing #qconnewyork
@GavinInNY: AWS built kinesis to solve their billing stream problems. 100s millions of billing events per second. #qconnewyork @shawnagram
Real World Functional Programming
A Day in the Life of a Functional Data Scientist
Twitter feedback on this session included:
@jessitron: Lessons of a data scientist: Be Paranoid. Test the data too. @rickasaurus #qconnewyork
@jessitron: Life: 60% munging data, 35% redoing work, 5% fun algorithms. We do everything we can to grow that 5% @rickasaurus #qconnewyork
@jessitron: Barb: a language designed around the issues faced by normal people loading really bad data. @rickasaurus #qconnewyork
@jessitron: The entire program is one big IEnumerable. It works amazingly well because it's so easy to test. @rickasaurus #qconnewyork
@jessitron: F# type providers: explore other people's web APIs from the comfort of your IDE. via @rickasaurus #qconnewyork
The Functional Programming Concepts in Facebook's Mobile Apps
by Adam Ernst
Twitter feedback on this session included:
@jessitron: Data should flow in one direction through your app. All updates flow in through the top. @adamjernst #qconnewyork
@jessitron: Functional UI: challenging for performance, but great for the code. @adamjernst and it seems the performance is achieved. #qconnewyork
Jessica Kerr attended this session:
In higher-level architectures, microservices are all the rage. Unlike old-style legible architecture diagrams, the dependency diagram in microservices looks like the death star. Services connect directly to each other willy-nilly.
There are alternative microstructure architectures that, like React.js, get the data flowing in one direction. Fred George describesputting all the messages on a bus ("the rapids") and let services spy on the messages relevant for them ("the river"). The only output a service has is more messages, delivered into the rapids for any other service to consume.
Software Architecture Improvements
If We Took Conway's Law Seriously...
Twitter feedback on this session included:
@codepiper: Software should be open for extension but closed for modification #qconNY 2014 #mike feathers
@jessitron: Architecture devolves when there's (I hate to say it) too much communication. @mfeathers #qconnewyork
@jessitron: Everyone here knows what Conway's Law is, and only two people are using it. Why? @mfeathers #qconnewyork
@jessitron: Instead of an Ops team that does deployments, a tools team enables deployments. An extension of cognition for developers. #qconnewyork
@jessitron: Move people among teams constantly to balance fresh eyes on the code against maintaining indepth knowledge. @mfeathers #qconnewyork
@jessitron: Our job is harder than we anticipate because everything matters. Build system, team structure. Burdens or leverage? @mfeathers #qconnewyork
@jessitron: Code has inherent value that makes us want to keep it alive; that works short-term. It is not a Redwood tree. @mfeathers #qconnewyork
@jessitron: We can readjust team structure to the needs of the code, or adjust code to new teams - by deleting and rewriting. @mfeathers #qconnewyork
@jessitron: Nature solved the longevity problem: we survive because we die. Our cruft dies with us.Software needs renewal too.@mfeathers #qconnewyork
@jessitron: There is no escaping decision making. @mfeathers #qconnewyorkSupport the decision with information. Don't try to take it away.
Dennis Doomen attended this session:
Michael Feathers is one particular of my hero speakers, not only because of his exceptional e-book, but also since most of his talks are truly inspiring. He has spoken about Conway’s Legislation numerous times, but this was the initial one exactly where he employed this legislation to propose organizational answers. About he said that irrespective of the greatness of your architecture and all the agile practices your making use of, faster or later you will operate into scaling problems caused by the organizational composition. I’ve been functioning at a client that grew from 8 to one hundred twenty men and women in about three years and Conway’s Legislation is truly seen there. It starts to get specific hard when you can not get all the developers on the very same flooring. That’s one of the factors Michael has a fantastic interest in the whole micro-companies hype. Given that every micro-services can be managed by at most 1 crew, it supplies not only architectural scalability but also on the organizational degree.
Jessica Kerr attended this session:
Connection between code and people was the subject of Michael Feathers' talk. Everyone knows Conway's Law: architecture mirrors the org chart. Or as he phrases it, communication costs drive structure in software. Why not turn it to our advantage? He proposed structuring the organization around the needs of the code. Balance maintaining an in-depth knowledge base of each application against getting new eyes on it. Boundaries in the code will always follow the communication boundaries of social structure, so divide teams where the code needs to divide, by organization and by room. Eric Evans also suggested using Conway's Law to maintain boundaries in the code. Both of these talks also emphasized the value of legacy code, and also the need for renewal: as the people turn over, so must the code. Otherwise that code+coder symbiosis breaks down.
Strategic Design: Embrace Imperfection!
by Eric Evans
Twitter feedback on this session included:
@jgrodziski: @ericevans0 team vithin bounded context must agree on design, architecture and process #qconnewyork
@jgrodziski: Multiple models: inevitable and desirable. Good reminders about bounded context by @ericevans0 #qconnewyork
@ddoomen: . @ericevans0 just admitted he wasn't sure what architecture is... What happened to the world? #qconnewyork
@ddoomen: According to @ericevans0 Netflix have reached perfectionism in handling imperfections #qconnewyork
@jessitron: If you want to make elegant designs, you need the ability to make an assertion and let it be true. @ericevans0 #qconnewyork
@jessitron: Multiple models: inevitable and desirable. Models are the way you think about a problem; have more than one. @ericevans0 #qconnewyork
@jessitron: Bounded Context: "at least in a few places, we have drawn a line around a space where there is one model present." @ericevans0 #qconnewyork
@jessitron: Bad design is going to be there. Allowing varied levels of quality makes room for good design. @ericevans0 #qconnewyork
@jessitron: Most of my career, "robust" meant "won't go down." Now it means "the system keeps working as parts of it go down." @ericevans0 #qconnewyork
@jessitron: Service architecture creates a boundary on one side. Keep the other side independent: no shared DB, separate deploy @ericevans0 #qconnewyork
@jessitron: Some people say "my service explains itself" :eyesroll:You have to think a certain way to use a good service well.@ericevans0 #qconnewyork
@jessitron: An architecture directive must include where it applies: not everywhere. Architectures have contexts too. @ericevans0 #qconnewyork
@jessitron: Everywhere it's gonna be like this! leads to halfhearted implementations that don't achieve the benefits. @ericevans0 #qconnewyork
@jessitron: Escape from the Big Ball of Mud means creating boundaries. @ericevans0 #qconnewyorkHe suggests an Anti-Corruption Layer.
@jessitron: Language interoperability is a two-edged sword. It lets you thoughtlessly create dependencies. @ericevans0 #qconnewyork
@jessitron: For a well-designed system, choose TrendyNewLanguage. It enforces strong boundaries and attracts sharp people. @ericevans0 #qconnewyork
@jessitron: Sometimes software looks like a fossilized picture of an earlier version of the organization. @ericevans0 #qconnewyork
@jessitron: No: this is so elegant we need to use it everywhereYes: this is so elegant we need to establish a context for it@ericevans0 #qconnewyork
@qconnewyork: .@ericevans0: "A practical architecture gives you a path from where you are now to someplace better."#qconnewyork http://t.co/oYDuX1APUZ
Jessica Kerr attended this session:
Eric Evans emphasized: When you have a legacy app that's a Big Ball of Mud, and you want to work on it, the key is to establish boundaries. Use social structure to do this, and create an Anti-Corruption Layer to intermediate between the two, and consider using a whole new programming language. This discourages accidental dependencies, and (as a bonus) helps attract good programmers. …
In code and with people, successful relationships are all about establishing boundaries. At QCon it was a given that people are writing applications as groups of services, and probably running them in the cloud. A service forms a bounded context; each service has its internal model, as each person has a mental model of the world. Communications between services also have their own models. Groups of services may have a shared interstitial context, as people in the same culture have established protocols. (analogy mine) No one model covers all of communications in the system. This was the larger theme of Eric Evans' presentation: no one model, or mandate, or principle applies everywhere. The first question of any architecture direction is "When does this apply?"
Dennis Doomen attended this session:
Right after admitting he wasn’t really sure what architecture genuinely is (!), he talked on our failed tries to create strong and resilient methods. Which is why he thinks Netflix is performing these kinds of excellent tasks. They have in essence managed to reach perfection in dealing with imperfection. As a prolonged-term architect that will profoundly influence my future endeavors.
Presented that I comprehended him appropriately, his standard rule-of-thumb is that inside a bounded context (BC) you ought to have 90% of the features lined by an elegant architecture. The remainder doesn’t have to be so excellent, as extended as the BC is aligned with the group structure. That assures that any shortcuts that are having are properly-identified inside of the crew and won’t shock other teams. By more decoupling the BCs from every single other using special interchange contexts that translate messages among BCs (aka the Anti-corruption Layer), and not sharing any sources this kind of as databases, you can localize the imperfections. Oh, and with that assertion of ‘not becoming so perfect’, he actually intended to use if-then-else constructs fairly than properly-created polymorphic abstractions!
Taming Mobile
Optimizing Mobile Performance with Real User Monitoring
@darinrs: % users intent delete during slow UI responsiveness? 48% unforgiving & will delete app when perceive slowness @brittanytarvin #qconnewyork
@darinrs: Real User Monitoring: the only way to know what normal feels like to your mobile app users @brittanytarvin #qconnewyork
@darinrs: Monitor first for baseline, validate acceptable range with iterative user studies --> performant Mobile app @brittanytarvin #qconnewyork
@darinrs: Real User Monitoring - understand what users see on daily basis and what you can do to make experience better @brittanytarvin #qconnewyork
The Evolving Cloud
Canary Analyze All The Things: How we learned to Keep Calm and Release Often
by Roy Rapoport
Twitter feedback on this session included:
@dmarsh: Canary analyze all the things at Netflix. @royrapoport #qconnewyork http://t.co/bQEJ5BButA
@cpswan: 'Absolute numbers are relatively unimportant' says @royrapoport about canary analysis on cloud track at #qconnewyork http://t.co/ca0NUTRyiy
@dmarsh: Describing challenges faced when implementing canary analysis, hoping to save you time. @royrapoport #qconnewyork http://t.co/ReDMi0ZK44
@cpswan: 'the cloud gives you infinite scalability for suitably small values of infinite' @royrapoport #qconnewyork http://t.co/fPXjRRJyGE
The Hyperinteractive Client
Front End Ops Tooling
Twitter feedback on this session included:
@qconnewyork: .@nzgb on the benefits of using #Browserify to write Common.JS code for the browser #javascript #qconnewyork http://t.co/5gSJ5sqyfc
Mobile Web: So Hot Right Now
by Dave Arel
Twitter feedback on this session included:
@QuyJitsu: The key to performance in an HTML5 mobile web app is "compositing", http://t.co/aduLR1RFOQ, says @davearel #QConNewYork
@azat_co: We built our own custom HTML5 CSS keyboard @davearel #QConNY @qconnewyork // super cool! http://t.co/NHUqFZxsAU
@QuyJitsu: Think like mobile engineers, says @davearel. Consider memory management, and how to leverage the GPU #QConNewYork
Web Application Development with Flight
Twitter feedback on this session included:
@burkeholland: DOM hating is unnecessary via @kassandra_perch #qconnewyork http://t.co/jiZflZVpS1
Zero To Testing In JavaScript
by Pamela Selle
Twitter feedback on this session included:
@kendaleiv: This: "What do you call code without tests? Legacy code" /via @pamasaur #qconnewyork
Solutions Track
Deployed in 60 Minutes: Increasing Production Deployments from Six Months to Every Hour
by Matt Makai
Twitter feedback on this session included:
@darinrs: Have a meeting time budget. Make meeting time a limited resource. Prioritize & minimize @mattmakai @twilio #qconnewyork
OSGi Track #1
What’s Cool in the New and Updated OSGi Specs (DS, Cloud and more)
by David Bosschaert, Carsten Ziegeler
Twitter feedback on this session included:
@garyrfield: OSGi Core Release 6 has added async services and promises. Also cross-namespace capability lookup for repositories. #OSGi #QConNewYork
@garyrfield: JPM4J from @pkriens looks really good. Indexes repositories like Maven Central, but understands OSGi capabilities. #OSGi #QConNewYork
OSGi Track #2
Intro to OSGi – The Microservices Kernel
by Peter Kriens, Tim Ward
Twitter feedback on this session included:
@jessitron: You can move your coupling to an XML file, but that's just fooling yourself. @pkriens #qconnewyork #OSGi
@denschu: Ok, #microservices are not a hype anymore #qconnewyork
@jessitron: Complexity is in the eye of the beholder. @TimothyWard #qconnewyorkIs #OSGi hard, or is it solving a hard problem that we'd rather ignore?
@jessitron: A system well aware of failure is much more reliable than a system that tries to pretend nothing will go wrong. @pkriens #qconnewyork #OSGi
@jessitron: Contract based programming: When replacing a module is easy, quality of modules is less important. @pkriens #qconnewyork #OSGi
@jessitron: OSGi extends the type safety of the language into the evolution of the application. @pkriens #qconnewyork #OSGi
Opinions about QCon
Opinions expressed on Twitter included:
@ddoomen: #qconnewyork is the place to be if you want your brain to be fried of information overload...
@kaimarkaru: So it *is* possible to provide non-stop coffee at an IT conference in NYC. What a contrast. Who knew ;) Great job #QConNewYork
@emilioguarino: I understand maybe half of what they're talking about at #QConNY Getting out of my field is super inspiring
Qingsong Yao’ opinion on QCon was:
The main reason I attend this conference is to know the industry trend in the software and service development, learning more people use bigdata and machine learning techniques in there services and find existing Microsoft customer and understand their user cases.
Takeways
@jtdavies: Sat back in comfort on @VirginAtlantic, good bye New York, it was a great #QConNewYork. London and family here I come!
@JamesKLavin: Enjoyed #qconnewyork, esp. excellent talks by @netflix, @facebook and @continuumIO. They've got some talented engineers & managers.
@paulwilliamhill: Really enjoyed presenting at @qconnewyork #QConNewYork an excellent conference filled with top minds.
@GavinInNY: What a great week at #qconnewyork. Met some amazing people and got truly inspired. #LetsGo
Jessica Kerr’ takeaways were :
Overall, QCon New York emphasized: question what you're used to. Question what's under you, and question what people say you can't do. Face up to realities of distributed computing: consistency doesn't exist, and failure is ever present. We want to keep rolling through failure, not prevent it. We can do this by building tools that support careful decision making. If we each support our code, our code will support our work, and we can all improve.
Qingsong Yao’ takeaways were:
Application monitoring and NoSQL/other database techniques are dominating the booths, nearly all booths are related to one of the techniques, which is also a good indicator of what is hot in industry.
Azat Mardan’s takeaways were:
- Hybrid mobile apps are successful and use stacks such as: Cordova+Ionic+Angular+SASS (Salesforce.com) and Backbone+React (Belly)
- Dev managers starting to use badges to motivate developers as oppose to traditional managerial ladder promotions (Spotify)
- ECMAScript 6 is going to be awesome but coming only next year
- Breaking monolithic apps into microservices is the hottest discussion topic in enterprise teams
- Developers deploy code 30 time a day and even dogs can deploy changes with Continuous Delivery (Etsy)
Conclusion
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 New York was produced by InfoQ.com. We will next be in Rio de Janeiro September 23-25 and San Francisco November 3-7 this year. QCon New York will continue to run in New York around June of every year.