In this example-driven presentation, you'll learn how to leverage Spring Boot to accelerate application development, enabling you to focus coding on logic that drives application requirements with little concern for code that satisfies Spring's needs.
For over a decade, Spring has sought to make enterprise Java development easier. It began by offering a lighter alternative to EJBs, but continued to to address things such as security, working with various sorts of databases, cloud-native applications, and reactive programming. And, along the way, Spring even took steps to make itself easier to use, offering Java-based and automatic component configuration. Even so, there's still a lot of near-boilerplate code required to develop Spring applications.
Enter Spring Boot. Spring Boot's primary purpose is to make Spring easier to work with. It achieves this in three ways:
All together, Spring Boot lets you focus on fulfilling your application's requirements without worrying about writing code that satisfies the needs of a framework.
In this session, you'll learn how to take your Spring Boot skills to the next level, applying the latest features of Spring Boot. Topics may include Spring Boot DevTools, configuration properties and profiles, customizing the Actuator, and crafting your own starters and auto-configuration.
TBD
In this session, you'll learn how to use Spring Data to rapidly develop repositories for a variety of database types, including relational (JPA and JDBC), document (Mongo), graph (Neo4j), and others (Redis, Cassandra, CouchBase, etc).
For decades, relational databases and SQL have enjoyed their position as the leading choice for data persistence. Even though many alternative database types have emerged in recent years, the relational database is still a top choice for a general purposes data store and will not likely be usurped from its position any time soon. When it comes to working with relational data, Java developers have several options.
But relational databases are not a one-size-fits-all solution. Thankfully, there are many options for data persistence, including relational, document, graph, key-value, and column-store databases, each presenting their unique way of handling data suitable for different problems.
Spring Data makes it easy to work with various databases by offering a programming model that is consistent, regardless of which type of database you're working with. And regardless of the database you're dealing with, you will find that Spring Data eliminates a lot of boilerplate code.
In this session, you'll see how to take Spring Data's automatic repository generation to a whole new level. We'll look at ways to model data and manipulate Spring Data to produce repositories and APIs that are more than just CRUD layers on top of a database.
TBD
In this sessions we'll see how to use components of Spring Cloud to configure and discover microservices in a cloud native microservice-architected application. Specifically, we'll look at Spring Cloud Netflix and Netflix' Eureka and Ribbon projects for service discovery as well as the Spring Cloud Config project's configuration server to provide a central point of external configuration.
Microservice-architecture presents many benefits, not the least of which include opportunities to develop, evolve, scale, test, and deploy individual modules of an application independently from the rest of the application. But once an application is broken apart, a new set of challenges arises.
If the individual microservices are to work together in service of the greater application, then they must know about each other. Rather than hardcode the specifics of each microservice within every other microservice, it's better to provide a registry with which a service can register and other services may use to lookup those service details.
Microservices, like any application, will also likely depend on application-level configuration. It's generally a good idea to keep that configuration separate from the application itself, and this is even more true with microservices. Using a centralized configuration service, microservices can obtain their configuration details, some of which may be shared across many microservices. Because it is separate from the application/microservice code, that configuration itself can be versioned and evolve at a pace independent of the microservices it serves.
Understand Java from a functional programming point of view. This part covers the basics of lambdas and streams, emphasizing functional programming by transforming collections using the stream approach.
Also includes method references and static and default methods in interfaces.
Functional features in Java, including parallel streams, the java.util.function package, the Optional data type, and reduction operations.
The talk also covers the new date and time package based on Joda time, as well as collectors and implementing the Collector interface.
Java SE 8 introduces many new features that can simplify your code. Using streams, lambdas, and the new Optional type all change the way we write Java. In this presentation, we'll work through a series of examples that show how to rewrite existing code from Java 7 or earlier using the new Java 8 approach.
Examples will include replacing anonymous inner classes with lambdas, switching from iterating over collections into transforming streams, using immutables wherever possible, lazy evaluation, and more.
This talk will focus on interesting features of Java 8 that go beyond the basics. Topics will include:
map
, filter
, and flatMap
methodsOptional
as intendedjava.time
packageSample code will be provided to illustrate all the techniques, along with tests and a build file.
Traditional approaches to software architecture do not address the core tenet of all agile practices - feedback! We make many of the most important architectural decisions early in the development lifecycle and fail to get accurate feedback on those decisions throughout implementation. Compounding the problem? Agile methods offer no architectural advice. This session explores several architectural practices that help increase architectural agility.
What’s the goal of architecture? To serve as a blueprint of the system that everyone understands? Possess the flexibility to evolve as new requirements emerge? To satisfy the architectural qualities, including performance, security, availability, reliability, and scalability? Yes. Yes. Yes. At the heart of these three questions are the three pillars of architecture - social, process, and structure. But how do we create software architectures that achieves all of these goals? And how do we ensure no disconnect occurs between developers responsible for implementation and architects responsible for the vision? In this session, we’ll explore several principles to increase architectural agility and provide some actionable advice that will help you get started immediately.
The way we build and deliver software is changing. We must deliver software more quickly than ever before and traditional approaches to software architecture, infrastructure and methodology do not allow us to meet demand. We’ve reached the limits of agility through process improvement alone, and further increases demand we focus on improving architecture, infrastructure, and methodology simultaneously. 12 Factor is an app development methodology for building modern apps in the modern era.
Building modern apps requires modern methods and 12 Factor is an app development methodology that helps development teams build software by emphasizing development practices that meld together modern architectural paradigms with agile practices like continuous delivery for deployment to cloud platforms. In this session, we’ll examine the 12 Factors and explore how to apply them to apps built using Java.
With Java 9, modularity will be built in to the Java platform…Finally! In this session, we explore the default Jigsaw module system and compare it to the alternative module system, OSGi, on the Java platform.
We will demonstrate the impact that Jigsaw will have on our existing applications and identify what we must do to get ready for Jigsaw. You will also see firsthand how to use the Jigsaw module system and the benefits that support for modularity on the Java platform will have on your applications.
Hypothesis and data driven development ties together current thinking about requirements, Continuous Delivery, DevOps, modern architecture, and engineering techniques to help rethink building software.
Agile development claims to abhor “Big Design Up Front”…yet what is that giant backlog building session but BDUF in other clothing? Back in the olden days of software development, we were forced to speculate on what users want, then build it. We were basically running a buffet. But what if we could switch to à la carte? With modern engineering practices like Continuous Delivery, we can shift our perspective and start building by hypothesis rather than speculation. This talk shows the full spectrum of software development, from ideation through execution and deployment, through the lens of modern software engineering practices. I discuss building a platform using feature toggles, canary releases, A/B testing, and other modern DevOps tools to allow you to run experiments to see what your users really want. By building a platform for experimentation, product development shifts from up-front guessing to market driven. This talk unifies the practices of modern architecture, DevOps, and Continuous Delivery to provide a new approach to feature development. This talk also demonstrates how to undertake major architectural restructuring with zero regression failures by relying on data and the scientific method.
Stories and lessons from architecture, design, process, and other sources, each illustrating important principles and pitfalls for modern architects.
Those who cannot remember the past are condemned to repeat it. –George Santayana
The past is never dead. It's not even past. –William Faulkner
Most developers pursue the Latest and Greatest with intense fervor, yet the history of engineering, including software projects, contains rich lessons that we risk repeating ad nauseam. This session recounts a variety of stories of projects that failed architecturally…and why. Ranging from the Vasa in 1628 to Knight Capital in 2012, each story tells of a mistaken interpretation of some architectural fundamental principle and the consequences–some good, some less so. I I also look at the common threads for these stories, which resonates with problems many companies have but don't realize.
null
An evolutionary architecture supports incremental, guided change along multiple dimensions.
For many years, software architecture was described as the “parts that are hard to change later”. But then microservices showed that if architects build evolvability into the architecture, change becomes easier. This talk, based on my upcoming book, investigates the family of software architectures that support evolutionary change, along with how to build evolvable systems. Understanding how to evolve architecture requires understanding how architectural dimensions interact; I describe how to achieve appropriate coupling between components and services. Incremental change is critical for the mechanics of evolution; I cover how to build engineering and DevOps practices to support continuous change. Uncontrolled evolution leads to undesirable side effects; I cover how fitness functions build protective, testable scaffolding around critical parts to guide the architecture as it evolves.
The software development ecosystem exists in a state of dynamic equilibrium, where any new tool, framework, or technique leads to disruption and the establishment of a new equilibrium. Predictability is impossible when the foundation architects plan against changes constantly in unexpected ways. Instead, prefer evolvability over predictability. This keynote illustrates how to achieve evolutionary architectures and how to retrofit existing systems to support better evolution.
This session covers two critical soft skills for architects:
New architects find soft skills like creating lucid documentation and building compelling presentations challenging. This presentation covers a variety of ways to document ideas in software architecture, ranging from diagramming techniques (that aren't UML) to Architecture Decisions Records and ultimately to presentations. The second part of the talk leverages patterns and anti-patterns from the Presentation Patterns book to help architects build clear and concise representations of their ideas.
You don't need Node.js or MongoDB to build “full-stack” solutions, but they sure help! This stack is popular for its scalability, its promise of developer productivity, and the capability to develop all components with a single programming language. Not all use cases are a great fit for JavaScript on the server. But love it or hate it, there are valuable lessons and use cases here for all developers.
We'll examine a complete multiuser end-to-end app using HTML5, CSS, and JavaScript. We'll connect it to a simple Node.js instance using WebSocket. We'll wire up a simple document-oriented persistence layer with MongoDB. And we'll do it all using mostly-vanilla JavaScript to illustrate concepts that don't depend on particular frameworks.
You'll leave this session convinced that full-stack JavaScript has “teeth”, and that it's not all just hype. And whether you intend to use JavaScript, Java, Ruby, or a mix of various frameworks on the server, the architecture of a dynamic HTML5 app will be made transparent and straightforward.
Web Components change the way you build web applications and think about front-end architecture. Finally, web developers have a sane way to scope and modularize not just their JavaScript, but also the HTML5 and styling. The approach is elegant, encourages compatibility between frameworks, and piggybacks on the web browser's success as an open and extensible runtime. The Polymer framework demonstrates how frameworks can and should evolve in a Web Components world.
In this session, I'll provide an overview of Polymer, and demonstrate the creation of Web Components using the framework. Data binding, true encapsulation of code and style, and dynamic HTML imports are all ready for your use. You will leave with a solid understanding of Polymer basics, and real-world examples of Polymer being used in production today. You will be able to guide your current development to better align with upcoming web standards, and to understand how they will change the way we build and deploy web applications. I'll also show you examples of a large personal project using Web Components to build an entire iOS application.
If the web browser is growing up, then Web Components are the browser leaving home. Finally.
For this workshop, you should bring a laptop with some IDE installed – Brackets (from brackets.io) works well. We'll do the rest in the session, including installing Polymer itself.
HTML5 hasn't fundamentally changed the way we build web applications — JavaScript frameworks did that. Not so with Web Components! Web Components are the most important update to HTML and the Document Object Model in recent years. They have a major impact on client-side architecture, on framework selection, and on distribution and reuse of code.
In this session, I'll explain to you the four Web Components standards, their current state, and why you should care. I'll give several examples of complex applications built in Web Components, and running in all modern browsers — including a rich mobile game.
Regular Expressions are an undervalued, underutilized tool in the developer toolbox. Few programming technologies have stood a comparable test of time for their capacity to improve developer productivity, to shortcut complex tasks, to reduce dependency on various libraries, and to encourage code reuse. They also help to teach patterns and improve pattern recognition, not only for code, but for programmers themselves. Competency with regexes will make you a better programmer, regardless of your choice of language or platforms. And it will impress your peers, too!
This workshop will teach you the fundamentals of writing, debugging, and testing PCREs (Perl-compatible Regular Expressions) in multiple programming languages. With hands-on examples we will cover regex syntax, metacharacters, assertions, grouping, quantifiers, greed, capturing, balanced matches, and replacing. We'll compose regexes from scratch to parse some common string formats such as URLs, email addresses, and even JSON. Given enough time, we'll even learn look-around assertions, and examine some creating uses of regexes in the field of natural language processing.
“There's a new JS framework every week! There's a new JavaScript feature every week! There's a new HTML5 feature every week! We are losing our minds OMG@#$HELPUS!”
Settle down everybody. Shiny new frameworks distract you from the stability offered by the web platform: ES6 is the first major update to JavaScript since 2009, and HTML5 was 18 years in the making! More importantly, few of these innovations significantly change the architecture of web applications — we owe browser innovation and frameworks for that. But since the browser evolved in to a full-blown application runtime, we now need solid front-end architecture, and front-end architects. It's not just about JavaScript, it's about the entire browser platform. And you can't pick frameworks to simplify that platform until you understand its underpinnings.
In this workshop, we will dissect the components of a modern web client into three buckets:
I'll lay the foundations to simplify the complex world of front-end tools, frameworks, and architecture. I'll share patterns to help you manage the complexity of front-end development and back-end integration for modern web clients. And I'll convince you to never again complain about how fast the world of front-end technologies is moving.
Recently, microservices have take the development community by storm. Though a modern architectural paradigm, the underlying principles of microservices are embedded across many proven traditional architectural approaches, especially modularity. At the end of the day, microservices are just one way to the increase modularity of our software system. But there are others.
In this session we will examine several different ways to modularize large software systems. We'll start with the “modular monolith” and demonstrate how this modular monolith gives us a significant degree of architectural agility to evolve the architecture to microservices by incrementally breaking pieces of the application off and deploying them as microservices.
Microservice architecture is a modern architectural approach that focuses on breaking apart the monolith and building modular services. But the framework we use has a tremendous impact on how we build and deploy services. A new type of framework has emerged that provides a lightweight stack for building microservices.
In this session, we will explore some modern Java micro frameworks for building microservices. Example frameworks you may see include Dropwizard, Spark, Ninja, RestExpress, Play, Restlet, and RestX.
This is my story of lessons learned on how to stop the crushing effects of business pressure… I was team lead with full control of our green-field project. After a year, we had continuous delivery, a beautiful clean code base, and worked directly with our customers to design the features. Then our company split in two, we were moved under different management, and I watched my project get crushed.
As a consultant, I saw the same pattern of relentless business pressure everywhere, driving one project after another into the ground. I made it my mission to help the development teams solve this problem. This is my story of lessons learned on how to transform an organization from the bottom up. I'll show you how to lead the way.
The crushing business pressure is caused by a broken feedback loop that's baked into the organization's design. In this presentation, I'll show you how to fix the broken feedback loop. Learn how to:
If the system is broken, we need to fix the system. You can change the system by making the decision to lead.
This is my story of lessons learned on why improvement efforts fail… I had a great team. We were disciplined about best practices and spent tons of time on improvements. Then I watched my team slam into a brick wall. We brought down production three times in a row, then couldn’t ship again for a year.
Despite our best efforts with CI, unit testing, design reviews, and code reviews, we lost our ability to understand the system. We thought our problems were caused by technical debt building up in the code base, but we were wrong. We failed to improve, because we didn’t solve the right problems. Eventually, we turned our project around, but with a lot of tough lessons along the way.
In this talk, we'll go through a deep-dive case study that starts with project failure, then revisit all the mistakes we made over a 3 year journey to turn the project around. We'll discuss bad assumptions, strategies that failed, ideas that changed, techniques and tools that changed, and how we eventually learned our way to victory.
After reviewing each mistake, we'll have a group discussion about the underlying reasons, so you can avoid these mistakes on your own project.
I.flow() AI is an emotional intelligence AI that learns to respond in real-time to the pain of humans, for example, developers that are having a hard time. The I.flow() AI Platform is still in the early stages of mapping theory to concrete implementation, so in this talk we'll breakdown architecture strategy, pain metrics, pair programming buddy, supply chain flows, and the underpinning of Flow theory.
Flow is an old concept, adopted into the software world by mapping Flow from Lean manufacturing. When we map a metaphor between two different domains, our brain locks onto the isomorphisms between contexts, and “Flow” becomes stickies flowing on a whiteboard, or features flowing out to customers. It becomes difficult to see Flow any other way.
What if our object-oriented blinders led to an object-oriented notion of Flow, and there's a totally different way to look at the system? Flow, at it's core, is a paradigm shift, a metaphorical lens, that helps us see, understand, and predict the behavior of any Flow System. Better predictive models, enables AI automation like we've never had before. It's about time we started applying AI to our own problems.
In this session, we'll use I.flow() AI as a metaphorical lens to explore the world of philosophy.
Each one of us is on a journey to discover who we are, why we're here, and what it all means. I.flow() Emotional Intelligence AI evolved as a result of deep self-reflection, in the search for an authentic self, and the courage to live an authentic life.
“I.choose() therefore I.am()”
This session is a collection of life reflections and lessons learned, codified into diagrams and code abstractions using I.flow() AI. We'll start with the assumption that life is a video game, and humans are the AI. We'll break down models for human relationships, different ways of being in the world, and discuss the meaning of the game of life.
If you are someone that delights in a great philosophical discussion over dinner, you won't want to miss this talk.
It happens to us all; there are simply days where it seems impossible to get anything done. This session focuses on techniques and tips to get into the zone, stay in the zone and to protect your productivity, even in disruptive environments.
Rather than focusing on any one productivity methodology (e.g. GTD) This talk analyzes the internal and external factors that affect our productivity and offers broader strategies to get back on track.
With the explosion of new frameworks, a mountain of automation, and our applications distributed across hundreds of services in the cloud, the level of complexity in our industry is growing at an insane pace. With increased complexity comes increased costs and risks. When diagnosing unexpected behavior can take days, weeks, or sometimes months, all while our release is on the line, our projects plunge into chaos. In the invisible world of software development, how do we identify what's causing our pain? How do we escape the chaos?
Janelle Klein presents a novel approach to measuring the chaos, identifying the causes, and systematically driving improvement with a data-driven feedback loop. Rather than measuring the problems in the code, Janelle suggests measuring the “friction in Idea Flow”, the time it takes a developer to diagnose and resolve unexpected confusion, which disrupts the flow of progress during development.
With visibility of the symptoms, we can identify the cause, whether it's bad architecture, collaboration problems, or technical debt. Janelle discusses how to measure Idea Flow, why it matters, and the implications for our teams, our organizations, and our industry.
In this session we will take a look at building applications with Angular. We will build a very simple application from the ground up, and attempt to understand the approach of Angular, as well as understand some of the terminology that Angular introduces.
This session will focus on the Angular 10
TypeScript, Components, Annotations/Directives, Observables, Reactive Stores, Model-Driven forms … Oh my! Angular, much like AngularJs (1.x.x), despite being a powerful platform for building rich client side applications, comes laden with both new terminology, and a “newer” approach to writing client side code.
In this session, as we build a simple application, we will attempt to tease apart these concepts, slowly building our understanding towards how these pieces come together, and how we can leverage them to build rich client side application.
Details
angular-cli
generatesAlong the way we will see how to use the Angular style guide to follow conventions adopted by the Angular community at large, and some ways to use the angular-cli
tool.
In this session we will take a look at building applications with Angular. We will build a very simple application from the ground up, and attempt to understand the approach of Angular, as well as understand some of the terminology that Angular introduces.
This session will focus on the Angular 10
TypeScript, Components, Annotations/Directives, Observables, Reactive Stores, Model-Driven forms … Oh my! Angular, much like AngularJs (1.x.x), despite being a powerful platform for building rich client side applications, comes laden with both new terminology, and a “newer” approach to writing client side code.
In this session, as we build a simple application, we will attempt to tease apart these concepts, slowly building our understanding towards how these pieces come together, and how we can leverage them to build rich client side application.
Details
pipes
in AngularAlong the way we will see how to use the Angular style guide to follow conventions adopted by the Angular community at large, and some ways to use the angular-cli
tool
Functional programming (FP) is fast becoming the tool that programmers reach for in this era of multi-core processors. Although the definition of “functional” varies quite a bit between implementations, there are a few facets that remain core and true to the paradigm. Facets such as functions as first-class, higher order functions, closures etc. In this session we will explore the meaning of these using JavaScript as our medium.
Why JavaScript? The answer in short is: omnipresence. The long answer is that hiding at the core of JavaScript is a language that is not only beautiful and elegant, but one that supports many of the core ideas in FP. If you are interested in what the fuss is all about, or are confused about some of the concepts that make FP a reality, then this is the session you should attend.
In today's world, our applications need to be both responsive, fast and scalable. Our applications need to respond to user interactions such as mouse movements, clicks and inputs as well as asynchronous inputs like XHR calls, server sent events, setInterval, even web socket events! Unfortunately as things stand today, there is no consistent way to deal with the myriad of different “changes” that could happen in an application.
But what if there is? This is what Reactive Extensions (specifially RxJs in this session) allow us to do. It offers us an abstraction that allows us to treat everything from DOM events (infinite streams) to our domain (map
s, set
s and array
s) as streams. This consistent interface now permits us to create and manipulate any source identically. Futhermore, it allows us to react to different sources as if they are one!
Reactive Extensions are fast becoming the de-facto approach of managing asynchronicity in JS land. From Netflix's UI to Angular 2 $http
to ES7 - reactive programming is everywhere!
This session is RxJs 101, covering
If we have time we will look at a simple demo, and reactive progamming's role in Angular 2
In this session we will get acquainted with Docker. We will discuss what docker is, how to install it, and how to start using Docker. We will also explore some of the benefits of containerizing your applications.
Containers are taking over the world. Containers provide a means to have hermatic builds of your software, allowing for truly immutable testing, and delivery of your software. Docker is one of many containerization technologies, and in this session we will take a brief look at Docker and what it has to offer.
Reactive Programming in gaining a lot of excitement. Many libraries, tools, and frameworks are beginning to make use of reactive libraries. Besides, applications dealing with big data or high frequency data can benefit from this programming paradigm. Come to this presentation to learn about what reactive programming is, what kind of problems it solves, how it solves them. We will take an example oriented approach to learning the programming model and the abstraction.
Reactive Programming
Nature of Problems
Programming API
The Reactive Programming Abstraction
Examples
Distributed and parallel computing have been around for a while. The problem is not new, but solutions have generally been complex. Over the years several solutions have come along to ease the pain. Spark is a wonderful programming API and a tool that can ease the pain of creating distributed, high concurrent, performing code.
In this presentation we will take an example oriented approach to creating applications that make use of Spark. We will learn how to create the code to use Spark, how to configure and manage the number of threads, and how to distribute the computations.
Java 8 is the most significant change to the language since it's introduction, surpassing changes seen in any of the previous versions. It is not merely syntactical change or addition of a few extra features, it's a paradigm shift. Come to this presentation to learn about the power and capabilities of functional programming using Java 8 and how to benefit from those when building Java applications.
Lambda Expressions
A Look under the hood
Stream
Functional Programming Principles Applied
Function Pipeline
Lazy Evaluations
Parallel Streams
Life is full of choices and the choices are full of tradeoffs. One such choice is which client side technology to use: React or Angular 2? This presentation will not decide that for you, but it will provide you with enough details so you can make that decision for your applications.
This presentation has three parts. A short introduction to React along with key capabilities and limitations. A short introduction to Angular 2 along with key key capabilities and limitations. Finally, a comparison and a list of things to consider in choosing one over the other.
Turning a stream into a parallel stream is extremely easy, but is that the prudent thing to do? While flipping that switch is almost effortless there are some significant ramifications. In this presentation we will learn the power of parallel streams but also why, when, and where it makes sense to use parallel streams. Through a series of example we will learn about cases where it makes sense and some there it does not.
Streams
Parallel Streams
Controlling Threads
Deciding Threads
Performance Implications
Recommendations on prudent use
By the end of this conference you will have learned many new tools and technologies. The easy part is done, now for the hard part: getting the rest of the teamand managementon board with the new ideas. Easier said than done.
Whether you want to effect culture change in your organization, lead the transition toward a new technology, or are simply asking for better tools; you must first understand that having a “good idea” is just the beginning. How can you dramatically increase your odds of success?
You will learn 12 concrete strategies to build consensus within your team as well as 6 technique to dramatically increase the odds that the other person will say “Yes” to your requests.
As a professional mentalist, Michael has been a student of psychology, human behavior and the principles of influence for nearly two decades. There are universal principles of influence that neccessary to both understand and leverage if you want to be more effective leader of change in your organization.
In this session we discuss strategies for getting your team on board as well as when/how to approach management within the department and also higherup in the organization.
In Part 1, you learned the core principles of influence and persuasion. How to we take this back to the office and apply what we've learned?
We dive deep in to specific strategies to get both the team and the business on board with your ideas and solutions. We cover several realworld patterns you can follow to be more effective and more persuasive. Part 1 was conceptual, part 2 is practical.
As a developer, your focus was squarely on the “functional requirements” aka the business capabilities your application must meet. But once you step in the architect role, you discover a world inhabited by “the ilities” otherwise known as the non functional or quality attributes of a software system. But how do we know which ilities matter and which ones don't? And much as we may want to turn every knob up to 11, many ilities are inversely related - maximize one and you by definition minimize another.
In this talk we will look at various architectural problems giving participants opportunities to try and balance non functional requirements. We'll discuss the consequences of various approaches as well as how we can best document the inevitable decisions we arrive at.
Today you can't swing a dry erase marker without hitting someone talking about “the cloud”. From the CIO to the project room, the cloud is bound to be a topic of conversation. While there is no denying the buzz worthiness of the term, you probably should take a deep breathe before declaring your entire portfolio will be cloud native by the end of the year. In this talk, I will discuss a practical way of assessing your applications and how to create a thoughtful plan to move applications to the cloud - when it makes sense.
We'll talk about what factors to consider when surveying an application, why some systems shouldn't go to the cloud and what else you need to consider beyond the basics of picking a cloud vendor. Cloud based deployments have tremendous benefits to today's organizations - but as with any new technology, it must be introduced with care.
Machine Learning is a huge, deep field. Come get a head start on how you can learn about how machines learn.
This talk will be an overview of the Machine Learning field. We’ll cover the various tools and techniques that are available to you to solve complex, data-driven problems. We’ll walk through the algorithms and apply them to some real but accessible problems so you can see them at work.
Documents contain a lot of information. We'll introduce you to a variety of techniques to extract them.
Machine Learning techniques are useful for analyzing numeric data, but they can also be useful for classifying text, extracting content and more. We will discuss a variety of open source tools for extracting the content, identifying elements and structure and analyzing the text can be used in distributed, microservice-friendly ways.
This open source machine learning framework from Google has taken off. Come learn what you can do with it in your own organization.
TensorFlow is a powerful data flow-oriented machine learning framework developed by Google's Brain Team. It was designed to be easy to use and widely applicable on both numeric, neural network-oriented problems as well as other domains. We'll cover the over view as well as apply it to several fun, realistic problems.
What happens if web applications got really fast?
We are increasingly able to do more in the browser because of faster networks, optimized JavaScript engines, new standard APIs and more. There is a new initiative to allow a binary format called WebAssembly that will provide a compiled, cross-platform representation that will take us to the next level. Complex business applications and 3D video games will alike will benefit from this new standard. Come hear about what it can do for you.
At some point, graphics cards became serious business computationally. We'll explore why and how this switch has happened.
The most basic introduction to computers spells it out: software runs on the CPU. At some point, this became not entirely true. Graphics cards now support general purpose computing via apis such as CUDA and OpenCL. This talk will introduce you to how and why you can take advantage of these capabilities for a wide variety of applications. Moore's Law may have petered out, but we have plenty of other ways to make our applications run faster.
This session compares Service-oriented, Service-based, and Micro-service architectures, describing the problem each is designed to solve, differences and similarities, variants and hybrids, and engineering practices.
Microservice architectures are quite popular, described as “SOA done correctly”. But what are the real differences between SOA, Microservice, and service-based architectures? What about middle ground between the shared everything of SOA versus shared nothing of microservices? This talk explores the similarities and differences between various service-oriented architectural styles. I describe the characteristics of SOA, microservices, and hybrid service-based architectures, along with the considerations and constraints for each. I also discuss specific engineering practices, orchestration styles, reuse strategies, and migrating from monolithic applications to service-based or microservice architectures. No one architecture can solve every problem, and many projects take on more complexity than necessary by choosing the wrong paradigm.
For the last several years, the JavaScript world has been awash in various Model-View-Whatever frameworks and libraries with new implementations popping up like bunnies. With the popular React library, Facebook took a different approach to developing JavaScript user interfaces by focusing on the View in MV*. This talk will get you up and running on React, a library that gives us a declarative approach to designing highly performant interactive user interfaces. We'll dive into the basics of components, JSX, the virtual DOM and more. By the end of this session you'll have a solid foundation in what React brings to the table and how it might help you on your next project.
For the last several years, the JavaScript world has been awash in various Model-View-Whatever frameworks and libraries with new implementations popping up like bunnies. With the popular React library, Facebook took a different approach to developing JavaScript user interfaces by focusing on the View in MV*. This talk will get you up and running on React, a library that gives us a declarative approach to designing highly performant interactive user interfaces. We'll dive into the basics of components, JSX, the virtual DOM and more. By the end of this session you'll have a solid foundation in what React brings to the table and how it might help you on your next project.
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.
With the advancement of AI, the paradigm shift of blockchain, the media war for the Internet, and escalating emotion, it's time to explore brand new territory – using software as a metaphor to construct a functional model of the human mind. Imagine your brain's logic is written in code. You fire up the debugger, set a breakpoint in the “Self” class, and inspect your brain's internal state. What are the state variables? What does the code look like? How do we fix the bugs?
I.flow() is a theory of consciousness that models motivation behavior of humans using software as a metaphor, because… why not? From the origin of gut feel reasoning, to the feedback loops that drive you, we'll breakdown the functional architecture that makes the universe tick.
I.flow() is the underpinning theory behind MetaOS, the generalized AI platform being pioneered by Open Mastery. In an age where everything is changing faster than ever, and the magic of sci-fi novels is coming to life – we're faced with some of the most difficult questions about what it means to be human:
Who am I? What do I live for? What is the purpose of life?
“I.choose() therefore I.am()”
Since the dawn of software development, we've struggled with a huge disconnect between the management world and the engineering world – the clash of top-down control, money, and economics, versus art, freedom, working with our friends, and bringing awesome creations to life.
Overcoming these challenges in our industry requires a huge paradigm shift – rather than building organizations as money-making machines with top-down control, our organizations need to become thinking, feeling, interconnected social organisms, where our humanity isn't boiled down to a few numbers.
How do we shift the paradigm of the organization, to bridge these two worlds together? The short answer – with the help of software.
By measuring the friction in a developer's Flow, we have a data-driven feedback loop for personal improvement. What if we measure Flow across the team? Across team dependencies? Across the organization?
What would it take to build an organizational operating system, that uses our past experience and lessons learned as the foundation for an intelligent hive mind, that helps everyone in the organization make better decisions? What if we codified our organizational ideals into the business accounting rules of the software, then sold it as the “the next big thing” in the industry?
At the end of the day, business is a game. If we take responsibility for making up the rules, we can redefine the game we wish to play. In this session, we'll discuss a potential future for our industry, where we design the organizational operating system that runs the world.
For the last 20-30 years, there has been a never-ending set of solutions for building cross-platform desktop applications. Most of them suck. Electron is one that doesn't.
It is a new solution that forms the basis of the Atom Editor, Microsoft's Visual Studio Code, the Slack app and more.
Come see what happens when you combine the best of the Web, Node.js and Chromium to provide attractive, modern, flexible, useful, consistent cross-platform desktop applications.
Electron grew out of the work on the Atom Editor from GitHub. Developers familiar with JavaScript, Node and Web Development will be comfortable with an engine that uses the same technologies as they move to the Desktop. At the same time, the Chromium engine, which has support for modern technologies such as WebGL, WebRTC and desktop-integration hooks, as well as HTML 5 and CSS, rounds out the platform. The strength of the Web mixed with native desktop integration hooks and the performance and flexibility of Node strikes the right balance for avoiding sucky cross-platform applications.
We all have seen our share of bad code and some really good code as well. What are some of the common anti patterns that seem to be recurring over and over in code that sucks? By learning about these code smells and avoiding them, we can greatly help make our code better.
Come to this talk to learn about some common code smell and to share your experiences as well.
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.
In this session we will dive deeper into Dockerfiles. We will explore the DSL that Dockerfiles provide to allow for the automation of image creation.
Dockerfiles provide a means to automate the creation of images, and consequently the containers within which our applications run. The Dockerfile, though minimal, provides us with everything we need to package our software, and enable it to run. In this session we will dive deep into the Docker DSL, and explore the many commands that it provides, and along the way explore some differences between similar commands, and some gotchas.