One day we woke up and things were different. Maybe it happened overnight, maybe it took many years. Suddenly we are scripting against thousands of Virtual Machines from the command line while creating things today with JavaScript in the browser that were impossible yesterday. LiveScript becomes JavaScript becomes ES6 and now we’re compiling C++ to JS. Join Scott Hanselman as he explores the relationship between the Cloud and the Browser, many Languages and one Language, how it might all fit together and what might come next.

Understanding how the brain works and building machines that work on the same principles is one of the greatest quests of our time. In this talk I will describe recent advances in neocortical theory, including why the brain uses sparse distributed representations and how the brain makes predictions from high velocity sensory data streams.

I will demonstrate a product called Grok, that uses a detailed model of neocortical memory to act on machine generated data and how developers can contribute to the development of intelligent machines via the NuPIC open source project (www.numenta.org).

I will end my talk with a discussion of the future of machine intelligence.

For the domain of databases, the old question of how to achieve language integrated query is receiving renewed attention, in part because of its support through Microsoft’s LINQ framework. We present a practical theory of language-integrated query based on quotation and normalisation of quoted terms. Higher-order features prove useful even for constructing first-order queries. We prove a theorem characterising when a host query is guaranteed to generate a single SQL query, and we present experimental results confirming our technique works, even in situations where Microsoft’s LINQ framework either fails to produce an SQL query or, in one case, produces an avalanche of SQL queries. Our ideas are implemented in F#, and the talk briefly considers how they might apply to other languages such as Scala and Haskell.

There is no official “devops” Manifesto. I’ve always shied away from writing this for two main reasons:

• not setting things in stone encourages people to keep an open mind. So they can come with their own version of the solution AND the problem. This allows our field to expand and have people re-think and re-evaluate other people’s solutions.
• it often brings a sense of checklist. Do A,B,C and you have reached the final goal. Devops does not have an end-goal, it is continuous journey; whatever you change to improve, will have an impact and might require you re-think your strategy

Therefore I value more the different models people have developed along the years to understand/explain the “devops” problem space:

In the first part of the session, I will iterate over the conceptual models I’ve come across that try to capture the essence of devops. In part two we will leave the theory, and provide a more practical way of obtaining the shared view, using a sort of ‘reverse value stream mapping’ technique. Finally, we’ll take a step back and see how well we’ve done in the past years, explain some of the caveats and look towards the future.

Don’t expect specific tools to be explained in full; We will refer to the tools as examples of concepts though. Come with an open mind and re-think / re-evaluate your “devops” project while applying the principles of the different models.

The Java driver for MongoDB has been around almost as long as the NoSQL database itself. It was designed without some of the modern Java features we now take for granted, and the API might be easier with features like lambdas.

The existing Java driver is extensively used, which leads to a tricky question: how do you create a new API that uses modern development patterns whilst retaining backwards compatibility? Your users are fundamental to the success of your business, you do not want to alienate them, break their systems or make it hard for them to migrate to the New World Order.

In this presentation Trisha will share some of the pain experienced and solutions tried while creating a new Java driver for MongoDB.

For decades we’ve known that modularity, loose coupling, and service orientation allow for the construction of large software systems that can be reasonably maintained and extended. In this talk, Steve explores from a services perspective the architecture of Riak, the open source distributed database from Basho Technologies, focusing on how it achieves fault tolerance and high availability based on modularity, supervision, replication, and message passing between services, as well as how it integrates subsystems written in different programming languages. He also discusses how Erlang, the language used to implement most of Riak, facilitates the construction of service-oriented systems.

So you’ve heard about the buzz behind Microservices and finer-grained architectures in general? Microservice architectures can lead to easier to change, more maintainable systems which can be more secure, performant and stable than previous designs.

But what are the practical concerns associated with running more fine-grained systems, and what are the new things you’ll need to know if you want to embrace the power of smaller services without the new sources of complexity making your life a nightmare?

This talk will delve deeper into the characteristics of well-behaved services, and will define some clear principles your services should follow. It will also discuss in more depth some of the challenges associated with managing and monitoring more complex distributed systems. We’ll discuss how you can design services to be more fault-tolerant, what technologies may exist in your own platform to get you started. We’ll end by giving some pointers as to when you should consider microservice architectures, and how you should go about introducing them in your own organisation.

