Many software developers point their career towards ascending to the gilded rank of Architect…but what does it mean to actually be one? While many of us labor under false pretense of abject technical decision making, the reality is often very different. You'll code less, spending more time on activities that lack an objective green/red bar. But you'll also an opportunity to impact far more than one project.

In this talk, I'll speak to my own journey. We'll touch on influencing coworkers, the importance of communication and the importance of cup of coffee.

Many software developers point their career towards ascending to the gilded rank of Architect…but what does it mean to actually be one? While many of us labor under false pretense of abject technical decision making, the reality is often very different. You'll code less, spending more time on activities that lack an objective green/red bar. But you'll also an opportunity to impact far more than one project.

In this talk, I'll speak to my own journey. We'll touch on influencing coworkers, the importance of communication and the importance of cup of coffee.

At the end of the day, an architect's primary job is to communicate. Not only do we need to make sure our teams understand the design of the system well enough to implement it, we must be able to explain our decisions to an audience that isn't impressed with how many TLAs you can rattle off in one sentence. Successful architects need to seamlessly transition from in depth technical conversations to budget meetings to discussions with end users adjusting the message to fit the audience.

While oral communication is key, good architects also spend a good deal of time putting pixel to screen via email, IM and various architectural documents we're expected to create. We need to write clearly and concisely while also knowing when the best course of action is to pick up the phone or walk to someone's desk.

In this talk, we'll explore the various methods that we as architects use to communicate with our stakeholders. We'll talk about knowing our audience, being able to present as well as how to run a good meeting. We'll discuss various patterns (and antipatterns) of presenting along with some concrete advice on how to do it better. At the end of the day, our job is to tell effectively tell a story - this talk will look at ways to do that.

Good architects are, almost by definition, good story tellers. And while good communication skills are vital to success as an architect, so too is an ability to constructively critique an architecture. In this talk, we'll explore why reviews are important and what it takes to perform them well. Additionally, we'll talk about the importance of planning and preparation in conducting a successful review.

Good architects are, almost by definition, good story tellers. And while good communication skills are vital to success as an architect, so too is an ability to constructively critique an architecture. In this talk, we'll explore why reviews are important and what it takes to perform them well. Additionally, we'll talk about the importance of planning and preparation in conducting a successful review.

In some organizations, architects are dismissed as people that draw box and arrow diagrams - the dreaded whiteboard architect. While we don't want to foster that stereotype, it is important for an architect to be able to construct basic architectural diagrams. An architect must also be able to separate the wheat from the chaff eliminating those models that don't help tell the story while fully leveraging those that do.

In this workshop, we'll discuss the various diagrams at our disposal. We'll walk through a case study and as we go, we'll construct a set of diagrams that will help us effectively communicate our design. We'll talk about stakeholders and who might benefit from each typ of diagram. Additionally we'll discuss how to constructively review an architectural model.

Workshop Requirements

Neither a laptop nor special software is required for this workshop though your modeling tool of choice (Spark, Visio, OmniGraffle, etc.) is welcome for the exercises. Of course paper and pencil are very effective too and frankly recommended! Feel free to work in pairs or teams. That's it! Well, and a willingness to participate!

In some organizations, architects are dismissed as people that draw box and arrow diagrams - the dreaded whiteboard architect. While we don't want to foster that stereotype, it is important for an architect to be able to construct basic architectural diagrams. An architect must also be able to separate the wheat from the chaff eliminating those models that don't help tell the story while fully leveraging those that do.

In this workshop, we'll discuss the various diagrams at our disposal. We'll walk through a case study and as we go, we'll construct a set of diagrams that will help us effectively communicate our design. We'll talk about stakeholders and who might benefit from each typ of diagram. Additionally we'll discuss how to constructively review an architectural model.

Workshop Requirements

Neither a laptop nor special software is required for this workshop though your modeling tool of choice (Spark, Visio, OmniGraffle, etc.) is welcome for the exercises. Of course paper and pencil are very effective too and frankly recommended! Feel free to work in pairs or teams. That's it! Well, and a willingness to participate!

The new facilities in Java 8 is about the change the way we write code. Our code will become
more expressive and concise. But, exactly how?

In this presentation we will take several common Java code examples, discuss the core idea expressed in code, and transform that code to use the facilities in Java 8. Watch and interact as you see Java code go through a weight loss program right in front of your eyes.

