Gradient Migrations: A Gradual Approach to Platform Changes

Every web application will eventually face the need to make a significant and risky platform change. These come in the form of major framework upgrades, new deployment environments, or even porting to a new language. This need will show up again and again, regardless of the chosen architecture, be it monolith, microservice, or somewhere in between.

The Gradient Migration approach is a reliable, methodical, and gradual technique for making these changes safely. Further, it allows teams and business leaders to track progress, all while frequently deploying to production.

This approach avoids the issues that are present when attempting to execute a large platform change in one step, the path that most teams choose for this kind of change. It also increases the safety around platform changes, meaning that teams will be less likely to defer similar work in the future.

Come and learn about this approach, how to execute it, and explore the opportunities for innovation that it provides.

Important Metrics for Measuring Code Health

There are a bunch of different ways to measure code quality. What’re the most important ones for your team to focus on? No matter what language(s) your team is working with or your role on the team, you’ll walk away from this talk with a clear guide of what to pay attention to.

Outline
Explore the health metaphor
Defining the metrics
Churn
Code Coverage
Complexity
Tools to collect the metrics
Why these metrics?
What are good metric values?
Using the metrics together
Exploring common scenarios

Learning Outcome
An understanding of the meaning of 3 important software metrics (churn, code coverage, and complexity) and how to interpret values in combination.

Target Audience
Developers, Managers, Product Owners

Embracing the Red Bar: A technique for safely refactoring your test suite

Have your tests become brittle? Have you strongly considered dumping your test suite and starting over? Don’t throw them away. Refactor them. But you need to be careful so that you don’t introduce false positives. We’ll explore a method of refactoring your tests that makes sure they still work.

Outline
Reasons why your test code should have same high quality you insist on for your production code
Normal TDD cycle
Red, Green, Refactor
Designed for production code
Ensures that your test only passes as a result of the code that you write
Allows you to safely refactor your production code without worrying about introducing failures
Risks of changing your tests without watching them fail
Red-bar Cycle
Red, Refactor, Green
Mutate the production code - produce the red bar (your test is failing)
Refactor your test - continue to see the red bar (your test continues to fail)
Reverse the mutation - bar should switch to green (your test should now pass)
Designed for your test code
Ensures that your test code continues to detect the failure condition that it was designed to
Walk through a live example
Learning Outcome
A technique for safely improving the quality of your test suite without introducing false positives.

Target Audience
Developers, Testers

Communication is Just as Important as Code

The idea of a lone developer coding in their basement without social interaction is a thing of the past. These days, technical solutions are often developed by cross-functional teams whose participants have a range of technical experience. Now, more than ever, good communication skills are an essential part of being a software developer.

In this talk, Scott will share immediately actionable communication principles that will help you get buy-in for your ideas, reduce conflict and tension, increase productivity, be liked and respected. If you’re looking to take your career to the next level, this is one talk you won’t want to miss.

“Communication is just as Important as Code” is one of our core values at Corgibytes, a software dev shop exclusively focused on modernizing existing software applications.

At Corgibytes, we eliminate the binary belief that people are “technical” or “non-technical.” Everyone is expected to be both. Folks who come from a computer science background participate in sales calls and help with blog posts, and everyone, no matter their role, is expected to learn how to code.

To preserve a culture of autonomy, motivate our members to do their best work and to enable fluid communication, we have thought extensively about optimizing the balance between asynchronous communication, routine synchronous communication, and even developed our own framework to reduce context switching that allows people the most scheduling flexibility.

A Deep Dive into Measuring Dependency Freshness with LibYear

LibYear is a dependency freshness measure which helps you learn how out of date your project’s dependencies are. While LibYear has considerable value when used as a “spot” metric, something that you just measure once, there is even more power that can be unlocked when you observe how the metric has trended over time. In this talk, we’ll explore a tool, Freshli, which is able to compute this metric across a project’s history. The Freshli tool supports many different dependency management tools from many different frameworks. Also during this talk, we’re going to look at graphs of LibYear over time for many different open source projects. By analyzing these graphs, we can see the long term impacts of different decisions, such as when a team decides to start using Dependabot.

Building a Bridge to a Legacy Application - How Hard Can that Be?

My team loves working on legacy code projects. It’s all that we do. That’s why a friend of mine reached out to us for some help.

His startup was building out a universal API across a very fragmented industry with little to no interoperability or standards. Up until now, integrating with the systems in that industry had been pretty easy, because the companies that built them were willing to help.

But now he’d found one that wasn’t willing to help. There was no obvious API for getting data out of the legacy application so that it could be exposed via his company’s API. A big client for his company was riding on his ability to be able to pull this off. He remembered how much I loved a challenge and how much my team loved legacy code, so he figured we were his best shot.

The goal was to be able to read from the application’s database.

In this talk, I’ll cover:

