Software is math. Every class is a theorem. The compiler is the proof. And unit tests check our work.
Michael has recorded Pluralsight courses on CQRS, XAML Patterns, and Cryptography, in addition to Provable Code. He maintains the spoon-bending Assisticant, Correspondence, and Jinaga open-source libraries. He shared videos about distributed systems at historicalmodeling.com. And he helps his clients at Improving benefit from the power of software mathematics.
Many project teams use Slack as a means of communication with one another. Why not also use it to communicate with your infrastructure? Invite a helper into your conversation that can perform routine tasks tirelessly, conversationally, and interactively.
In this 4 hour workshop, you will build a Slack bot that understands natural language and integrates with your DevOps pipeline. You will use the Slack Events API to receive messages, and the Slack Web API to send them. You will use LUIS to interpret language and extract intent. You will execute actions against the Visual Studio Team Services Web API in response to user requests, and subscribe to Webhooks to notify your team of important events. In the end, you will have a new member of your team who can help you with your build and release pipeline.
When should you use a service bus vs. a web service call? When should you use the Distributed Transaction Coordinator? Should you use CQRS? Should you build Microservices?
Take a look under the hood of your network stack. What promises does it make? What promises can it actually keep?
We have many architectural choices to make within a distributed system. Those decisions depend upon the nature of the messaging infrastructure upon which we build. Different options are good for different parts of the system. But some of the advice that you may have heard is wrong. Learn what's really happening inside of the components you choose. And use that knowledge to build more reliable distributed systems.
CRUD apps destroy data.
Delete is an obviously destructive operation, but Update is no better. Updates overwrite the data that was once present. What would software look like if the only valid operations were Create and Read?
Historical Modeling is a technique for designing and building software systems that permit only inserts, no updates, no deletes. The only way to "modify" an object is to insert related records. You can then read the state of the object by querying for the presence or absence of those related records. We'll start with the assumption that all records are immutable and indelible. From there, we'll build a set of patterns that yield some surprising benefits.
With a historical model, synchronizing disparate nodes is trivial: just insert what you don't yet have. Building offline-first web applications is easy. Viewing a snapshot of the system at any point in the past is a simple query.
Let's build a historical model together, and see these benefits for ourselves. Let's put aside the assumptions of CRUD applications and discover a whole new set of patterns. Once you master these techniques, you will never destroy data again.
You and your co-workers want to keep track of who picks up the check at lunch. But they can't be trusted. Build a solution in Git that keeps things fair without trust.
The solution: blockchain!
In Git, it's a shared repository; in blockchain, a distributed ledger. Where Git has commits, blockchain has blocks. Git uses SHA, and so does blockchain. Discover how blockchain technology actually works by building a blockchain using Git. Along the way, you'll discover features such as:
• Proof of work
• 51% attack
By the end of this demonstration, you will know how blockchain solves the zero-trust problem. You will clearly see its limitations. And you will discover what you are sacrificing for that solution.
Learn several patterns that you could use to solve the problems you really have. But the problems that blockchain solves best, you don't have. That's why you don't need a blockchain.
But if you really do, here's how they work.
Not all developers need Category Theory or Linear Algebra. But every developer can benefit from Logic, Graph Theory, and Degrees of Freedom. Even if you don't think you are good at math, these are the skills that you use every day. You are a better mathematician than you give yourself credit for. Let's formalize those skills so that you can apply them with confidence.
We'll identify the Degrees of Freedom of a problem. Then we'll see how those degrees of freedom manifest in the solution. This will help us create better MVVM applications, better APIs, and better relational database models.
We'll learn some of the cool properties of Directed Acyclic Graphs, and how they help us track dependencies, and construct data models. We'll apply that knowledge to traversing those graphs in a way that always produces the correct result with the minimum necessary work.
We'll practice some of the tools of Predicate Calculus, and see how it helps us specify better requirements, and express concise queries. From that, we'll ensure that we've covered every edge case without overly complicating our code.
Math is not hard. Writing proofs is not complicated. In fact, it's exactly like writing programs.
React is a front-end Web framework based on immutable state. If you are used to thinking in React, then immutability and functional programming are a way of life. The spread operator is your favorite tool. Reducers are second-nature. It's immutable all the way…
Until you get to the API.
Then you find yourself in the land of updates. You read objects from the database, transform them, and write them back. The database is designed for mutability. The data transfer objects are *almost* like your beautiful Redux store, but just different enough to force you to stop and think. The mental shift is jarring.
So what do you do? Let someone else take care of the back end? No! You are a full-stack developer, by gosh! You want to take your love of immutable state all the way down…
To the database!
Jinaga is an application framework based on immutability. It works beautifully with React to help you create gloriously collaborative web applications. Use the same set of patterns on both sides of the client/server divide. Build the full application without ever leaving the realm of immutable, reactive, functional programming.