Functional programming has gained the recognition it deserves and almost all mainstream languages now support functional style of programming. With the introduction of lambdas in Java 8, we have new tools on our hands. In this presentation, we explore this tool and how we can benefit from it.

We start with an introduction to lambda and learn about imperative vs. declarative style and learn how to solve some common problems with it.

We all have heard about lambda expressions in Java 8. The real unsung hero of Java 8 are the Streams.

In this presentation we will take an example driven approach to explore streams, their core capabilities form the application development point of view, and how to explore these capabilities for improve performance and efficiency.

Although Agile has proven to provide incredible benefits in software development and delivery, it is not foolproof, nor a “Silver Bullet.” Plenty of factors need to be considered before attempting this highly disciplined approach.

Learn from the mistakes other organizations have made and discover which pitfalls to avoid to ensure that your first attempt at applying an Agile approach will be met with a successful outcome. This hour-long web seminar will explore these areas and provide clear steps your team and organization should consider to provide a clear set of tools to maximize the opportunity for best results possible.

Some come to Agile assuming it involves less discipline than their traditional methods, but this is a misperception. Today, the need for discipline in software development is greater than it ever was. Agile answers that need, arriving at discipline through the Team. Agile Teams must collaborate to develop strong discipline in both planning and execution.

We'll discuss how teams can obtain Agile discipline to achieve one of our core principles of delivering “working software” frequently. We'll explore some of the key Agile planning and engineering practices like continuous planning, Test-Driven Development, Continuous Integration and Acceptance testing. We'll look at the discipline involved in these practices, their inter-relationship, and the benefits they realize in delivering value to the customer.

The Executable Specification is a result of implementing a set of practices that allow frequent change in software products to ensure that the right product is delivered economically. We'll explore how mature Agile Team's go from User Stories to Executable Specifications by implementing practices that foster collaboration, shared understanding and liberal automation to achieve living documentation that supports the team.

We'll collaboratively walk through a evolving example of how software can be created by utilizing an executable specification to document the the software requirements and confirm it completeness.

Part 1 of this workshop focuses on the many elements required to make the journey from developer to architect, covering process topics like the impact of Continuous Delivery on architecture, technical subjects like application, integration, and enterprise architecture, and soft skills. While we can't make you an architect overnight, we can start you on the journey with a map and a good compass.

The job Software Architect places in the top ten of most annual surveys of best jobs, yet no clear path exists from Developer to Architect. Why aren't there more books and training materials to fill this demand? First, software architecture is a massive multidisciplinary subject, covering many roles and responsibilities, making it difficult to teach because so much context is required for the interesting subjects. Second, it's a fast moving discipline, where entire suites of best practices become obsolete overnight.

Part 1 of this workshop focuses on the many elements required to make the journey from developer to architect, covering process topics like the impact of Continuous Delivery on architecture, technical subjects like application, integration, and enterprise architecture, and soft skills. While we can't make you an architect overnight, we can start you on the journey with a map and a good compass.

• Soft skills
• Continuous Delivery
• Understanding large codebases
• Architecture patterns
• Architecture anti-patterns
• Tooling & documentation
• Integration architecture
• Integration styles
• Introduction to enterprise architecture

To fully leverage knowledge, you need application. Part three of this workshop uses the public domain Architectureal Katas exercise to apply learnings from the first two parts.

To fully leverage knowledge, you need application. Part three of this workshop uses the public domain Architectureal Katas exercise to apply learnings from the first two parts.

From the Architectal Katas website:

Architectural Katas are intended as a small-group (3-5 people) exercise, usually as part of a larger group (4-10 groups are ideal), each of whom is doing a different kata. A Moderator keeps track of time, assigns Katas (or allows this website to choose one randomly), and acts as the facilitator for the exercise.

Each group is given a project (in many ways, an RFP–Request For Proposal) that needs development. The project team meets for a while, discovers requirements that aren’t in the orignal proposal by asking questions of the “customer” (the Moderator), discusses technology options that could work, and sketches out a rough vision of what the solution could look like. Then, after they’ve discussed for a while, the project team must present their solution to the other project teams in the room, and answer challenges (in the form of hard-but-fair questions) from the other project teams. Once that challenge phase is done, the room votes on their results, and the next project team takes the floor.