- the different approaches that we took
- the one we really wanted to try because we thought it would be fun
- the approaches that we needed to try before we could attempt the fun one
- the excitement that we felt while working on it
- the grind toward completion once the big technical hurdle was crossed
- the sense of achievement when we got a read-only solution built
- the hope that we’d get the green light to start working on a read-write solution
- the disappointment when the plug got pulled and we weren’t authorized to proceed any further

It was a fun journey, and I’d love to be able to share it.

Moving a Monolith to Kubernetes

Our work with legacy code doesn’t often put us in a position to move quickly into new or trendy tooling. And while we almost always introduce Docker very early in our projects, it is usually only for the purpose of standardizing and easing setup of developer environments. Transitioning a live environment to containers, however, can be a daunting prospect.

There are a variety of reasons for that, many of which you’ve probably encountered yourself, which include:

1. The application isn’t in the cloud yet
2. It’s too complicated
3. Container orchestration (like Kubernetes or Swarm) is too new/buggy/insecure
4. We need microservices to leverage Kubernetes
5. The application is a monolith

All these might be valid reasons, but this talk will focus on our experiences in that last scenario — containerizing a monolith.

Comparing Complexity Measures

There are many different ways to measure code complexity, cognitive, cyclomatic, ABC, indentation level, lines of code, and more. Which measure is the best? Let’s compare these measures across the history of an actual project and see what we can learn.

Learning Outcome
Attendees of this talk will learn about many different complexity measures and how they compare to each other as a project changes over time.

Outline
Background
Why should we care about complexity?
The Measures
Cyclomatic complexity
Cognitive complexity
ABC complexity
Indentation level complexity
Lines of code count
In Practice
Applying the measures on a project’s history

I recently heard someone claim that many complexity measures are no better than measuring number of lines of code, especially when examining how a project changes over time. I want to do a deep dive to explore this further by using a few different open source projects for source material. In addition to learning about the different complexity measures we’ll all learn how they compare with each other.

Dig into Rekit - an opinionated framework for building React + Redux + React-router apps

Rekit is an opinionated framework for building React applications using Redux along with React-router. It includes a rich set of command line tools and an in-browser IDE environment. Let’s dig into this tool together and see what it has to offer. Experience with React is not required.

Outline
Understanding Rekit
What is it?
Why would I use it?
Important concepts
Feature
Component
Action
Reducer
Getting started with a new app
Sits on top of create-react-ap
Creating our first feature
Understanding the diagrams in Rekit Studio

Learning Outcome
An understanding of the benefits of using Rekit and how to use it to get started on a new project

Target Audience
Developers

Prerequisite
Experience with React is not required but will be helpful for understanding how Rekit’s opinionated approach is different than other learning sources.

Introducing Storybook - a tool for building and documenting UI components in isolation

Storybook is a UI development tool for building and demoing UI components. It’s a great tool for building new UI components, and the result acts as documentation for how your components work. You can also use Storybook as the foundation for visual test suites. Works with React, Vue and Angular.

Outline
What is Storybook?
Getting started
Story time
Writing your first story
Use additional stories to showcase UI options
Setting up actions to view events
Addons
Knobs - UI to dynamically control the way your component is rendered
Info - add documentation for your components
Storyshots - snapshot testing for your stories
Backgrounds - make sure your components look great on multiple backrgounds
Viewport - make sure your component renders correctly at different sizes and layouts

Learning Outcome
A basic understanding of Storybook and how to use it to its fullest potential

Target Audience
Developers using React, Angular or Vue to build UI components

The Marriage of Sales & Software: Learning to Live with (and Love) Working With Other Departments

In many organizations, there’s an invisible battle line between the sales and software teams that gets in the way of clear communication. In this talk, you will be taught small yet significant language changes you can implement immediately for better team collaboration.

In many organizations, there’s an invisible battle line between the sales and software teams. Sales people push for tighter deadlines, lower costs, and immediate feedback without fully understanding the consequences of their requests. Developers are known for being anti-social, critical, combative, and have a bad habit of overpromising and under delivering? Sound familiar?

In this talk, the speakers will present real-world ways they learned to overcome their biases and build a business and life together. You’ll learn frameworks for communicating through conflict, tips for understanding complexities outside your established domain, and small yet significant language changes you can implement today for better collaboration.

Makers and Menders: Finding Talent for Legacy Code Projects

When you think of a developer what comes to mind? A brogrammer living in San Francisco working 23 hours a day on the next Facebook? If so, you wouldn’t be alone. Like so many industries, software development is rife with stereotypes. And one that is particularly pervasive is the idea that all developers, if given the chance, would opt for a complete rewrite of an application.

While it’s true that there are many software developers who do enjoy starting with a clean slate, there is also a group who loves working on making existing applications better. Rather than starting from scratch and building an 80% solution, these developers are ideal for taking over a project once it’s become stable, and nurturing it for a long time. Neither developer is better. Both are needed in the software world. You just need to understand when to use each one.