How to manage and balance all the future features, some architectural work, defect corrections and a growing technical debt. We present a simple strategy based on four colours to help putting it all in the same frame of reasoning, in a single backlog, with some détours about the real nature of technical debt, about value versus cost, the old concept of earned-value, your velocity, and risks and uncertainties.

Earth Engine (http://earthengine.google.org/) is an experimental platform for environmental analysis, providing petabytes of data and an API suitable both for exploratory programming and very large scale batch processing. Our science partners are using it to detect illegal logging in the Amazon, build global maps of land use, estimate forest biomass and carbon, and map the world’s roadless areas.

This talk covers 3 different functional programmers’ experiences applying Functional Programming in industrial settings; A product company improving their process and success, a new team with new projects, and a team performing experiments with multiple implementations using FP and non-FP languages. There have been some impressive results, and some interesting challenges. We hope these stories inform and inspire you if you are interested in adoption FP in your organisation.

Team 1: A new project, and a new team, is theoretically an ideal time to start using functional programming – green fields. Michael had to good fortune to be a co-founding engineer where the teams were built from the grown up, and projects split off organically. Hyper-small teams (1 or 2 people) and FP (Scala and Erlang, mainly) with the so-called micro-services approach allowed this to work – and scale reasonably well as teams grew. There have been trade offs, but using FP has enabled a breadth of features to be implemented via very small teams. Michael will talk about these trade offs and benefits as his portion of the talk

Team 2: ThoughtWorks has been engaged by IOOF to assist them in building superannuation integration solutions. Korny will talk about how ThoughtWorks and IOOF ran an initial three week experiment to evaluate functional programming languages, using a range of objective and subjective metrics. Based on the results of that experiment, the team developed their integration system in Clojure – Korny will also talk about how the adoption went, and how Clojure was a key factor that allowed them to meet tight deadlines in spite of multiple requirement changes.

Team 3: Atlassian products have to run in all manner of environments, with tens of thousands of customers running every possible combination of hardware, OS, DB and more. Functional programming techniques have proved useful to tame the complexity, and now serious FP projects are underway and gaining momentum. Jed relates the challenges, the pitfalls and the successes that have come with introducing FP to Atlassian.

One of the scenarios described is likely to apply to you – we hope you can take this experience back to your organisation and look at ways you can introduce functional programming based on these lessons learned.

Even a tool, like the Disruptor, that comes out of the box with great performance, it is possible to apply an understanding of the problem and a some mechanical sympathy to make the software run even faster. In this talk I will demonstrate an advanced technique of applying the Disruptor to two specific, but very common use cases to improve throughput and decrease latency. The cover of the CPU will be lifted to examine a number of hardware metrics with the intention of understanding where the additional performance comes from.

BDD is a set of practices which help software development teams to have conversations about the behavior of their system and how it delivers value to the project stakeholders. BDD has changed from its early roots as a replacement to TDD and now works as a mini-methodology across the whole software lifecycle. Over the last few years the adoption of BDD has grown globally, with dozens of tools created, used by hundreds of projects around the world.

In this talk we look at the original reasons behind the creation of BDD, bringing the focus back to the language and conversations which lie at its heart. We look at how BDD’s patterns can be applied at multiple scales – from the initial project vision all the way to the code – to deliberately discover and address uncertainty and risk in every aspect of software development, producing reliable, maintainable software that matters.

This talk covers 3 different functional programmers’ experiences applying Functional Programming in industrial settings; A product company improving their process and success, a new team with new projects, and a team performing experiments with multiple implementations using FP and non-FP languages. There have been some impressive results, and some interesting challenges. We hope these stories inform and inspire you if you are interested in adoption FP in your organisation.

Team 1: A new project, and a new team, is theoretically an ideal time to start using functional programming – green fields. Michael had to good fortune to be a co-founding engineer where the teams were built from the grown up, and projects split off organically. Hyper-small teams (1 or 2 people) and FP (Scala and Erlang, mainly) with the so-called micro-services approach allowed this to work – and scale reasonably well as teams grew. There have been trade offs, but using FP has enabled a breadth of features to be implemented via very small teams. Michael will talk about these trade offs and benefits as his portion of the talk

Team 2: ThoughtWorks has been engaged by IOOF to assist them in building superannuation integration solutions. Korny will talk about how ThoughtWorks and IOOF ran an initial three week experiment to evaluate functional programming languages, using a range of objective and subjective metrics. Based on the results of that experiment, the team developed their integration system in Clojure – Korny will also talk about how the adoption went, and how Clojure was a key factor that allowed them to meet tight deadlines in spite of multiple requirement changes.

Team 3: Atlassian products have to run in all manner of environments, with tens of thousands of customers running every possible combination of hardware, OS, DB and more. Functional programming techniques have proved useful to tame the complexity, and now serious FP projects are underway and gaining momentum. Jed relates the challenges, the pitfalls and the successes that have come with introducing FP to Atlassian.

One of the scenarios described is likely to apply to you – we hope you can take this experience back to your organisation and look at ways you can introduce functional programming based on these lessons learned.

A few billion likes and a few hundred million photos uploaded a day. A hundred or so petabytes of queryable data and a handful of power hungry datacenters. And it’s all humming while code is being written and deployed twice daily without our users noticing. This talk will explore the “move fast” side of Facebook’s software engineering culture: development process, organizational structure and the vast amounts of tooling we use to make sure we don’t screw up. We’ll also dig into how we “ship things”: release process, A/B testing, gate keepers, test infrastructure and so on. You’ll walk away with a prospective of how we build software at scale, for scale.

Five years ago DRW Trading was primarily a Java shop, and I was primarily developing in Ruby. Needless to say, it wasn’t a match made in heaven. Fast forward five years, Clojure is the second most used language in the firm, and the primary language for several teams (including mine). Clojure wasn’t the first language that I’ve introduced to an organization; however, it’s unquestionably the most successful adoption I’ve ever been a part of. The use of Clojure has had many impacts on the firm: culturally, politically, and technically. My talk will discuss general ideas around language selection and maintenance trade-offs, and specific examples of what aspects of Clojure made it the correct choice for us.

A few highlights

• Where to first introduce a new language and your role as the language care-taker.
• REPL driven development, putting TDD’s ‘rapid feedback’ to shame.
• Operations impact of adding a language – i.e. get ready for some DevOps.
• Functional programming, the Lisp Advantage, and their impact on maintainability.

Of course, no good experience report is all roses. The adoption has seen several hurdles along the way, and I’ll happily to describe those as well.

It is often important to look at our past, to understand how we got to where we are. Especially with something that has had such a rocky past. As performance in the browser and javascript VM are often optimised by popular trends and benchmarks how can we ensure our code is not going against the grain and suffering because of it? How will we be writing javascript in the future (if at all)?

Not everyone has the possibility of working on Greenfield projects or doing TDD or BDD. Many of us often end up having to work with legacy code bases that have little notion of what SOLID design principles are and unit tests are non-existent.

It can be daunting to have to maintain these types of systems. However, with a little bit of effort, we can try and make the best of the situation. By applying a series of patterns, techniques and principles, we can gradually refactor legacy systems to produce a better, friendlier and more sustainable design. Come and find out how!

A successful commercial programming language must be instantly familiar to its target audience. It must be engineered to deal with the challenges of todays systems. It must innovate and yet not over innovate. Dart, Google’s new web language, follows this approach and provides high performance on today’s web browsers. In contrast, Newspeak is a work of uncompromising idealism implemented on a figurative shoestring. Yet both languages share a common philosophy favoring pure object orientation and network awareness. Both languages support variations on features such as mirror based reflection, actor based concurrency, optional types and mixins. In this talk, we’ll compare the two languages/platforms and discuss why and how specific differences arose despite the commonality.

This talk tells a true story with a thin disguise. (The company involved does not want some details known.) Two years ago, a team I work with developed an application that addressed a strategically important pain-point. This is the story of how we used the Strategic Design tools of DDD to decide what to do, and how we ultimately turned it into a simple problem by leveraging established formalisms to do something quite original.

JavaScript has become important and ubiquitous. There are more people writing JavaScript than any other language. The language is surprisingly powerful, but comes with virtually no guard rails or safety devices. It is possible to write JavaScript in the style of other languages, but that can quickly lead to code that is difficult to maintain. By understanding how this language actually works, and by working with the language’s grain, you can be more productive and happier.