Part 3, Architectal Katas, is an instructor-led hands-on Katas exercise.

The usage of JavaScript on the server is rising. In this session, we'll talk about all the tools and utilities that comprise a modern JavaScript application, from a server-side point of view.

The usage of JavaScript on the command line and server has exploded over the past couple of years. Node.js has become popular with development shops from startups to big corporations. With its asynchronous nature, JavaScript provides the ability to scale dramatically. Along with the ability to drive your server-side applications, there are a number of tools that help with all aspects of browser development: testing, packaging, and deployment. In this session, we'll explore these tools and show you how you can incorporate these into your environment.

In this session, we'll dig deep into the performance aspects of JavaScript and the Web Browser. Single page web applications are becoming popular very quickly, and understanding the low-level and high-level aspects of the browser platform and JavaScript runtimes embedding in them are important.

We'll cover topics such as browser pipe-lining, memory management, testing and measuring performance.

JavaScript has first class support for functional programming. There are many techniques for writing code in more clear, and concise form, in JavaScript using these techniques. In this session, we'll explore these techniques and talk about how to implement them. We'll use commonly used libraries like underscore to make elegant JavaScript code.

JavaScript has first class support for functional programming. There are many techniques for writing code in more clear, and concise form, in JavaScript using these techniques. In this session, we'll explore these techniques and talk about how to implement them. We'll use commonly used libraries like underscore to make elegant JavaScript code.

We've come a long way down the JavaScript road. Gone are the days of 'just hack it' for the web - architecting even a small project in JavaScript can be a challenge. Thankfully, there are several frameworks to help you; the most popular currently is Backbone.js.

Before you start using a framework in JavaScript, you will want to understand the techniques expert JavaScript programmers use to build them. In this session, we'll dive into design patterns in JavaScript, and do live coding so you can see these patterns applied. Even if you're not using a framework, you can use these design patterns to make your code more maintainabile, elegant, and concise.

We started with documents on the Web. Then we realized we could share data using the same technologies. And then services. Concepts were next to help us organize all of this information. And now, we want Things on the Internet and Web too. Fortunately, we already have much of the infrastructure to welcome all of these new physical information producers and consumers to the party.

This talk will be a high level overview of how the Internet of Everything scales to accept entire new classes of devices and how we make sense of it all. We will also look toward the future of where we are going next.

Encryption is a powerful tool for privacy. At least that is what we're meant to think.

