Architecture has lots of difficult problems, many revolving around modularity and granularity. This session delves into many of the hard parts in architecture and makes many of the problems softer.
Architects often look harried and worried because they have no clean, easy decisions: everything is an awful tradeoff. Architecture has lots of difficult problems, which this talk highlights by investigating what makes architecture so hard. At the of core many architectural problems: getting good granularity, which we illustrate via event-driven architectures, teams, components, architectural quantum, and a host of other examples. We also illustrate reuse at the application, department, and enterprise level, and why /reuse/ seems simple but isn't. We also discuss difficult decisions, how to do tradeoff analysis, tools like MECE lists, and how to decouple services to achieve proper granularity. Architecture is full of hard parts; by tracing the common reasons and applying lessons more universally, we can make it softer.
This session describes how architects can identify architectural characteristics from a variety of sources, how to distinguish architectural characteristics from domain requirements, and how to build protection mechanisms around key characteristics. This session also describe a variety of tradeoff analysis techniques for architects, to try to best balance all the competing concerns on software projects.
Architects must translate domain requirements, external constraints, speculative popularity, and a host of other factors to determine the key characteristics of a software system: performance, scale, elasticity, and so on. Yet architects must also analyze the tradeoffs each characteristics entails, arriving at a design that manages to maximize as many beneficial properties as possible. This session describes how architects can identify architectural characteristics from a variety of sources, how to distinguish architectural characteristics from domain requirements, and how to build protection mechanisms around key characteristics. This session also describe a variety of tradeoff analysis techniques for architects, to try to best balance all the competing concerns on software projects.
This session covers basic application and distributed architectural styles, analyzed along several dimensions (type of partitioning, families of architectural characteristics, and so on).
A key building block for burgeoning software architects is understanding and applying software architecture styles and patterns. This session covers basic application and distributed architectural styles, analyzed along several dimensions (type of partitioning, families of architectural characteristics, and so on). It also provides attendees with understanding and criteria to judge the applicability of a problem domain to an architectural style.
Java is a language in evolution. There are a handful of language changes in Java 9 and 10 plus several JDK changes in 9, 10, 11, and 12. Some of these changes are significant in that they allow us to do things more effectively than before. The difference can be anywhere from reducing code to avoiding errors that come from verbosity. In this presentation we will explore the language changes first. Then we will visit the additions to the JDK. Along the way we will also look at a few things that have been removed from Java as well.
We will program with Java quite differently in the future than we do today. The reason is that Java is embracing asynchronous programming like never before. This will have a huge impact on how we create services and web applications. In this presentations we will look at what asynchronous programming is, what continuations are, how they get implemented under the hood, and how we can benefit from them.
Java Modules are the future. However, our enterprise applications have legacy code, a lots of it. How in the world do we migrate from the old to the new? What are some of the challenges. In this presentation we will start with an introduction to modules and learn how to create them. Then we will dive into the differences between unnamed modules, automatic modules, and explicit modules. After that we will discuss some key limitations of modules, things that may surprise your developers if they're not aware of. Finally we will discuss how to migrate current applications to use modules.
So you have some code and it is in a bounded context with a REST API. You are on your way to Microservices. Next you wrap it in a container and now it is an image that others can run. Simple. Now what? No service is an island. Your service needs to log information, needs to scale and load balance between its clones. Your service needs environment and metadata way outside its context. What about where the service will run? Who starts it? What monitors its health? What about antifragility? Updates? Networking? Oh my.
Services live in clusters and clusters live in data centers. Many concepts overlap with the features of cloud management. But don't get too flustered since, fundamentally, services are managed by clusters. There are several approaches to cluster management such as Docker Swarm, Mesos with Marathon and Kubernetes.
Minikube with Kubernetes is an approachable technique to set up a local cluster that is easy to understand and get started. Whether you have a simple service or a Web application with a set of services, you can develop much of it on Kubernetes with Minikube. We will run some practical examples. Once you understand the mechanics of the tools, we will explore how it works, sort through the terminology and share ideas about practical uses for this technology.
Afterward, you will understand how to run your personal cluster with your Linux, OS X or Windows laptop to further enjoy unraveling the mysteries of running applications in a cluster.
Prerequisite: If you are unfamiliar with Kubernetes be sure to attend: Understanding Kubernetes: Fundamentals
Aha moments with apps in containers can be quite liberating. The mobile space is saturated with “there's an app for that”. For us, we now expect “there's a container for that”. “Write once, run anywhere” (WORA) has changed to “Package once, run anywhere” (PORA). As the community of containers and flavors is riding up the hype curve we will look at some of those top aha moments together.
• Go rouge with Java 9 and jlink • Polyglot microservices • RabbitMQ broker in 1 minute • Private Docker hub in a container • Kubernetes, it’s all containers • database flavors for integration testing • R engine in 30 seconds • Tomcat with a war, in a container
The epiphanies are in the simplicity. Leveraging namespaces and using cgroups, these apps share a common kernel without polluting the host OS. This eliminates installation, conflicts and uninstalls. The barriers to getting something running are decreased and normalized to a container run command. This is subtly powerful and liberating. With this simplicity comes complexity such as shared resources, file systems, mounts, networking and overall cluster management.
As an example we will peruse the heart of this, the Dockerfile. See how containers can be stacked on top of base images. We will explore the syntax, optimization, tips, best practices and some tricky points such as the difference between CMD and Entrypoint.
Your software package delivery and installation is no longer an rpm, deb, dmg, jar, war, native executable or a run script, it is simply an image that has a common run container command. Liberating.
Lastly we will explore how containers can help and hurt your team if you are not careful. What goes into a container is a reflection of a team's skills. Should a team make each tech stack different, or should you standardize? External processes affect your tech stack choices inside your container such as static code analysis, code beautifiers, CI/CD, tracing, logging and monitoring. Exercise caution as standardization and frameworks can lead to coupling. Your tech stack details can change from version to version so get your SemVer and API versioning right. Finally, containers can be a vehicle to introduce new technologies to those that are conservative and risk avoiders.
The end of the presentation will explore containers driven from this source.
Prerequisite: If you are unfamiliar with Kubernetes be sure to attend: Understanding Kubernetes: Fundamentals.
Highly cohesive and loosely coupled business functions can have a great impact on your agility to deliver new features. Microservices in containers is an effective implementation detail for continuous delivery. However, before you bite into that big sandwich, consider how provisioning a variety of data flavors as containerized endpoints could greatly improve your internal testing.
How many times have you heard a colleague say, “Well that feature does not have integration tests because it requires a database with some specialized data”? Balderdash - put your data flavors in containers!
Let's explore a solution to create a pipeline of data flavors. We use Docker images, Kubernetes Pods, Minikube to provision these endpoints. See how a Gradle project drives integration tests against these Pod endpoints, all ready for your continuous integration pipeline. In the end you can see the power of Consumer Driven Contracts against your dataset flavors.
Watch how your team becomes empowered to create their own dataset flavors in containers for development and testing. See a wall to integration testing come down.
We will explore a GitHub Gradle-based project that includes:
This presentation will follow the source code found here.
Would Chuck Norris ask you to come hear him speak at a conference? No, he wouldn't. He would TELL you that you're coming, and then roundhouse kick you in the face if you gave him any more lip.
“What would Chuck Norris do?” is a philosophy this session will cover in depth. Other topics include: badass vs a-hole, human duck typing, the art of [not] caring, instrumentality, and what your facial hair says about you. You won't learn any new code in this session, but you might unleash a Pandora's box of awesomeness that will change the way you interact with your coworkers forever.
This is the droid you are looking for. The term “static code analysis” is a seemingly boring term for tools that harden your product and advance your team's engineering prowess. Within this droid are hundreds of rules designed to review your code for defects, hotspots and security weaknesses. Consider the resulting analysis as humble feedback from a personal advisor. The rules come from your community of peers, all designed to save your butt.
We will explore techniques on how to add these checks to your IDE, your build scripts and your build pipelines.
Discover how prerequisite checks made before your commits can help cut down on the chatter in your pull requests. See how the analysis teaches best practices, without ego or criticism, to a spectrum of developers. As a leader see how to develop an effective code quality intern program around this technique. We will see techniques on how Kubernetes is an effective way to obtain reports and dashboards right on your local machine and from your continuous integration pipeline.
Some practical uses of Kubernetes, Helm charts and SonarQube will be discovered in parallel to this topic.
Prerequisite: If you are unfamiliar with Kubernetes be sure to attend: Understanding Kubernetes: Fundamentals
From operating system on bare metal, to virtual machines on hypervisors, to containers orchestration platforms. How we run our code and bundle our applications continues to evolve. Serverless computing continuous our evolutionary path for our architectures..
See how Kubernetes provides a vendor agnostic solution for serverless computing using the Kubeless project.
Serverless promises to developers that they can worry less about the cluster and focus more on their logic. Based on your Kubernetes knowledge we will discover how two open source serverless frameworks, Kubeless and OpenFaaS, leverage Kubernetes. The recent addition of Knative is shaking things up. We will explore what Knative is bringing to the table and how the serverless landscape is evolving.
Kubernetes out of the box is a strong platform for running and coordinating large collections of services, containers, and applications. As is, Kubernetes is powerful for many solutions.
Remember Underdog? He was a mild-mannered dog, but when stress and conflict were introduced to the plot he took a magic pill, he became a superhero. Istio is a superhero for Kubernetes.
Istio is an open, platform-independent service mesh that manages communications between services in a transparent way. With a distributed architecture many things can fail, slow down and become less secure. Istio provides solutions to those stresses in our plot toward this architecture style:
• Traffic management
• Policy enforcement
• Service identity and security
We will explore these benefits with Istio through some working examples on Kubernetes. The key point is this meshing solution allows your code to be less coupled to the inherent weaknesses of a distributed platform.
Since the dawn of software development, we've struggled with a huge disconnect between the management world and the engineering world. We try to explain our problems in terms of “technical debt”, but somehow the message seems to get lost in translation, and we drive our projects into the ground, over and over again.
What if we could detect the earliest indicators of a project going off the rails, and had data to convince management to take action? What if we could bridge this communication gap once and for all?
In this session, we'll focus on a key paradigm shift for how we can measure the human factors in software development, and translate the “friction” we experience into explicit risk models for project decision-making.
How does your team decide what's the most important problem to solve?
When we ask a question like “what's the biggest problem?“, it doesn't mean the biggest problems will come to mind. Instead, we're biased to think about what's bothered us most recently, annoyances, or pet peeves. It's really easy to spend tons of time working on improvements that make little difference.
But what if we had data that pointed us to the biggest problems across the team?
In this session, we'll dig into the data from a 1-month case study tracking Idea Flow Metrics, and discuss the patterns of friction during development, and how to identify the biggest opportunities for improvement with data.
What makes software development complex isn't the code, it's the humans. The most effective way to improve our capabilities as an organization is to better understand ourselves.
In this session, we'll breakdown the dynamics of culture into explicit architecture models based on a synthesis of research that spans cognitive science, biology and philosophy. We'll discuss the nature of Identity, communication, relationships, leadership and human motivation by thinking about humans like code!
If you want to better understand the crazy humans around you, you won't want to miss this talk!
Angular 7 is a big jump for the entire platform, but what does it mean for you?
In this session we’ll explore the things you couldn’t do before by diving into changes in the core framework, Angular Material, and the CLI. We’ll discuss other improvements to the framework and why they might matter to you. We’ll upgrade an Angular 6 application and add some new features to it. And if you’ve stepped away from Angular for a while, you might be surprised at how easy it is to pick it back up.
Microservices have helped us break apart back end services, but large front ends often remain problematic monoliths.
In this session you’ll learn how to apply the same concepts to large front-end applications, slicing them into end-to-end verticals. These verticals can then be owned by different teams and even written in different frameworks. Can Angular, React, and Vue all live together in harmony? How about AngularJS and Angular2+? With micro frontends, the answer is yes!
Git. It can be intimidating if you're accustomed to other kinds of source control management. Even if you're already using it and comfortable with the basics, situations can arise where you wish you understood it better. Developers often just want to write code and tell everyone else to take a hike, but the reality is that most of us work on teams where the feature-based code we write must be integrated, tested, and ultimately released.
This session will cover the most critical git concepts, basic and advanced, in a completely visualized way. At the same time, you’ll pick up git terminal commands to help you understand (or even eliminate) a git GUI you already use. Go beyond the basics to learn how to get yourself out of a git pickle, practical release management strategies, and more.
Patterns/antipatterns, techniques, engineering practices, and other details showing how to restructure existing architectures and migrate from one architecture style to another.
A common challenge facing many architects today involves restructuring their current architecture or migrating from one architectural style to another. For example, many companies start with monolithic applications for simplicity, but find they must migrate it to another architecture to achieve different architectural characteristics. This session shows patterns/antipatterns, techniques, engineering practices, and other details showing how to make major changes to architectures. This session introduces a new measure, the architectural quantum, as a way of measuring and analyzing coupling and portability within architectures.
In the world of legacy code, we often end up inheriting a tangled ball of mess with a lack of automation, and no clear surfaces for testing. Yet still, under these circumstances, we're expected to safely make changes without regressions. Where do we start? How do we tackle this challenge? How do we get a handle on re-architecture?
We'll start this discussion with a first-hand use case and example – tackling the re-architecture of an 800k line JBoss application with near-zero unit tests. Ugh. The only option on the table was Selenium. UGH.
Let's talk about alternative strategies. How have you tackled similar situations? How could we build a data-driven regression framework without going through the UI?
This session will be 70% discussion, focused on the challenges you've faced in test harnessing legacy code. Be ready to share the story of a challenge your facing, or help out your fellow attendees with advice.
We'll discuss the strategies used to conquer the challenge in this case study, and how you could apply the same pattern to your own projects.
Take a moment and think about all the knowledge held by the brains in your organization. There's knowledge about how the software works, how the business works, and decades of experience with mistakes, and lessons learned.
How do we share this wisdom between brains? How do you get an idea from your head into someone else head, when there's no words to easily describe what you mean? Much of this knowledge is tacit knowledge, and not the easiest thing to share.
In this session, we'll use a synthesis of research from cognitive science to discuss how brains “make sense” of information, and strategies and philosophy around effective mentorship.
If you want to raise the bar on your teams, or build a mentorship culture at your company, you won't want to miss this talk.
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.
In this session, we'll explore the Spring Boot Actuator, a runtime component of Spring Boot that lets you peer inside a running application and, in some cases, even tweak configuration on the fly. We'll look at many of the Actuator's endpoints, learn how to customize and even create new endpoints, and see how to expose Actuator metrics to several popular instrumentation and monitoring systems.
Spring Boot makes developing applications with Spring easy work by offering auto-configuration for many common application scenarios. And with Spring Boot's starter dependencies, even an application's build file can be easily managed. But Spring Boot's powers don't end when the application is deployed. That's where the real fun begins.
In this example-driven presentation, we'll look at Spring Data REST, an extension to Spring Data that exposes your data repositories as a RESTful API, complete with hypermedia links. We'll start with essential Spring Data REST, but then go beyond the basics to see how to customize the resulting API to be more than just CRUD operations over HTTP.
In this session, we'll explore Spring Security and OAuth2, including building an OAuth2 authorization server, fronting an API with a resource server, and verifying an OAuth2 access token's claims to ensure that the client is allowed to access the resource they are asking for.
OAuth2 offers a means by which a client application can request authorization to access a resource and be given an access token that must be presenting when making HTTP requests. This involves creating an authorization server that issues tokens and defining a resource server which acts as a wall around an API that verifies the presented access token's claims before allowing the request to proceed.
Spring Security has historically supported OAuth2 as part of a separate project called Spring Security for OAuth. But gradually, Spring's OAuth2 support is moving into the main Spring Security project.
Some developers simply hate type inference. And then there others who love it. Neither one of them is entirely right. In Java we have been making extensive use of type inference for several years without realizing it. The introduction of “var” in Java 10 has stirred up some surprising debate. In this presentation we will step back and review type inference in Java. Then we will dive deep into type inference in Java 10 and 11. We will wrap up the presentation will good recommendations on when to use type inference and when to avoid it.
Functional style of programming was introduced in Java 8. Many organizations are still transitioning to Java 8 and more so, embracing the functional style. If you are like the speaker, who spent decades on imperative style, then the transition to functional style can be intimidating. In this presentation we will learn about the fundamentals of programming in functional style, the set of tools that we can reach into to solve problems as a series of state transformation. We will learn the how but also the benefits along the way as well.
In this example-driven session, we'll explore the Alexa Skills Kit (ASK) and see how to develop skills for Amazon's Alexa. You'll learn how to use the ASK CLI to jumpstart skill development and how to create conversational applications in NodeJS.
The way we communicate with our applications is an ever-evolving experience. Punch cards gave way to keyboards. Typing on keyboards was then supplemented by pointing and clicking with a mouse. And touch screens on our phones, tablets, and computers are now a common means of communicating with applications.
These all lack one thing, however: They aren’t natural.
As humans, we often communicate with each other through speech. If you were to walk up to another human and start tapping them, you’d likely be tapped (or punched) in response. But when we talk to our applications, we communicate on the machine’s terms, with keyboards, mice, and touch screens. Even though we may use these same devices to communicate with other humans, it’s really the machine we are communicating with—and those machines relay what we type, click, and tap to another human using a similar device.
Voice user-interfaces (Voice UIs) enable us to communicate with our application in a human way. They give our applications the means to communicate to us on our terms, using voice. With a voice UI, we can converse with our applications in much the same way we might talk with our friends.
Voice UIs are truly the next logical step in the evolution of human-computer interaction. And this evolutionary step is long overdue. For as long as most of us can remember, science fiction has promised us the ability to talk to our computers. The robot from Lost in Space, the Enterprise computer on Star Trek, Iron Man’s Jarvis, and HAL 9000 (okay, maybe a bad example) are just a few well-recognized examples of science fiction promising a future where humans and computers would talk to each other.
Our computers are far more powerful today than the writers of science fiction would have imagined. And the tablet that Captain Picard used in his ready room on Star Trek: The Next Generation is now available with the iPad and other tablet devices. But only recently have voice assistants such as Alexa and Google Assistant given us the talking computer promised to us by science-fiction.
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 real-world patterns you can follow to be more effective and more persuasive. Part 1 was conceptual, part 2 is practical.
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 team-and management-on 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 higher-up in the organization.
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.
What comes after machine learning and deep learning? How about dynamic systems that need new ways of finding paths through complex scenarios such as video games, challenging board games and more.
In addition to covering the main ideas of deep reinforcement learning, we will cover some of the main tools and frameworks
Deep Learning is an evolution of the capabilities of more conventional machine learning to take advantage of the extra data available from Big Data systems. With more data, many of the manual aspects of feature selection and other machine learning steps can be derived automatically. We will highlight many of the main deep learning frameworks and give you a hands on introduction to what is possible and how you can start to use them.
We will cover:
Everyone knows security is important. Very few organizations have a robust and comprehensive sense of whose responsibility it is, however. The consequence is that they have duct-tapped systems and a Policy of Hope that there will be no issues. (Spoiler: there will be)
We will review the various roles that most organizations need to fill and how they overlap as well as what should and can be expected from each of them.
These days, you can’t swing a dry erase marker without hitting someone talking about microservices. Developers are studying Eric Evan’s prescient book Domain Driven Design. Teams are refactoring monolithic apps, looking for bounded contexts and defining a ubiquitous language. And while there have been countless articles, videos, and talks to help you convert to microservices, few have spent any appreciable time asking if a given application should be a microservice. In this talk, I will show you a set of factors you can apply to help you decide if something deserves to be a microservice or not. We’ll also look at what we need to do to maintain a healthy micro(services)biome.
There are many good reasons to use a microservices architecture. But there are no free lunches. The positives of microservices come with added complexity. Teams should happily take on that complexity…provided the application in question benefits from the upside of microservices. This talk will cut through the hype to help you make the right choice for your unique situation.
Every organization has at least a phalanx or two in the “Cloud” and it is, understandably changing the way we architect our systems. But your application portfolio is full of “heritage” systems that hail from the time before everything was as a service. Not all of those applications will make it to the valley beyond, how do you grapple with your legacy portfolio? This talk will explore the strategies, tools and techniques you can apply as you evolve towards a cloud native future.
In this talk, you will learn:
If you’ve spent any amount of time in the software field, you’ve undoubtably found yourself in a (potentially heated) discussion about the merits of one technology, language or framework versus another. And while you may have enjoyed the technical debate, as software professionals, we owe it to our customers (as well as our future selves) to make good decisions when it comes to picking one technology over another.
In this talk, I will explore what criteria we should consider when comparing technologies, how we can avoid burning platforms as well as what to do when we’ve reached a dead end. We will also apply these techniques to a current technology or two.
In this talk I will explore various options you can deploy on your projects to tame the mass of code that lives on the front end of our applications. From NPM to Gulp to Webpack, this talk will help you establish a front end pipeline.
By now I bet your company has hundreds, maybe thousands of services, heck you might even consider some of them micro is stature! And while many organizations have plowed headlong down this particular architectural path, your spidey sense might be tingling…how do we keep this ecosystem healthy?
In this talk, I will go beyond the buzzwords into the nitty gritty of actually succeeding with a service based architecture. We will cover the principles and practices that will make sure your systems are stable and resilient while allowing you to get a decent night's sleep!
Creating code is easy, creating good code takes a lot of time, effort, discipline, and commitment. The code we create are truly the manifestations of our designs. Creating a lightweight design can help make the code more extensible and reusable.
In this presentation we will take an example oriented approach to look at some core design principles that can help us create better design and more maintainable code.
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.
This session describes mechanisms to automate architectural governance at application, integration, and enterprise levels
A nagging problem for architects is the ability to enforce the governance policies they create. Yet, outside of architecture review boards or code reviews, how can architects be sure that developers utilize their rules? This session describes mechanisms to automate architectural governance at application, integration, and enterprise levels. By focusing on fitness functions, architects define objective tests, metrics, and other criteria to ensure governance polices stick.
On the NFJS tour, there are questions that seem to come up again and again. One common example is “How do we determine which new tools and technologies we should focus our energy on learning?” another is “How do we stop management from forcing us to cut corners on every release so we can create better and more maintainable code?” which, after awhile becomes “How can we best convince management we need to rewrite the business application?”
There is a single meta-answer to all these questions and many others.
It begins with the understanding that what we as engineers value, and what the business values are often very different (even if the ultimate goals are the same) By being able to understand these different perspectives it's possible to begin to frame our arguments around the needs and the wants of the business. This alone will make any engineer significantly more effective.
This session picks up from where “Stop writing code and start solving problems” stops discussing what is value, how do we align the values of the business with the needs and values of the engineer.
Micronaut is a modern, JVM-based, full-stack framework for building modular, easily testable microservice applications.
In this session we'll dive deep into Micronaut, it's strengths, capabilities and best practices when building & testing services, functions and reactive apps.
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.
Many developers aspire to become architects. Some of us serve currently as architects while the rest of us may hope to become one some day. We all have worked with architects, some good, and some that could be better. What are the traits of a good architect? What are the skills and qualities we should pick to become a very good one? Come to this presentation to learn about things that can make that journey to be a successful architect a pleasant one.
It is designed from the ground up to be incrementally adoptable, and can easily scale between a library and a framework depending on different use cases. It consists of an approachable core library that focuses on the view layer only, and an ecosystem of supporting libraries that helps you tackle complexity in large Single-Page Applications.
In this session we'll start with a look at how VueJS stacks up against the competition. We will explore VueJs from incremental adoption to building a full SPA. We'll the core concepts and capabilities and take a look at the growing ecosystem around it.
You understand the basics: The core vue library, templates, styling and components. You understand the how and why of Vuejs. What's next?
In this session we start with some core best practices for the vue ecosystem. We dive deeper into some capabilites of the core Vue library, as well as branching out into some of the offical add-ons; specifically:
Vutify, the Vue CLI, vue-router, and nuxt.js.
There's nothing new or exciting about relational databases. We abstract them away with ORMS, grudgingly write a query here or there, but generally try to forget about them entirely. Then the performance and scalability problems begin. “Shading, the secret ingredient to the web-scale sauce” often won't help us.
The database is at the heart of nearly every system we build. Reading data and writing data account for the majority of performance bottlenecks. When it comes to SQL and relational databases, the syntax is easy, but the concepts often aren't. The most important knowledge is not obvious but it is necessary to make the right design, query, and optimization decisions.
Indexing, a glimpse under the hood of the storage engine and the query optimizer, and some best practices are all you need to know bring your DB skills head and shoulders above your peers and ready to build bigger, better, faster apps.
You've got an legacy MV* app. It's hard to maintain, hard to test, and it's a thorn in your side. You're keeping it running but both the code, and your skillset are getting a little old. If a ground-up rewrite is out of the question, you can use Vue to piecemeal refactor and modernize the app with minimal risk and zero downtime.
One of my favorite features of Vue.js is that it is incrementally adoptable, but what does this mean? Ultimately you can take any part of a webpage and turn it into a vue component. Does that piece require some jQuery widget? No problem. The libraries work just fine, side by side.
This session provides a roadmap for taking a legacy app and incrementially turning it into a modern vue masterpiece.