If you consider encryption to be a black box of magic, you should probably attend this talk.
If you think encryption will protect your secrets, you should probably attend this talk.
If you have (or haven't) been following the news, you should probably attend this talk.

The truth is, encryption can be an effective way of making it harder for people to steal your secrets. But it isn't magical, it isn't fool proof and, depending on how you are using it, may be completely useless. It is a hard topic that we'll only touch the surface on, but there are very few topics that are more crucial for our industry and profession to understand better than encryption. You don't have to understand the math (although that will help), but you do have to understand what it will and won't do for you*.

*and how implementations of it may have been intentionally compromised

If you're not terrified, you're not paying attention.

Publishing information as webs of data does not require us to just give it away. We have a series of tools and techniques for managing identity, authentication, authorization and encryption so we only share content with those we trust.

Before we tackle Web Security, however, we need to figure out what we mean by Security. We will pull from the worlds of Security Engineering and Software Security to lay the foundation for technical approaches to protecting our web resources.

The cost of integrating information isn't cheap. Well, at least it isn't if you do it wrong. Chances are, you're doing it wrong.

The single most difficult aspect of data integration is the effort to achieve consensus. It isn't just that we are disagreeable people. It's also that it is a fantasy that there is a “common model” or a “global truth”. Different groups and individuals see the world differently and have different needs from information systems. Language, and therefore what we call things, isn't simply reflective of reality. It plays a constructive and interpretive role.

The problem is that our technologies force us to make choices about world views and pretend that things aren't changing constantly. This yields fragile systems and high impedance to change that cascades through our organizations. This translates to expensive, rigid and difficult to extend failure to give the business what they want.

Our friend Tim Berners-Lee and his Happy W3C Merrymakers have given us a set of technologies to help us solve these problems though. We forget that the Web he designed was not the public Web, but one to solve integration needs for complex organizations like CERN. The HTML bit that we have gotten so excited about is but a small part of the vision. We will introduce RDF and SPARQL as enabling technologies. They do not necessarily replace what you already have, but they do make it possible to share information with people you've never talked to: Collaboration without Coordination.

Instant messaging, video conferencing, online audio calls and file sharing have become a crucial part of every day life. Until recently, this required the use of a centralized service. Now, with the WebRTC Standard from the W3C, we have the ability to communicate through our browsers without relying on third parties or plugins.

This talk will introduce you to the WebRTC standards from the World Wide Web Consortium (W3C). This includes:

• establishing connections and sessions between peers
• making video calls
• making audio calls
• instant messaging
• file-sharing
• security and privacy issues

Inspired by success stories from companies such as Amazon and Netflix, many organizations are moving towards microservice architectures at a brisk pace. This session provides a thorough overview of the pros and cons for microservice architectures, when it is applicable, and some nascent best practices.

Microservice architecture is important because it’s the first architecture to fully embrace the Continuous Delivery and DevOps revolutions. In this session, I cover the motivations for building a microservice architecture (including making the distinction between “regular SOA” and microservices), some considerations you must make before starting (such as transactions versus eventual consistency), how to determine service partition boundaries, and ten tips to dowse you towards success. I also discuss the role of polyglot development, enterprise governance, how data and databases fit into this new world, and tooling to help ensure consistency between core services like logging and monitoring. This session provides a thorough overview of the pros and cons for microservice architectures, when it is applicable, and some nascent best practices.

“Docker is an open-source engine that automates the deployment of any application as a lightweight, portable, self-sufficient container that will run virtually anywhere.” Docker creates containers that provide running process with:

• an equal slice of CPU
• a maximum memory quota
• its own process ID (PID) namespace
• its own network interface
• its own private root filesystem

It does this by leveraging low-level Linux kernel primitives like cgroups and namepaces. The end result is a portable application container that can run anywhere Docker can run, including on VMs, bare-metal servers, OpenStack clusters, public instances, or combinations of the above.

Containers are an excellent way to package your application such that it can run consistently everywhere you want to run it, a fantastic step toward Continuous Delivery. In this session we'll look at how to use Docker to package, deploy, and run Java applications and other services. We'll also compare Docker to another container solution, Warden, which is a key component of the Cloud Foundry PaaS.

Building and running container images isn’t enough. There are very real problems that we still have to solve:

• how do we schedule and run these containers on infrastructure?
• how do we create networks that can link these containers across multiple hosts?
• how do we handle data that needs to persist across container restarts?
• how do we handle concerns like service discovery and load balancing?

These concerns are the focus of much of the development work being done in the Docker ecosystem today.

We’ll examine the use of several projects and how they contribute to solutions to these problems, including:

• Kubernetes by Google
• Apache Mesos
• Cloud Foundry Diego
• Cloud Foundry BOSH
• Weave
• CoreOS
• The Hashicorp family of projects

Modern applications are changing as we embrace the engineering practices associated with Continuous Delivery and DevOps, migrate our applications to modern cloud platforms, elastically scale applications with the dynamics of customer demand, and embrace microservices architectures. The Twelve-Factor App is a collection of application development patterns developed by Heroku engineers that aim to support these types of architectural and cultural change.

The 12 Factors are:

1. One codebase tracked in revision control, many deploys
2. Explicitly declare and isolate dependencies
3. Store config in the environment
4. Treat backing services as attached resources
5. Strictly separate build and run stages
6. Execute the app as one or more stateless processes
7. Export services via port binding
8. Scale out via the process model
9. Maximize robustness with fast startup and graceful shutdown
10. Keep development, staging, and production as similar as possible
11. Treat logs as event streams
12. Run admin/management tasks as one-off processes

We’ll examine how to implement these factors using JVM “microframeworks” like Spring Boot and Dropwizard.

Go is a very interesting language, open-sourced by Google in late-2009, that takes a “less is more” (http://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html) approach to language design, but that also bakes in a powerful concurrency model.

This talk will introduce Go, delve into its distinctives, and contrast its approach with that of Java (where appropriate). We'll also write a fair amount of Go code along the way. This talk will be of particular interest to Java developers looking to add Go to their toolkits, but will also be of interest to anyone looking to learn a little bit more about Go.

Topics will include:

• Go Syntax Overview
• Why Go?
• Contrasts with Java:
• Small language features and Idioms
• Packaging and Modularity
• Object-Oriented Constructs
• Concurrency with Goroutines and Channels
• Your Go Toolchain:
• Workspace
• The “go” Build Tool
• Dependency Management
• Testing
• Editors/IDE Support

A Technology Radar is a tool that forces you to organize and think about near term future technology decisions, both for you and your company. This talk discusses using the radar for personal breadth development, architectural guidance, and governance.

ThoughtWorks Technical Advisory Board creates a “technology radar” twice a year, a working document that helps the company make decisions about interesting technologies and where we spend our time. ThoughtWorks then started conducting radar-building exercises for our clients, which provides a great medium for technologists company-wide to express their opinions about the technologies they use every day. For companies, creating a radar helps you document your technology decisions in a standard format, evaluate technology decisions in an actionable way, and create cross-silo discussions about suitable technology choices. This session describes the radar visualization and how to conduct a radar building session for yourself. After a brief introduction, the bulk of the workshop consists of attendees building a radar for the group, following the same procedure you'll use when you do this exercise at your company. At the end, we'll have created a unique Radar for this event and practiced doing it for yourself.

HotSpot promises to do wonders for us by Just-in-Time (JIT) compiling the “right” code for us, but how does it makes those decisions? And, perhaps more importantly, what happens when it's wrong?

In this talk, you'll learn through real code examples just how the JVM decides to compile your code, deoptimize your code, and stop-the-world for a GC.

Early releases of Java performed poorly, but those issues largely disappeared long ago with the introduction of HotSpot. However, much of the performance advice for Java persists through hearsay from those early days.

In this talk, we'll forget the hearsay and take an objective look using benchmarking and profiling tools to find out which optimizations matter today and just as importantly those that don't.

Today, we all benefit from the sophistication of modern compilers and hardware, but that extra complexity can also make it difficult to reason about performance.

In this talk, we'll examine some surprising performance cases and learn how to
use profiling and benchmarking tools to better understand our modern execution environments.

Most of us don't want to go back to the days of malloc and free, but the garbage collector isn't always our friend.

In this presentation, you'll learn about the different garbage collection strategies used in JVMs, how to monitor garbage collection, analyze memory dumps, and why you might want to use one collection strategy instead of another.

Big data, smart phones, tablets, wearable devices, multicore processors,…—we're seeing rapid and drastic
evolution in both the computing environments and the application needs. Thankfully, a number of technologies have been evolving over the past several years to meet these demands. The reactive manifesto is an attempt to reenforce a set of technical practices needed to meet the emerging demands.

If you've heard and read about reactive programming, but are eager to realize that in code, then this presentation is for you. We will start with a rapid introduction and get into code to learn about reactive programming, not in theory but with practical examples.

Part two of this workshop takes a deeper dive in application, integration, and enterprise architecture topics, including evaluating architectures via Agile ATAM, the impacts of continuous delivery on architecture, comparing architectures, SOA, SOAP, and REST, integration hubs, and enterprise architecture approaches and strategies.

The job Software Architect places in the top ten of most annual surveys of best jobs, yet no clear path exists from Developer to Architect. Why aren't there more books and training materials to fill this demand? First, software architecture is a massive multidisciplinary subject, covering many roles and responsibilities, making it difficult to teach because so much context is required for the interesting subjects. Second, it's a fast moving discipline, where entire suites of best practices become obsolete overnight.

Part two of this workshop takes a deeper dive in application, integration, and enterprise architecture topics, including evaluating architectures via Agile ATAM, the impacts of continuous delivery on architecture, comparing architectures, SOA, SOAP, and REST, integration hubs, and enterprise architecture approaches and strategies.

Agile ATAM
Continuous Delivery for architects
Applying abstraction
Comparing architectures
SOAP vs REST/ WS vs Messaging
SOA deep dive
Integration hubs
Enterprise architecture approaches
Enterprise architecture strategies

Functional programming is receiving much attention recently. Most mainstream languages, including C++, Java, and C# now support lambda expressions and functional style. Why is there a sudden interest in adapting something that was largely ignored for decades? What are the technical reasons, how do we benefit, in what ways can using these techniques make our applications better and our development efforts easier as well?

In this technical presentation we will learn about the technical underpinnings of functional programming, the fundamental problems they address, and the large impact of those on application development

Microservice architectures place great emphasis on autonomous product teams that develop and deploy equally autonomous services using decentralized release management, testing, and deployment strategies. I don’t have to wait on you to deploy my service, and you don’t have to wait on me. And yet the complexity associated with managing these large, distributed systems seems like it would demand even greater discipline and centralized coordination of testing activities. Fortunately, while greater discipline is in fact required, we don’t require the centralized coordination that would seem to destroy many of the benefits of embracing microservices. In this session will examine principles and practices that will help us develop an effective testing strategy for microservices.

Topics will include:

• who moved my trust boundary?
• expressing API’s as versioned contracts
• what’s in a contract? the good, the bad, and the ugly
• leveraging consumer-driven contracts
• exploratory testing for risk discovery
• recovery OVER prevention
• dogfooding

It's been almost 15 years since the Agile Manifesto was discussed, conceived and signed. That leading statement of “We are uncovering better ways of developing software ..” truly has meaning. We'll discuss current state, trends and emerging practices in the industry to see if you are working with 2001 ideas or the best that 2015 has to offer.

It's been almost 15 years since the Agile Manifesto was discussed, conceived and signed. That leading statement of “We are uncovering better ways of developing software ..” truly has meaning. We'll discuss current state, trends and emerging practices in the industry to see if you are working with 2001 ideas or the best that 2015 has to offer. We'll look into the following to see what methods and practices you should be considering to jumpstart or re-invigorate your agile efforts:

• Top methods used
• Common practices
• New supporting practices
• Blending patterns

Unlike earlier languages, Java had a well-defined threading and memory model from the beginning. And over the years, Java gained new packages to help solve concurrency problems.

Despite this, Java concurrency is sometimes subtle and fraught with peril.

In this talk, you'll learn these subtleties. And finally, you'll learn how to handle concurrency by exploring the concepts behind java.util.concurrent and other concurrency libraries.

React.js is a view library from Facecbook for building performant user-interfaces in JavaScript. In this session, we'll explore React.js and understand why it's a great step forward for building complex UI's that run fast. We'll code up an example web application using React.js and step through the basics of using the library while discussing concepts like the virtual DOM and components.

In this session, we'll explore React.js and understand why it's a great step forward for building complex UI's that run fast. We'll code up an example web application using React.js and step through the basics of using the library while discussing concepts like the shadow DOM and components.

The Semantic Web and its related technologies provide an incredibly powerful model for driving the cost of data integration down to nearly zero. So, how do we deal with developers who are overwhelmed, frightened or annoyed by its data models and formats?

We really do not have to devolve into Webs of Haves and Have nots when it comes to semantically rich, interoperable data and modern application tools, frameworks and user interfaces. There is a surprisingly simple mechanism by which “normal” developers can benefit from the power of the Semantic Web and the latter's developers can integrate with the panoply of tools and toys under constant development by the former.

The trick is JSON-LD. A simple, but deliberately designed extension to JSON that bridges both worlds and is finding its way into many other uses by the likes of Google and GitHub.

We will learn about:

• the JSON-LD format
• how to frame, sign and validate it
• how to convert it to/from RDF
• how to describe Hypermedia systems with Hydra and JSON-LD
• how to embed and consume JSON-LD in HTML documents
• how JSON-LD is being used in a variety of mass market ways

Pair programming, or even more generally pairing, is often misunderstood and rejected without consideration or understanding of the immense benefits it brings to a team and organization. We will discuss how this works for developers, testers, business analysts, to get your team and project on back on track.

Pair programming, or even more generally pairing, is often misunderstood and rejected without consideration or understanding of the immense benefits it brings to a team and organization. Management will often react with “Why am I paying for two resources to do the work of one?” We will discuss how to address management and individual resistance to pairing by discussing the immense benefits pairing can bring to an Agile team. If your team is suffering from resources constraints, limited domain knowledge, low productivity, or simply completing your stories within the Iteration, don't miss this web seminar. We will discuss how this works for developers, testers, business analysts, and more. We will discuss how pairing can help to solve these impediments and get your team and project back on track.