Observing software performance and failures in production is difficult. As systems scale, diagnosing behavior becomes more and more difficult. Monitoring via helpdesk tickets is helpful, but not the whole picture. Creating human-debuggable software comes from instrumenting software with metrics, distributed tracing, and effective logging. Being able to observe running software systems brings new data to both the product and engineering team and enables a culture of data driven decision.
Taking code from the repository to production in a consistent process makes software development easier for everyone downstream. A problem or inconsistency at any step of the software development life-cycle affects everyone, and so automating our environments is the best way to remove human error. Automating Azure, taking code to production becomes consistent, repeatable, observable, and accountable. Come see how application development and operation can be built with Azure.
"Business logic code" is the golden grail of code isolation: code that says what the application does without depending on other systems or any persistent storage, like a database.
Isolated business logic comes into effect when following the Dependency Inversion Principle, the fifth letter of the SOLID principles. The tenets of the Dependency Inversion Principle being that "High-level modules should not depend on low-level modules. Both should depend on abstractions." and "Abstractions should not depend on details. Details should depend on abstractions."
Using ASP.NET Core, I'm going to walk through both some theory and reasons to test, what to test, how to test, and why the Dependency Inversion Principle is so important to testable business logic code.
Domain Specific Languages (DSL) are built to concisely and clearly define the solution for a very specific problem, such as a template engine. Template engines have their own Domain Specific Languages leveraging declarative programming which allows us to define the desired result without dictating how to get there.
In this session, I will walk you through defining the basic syntax of a Domain Specific Language to be used by a simple text template engine, then through parsing that Domain Specific Language into an Abstract Syntax Tree (AST), and then transforming that tree into a result.
Using this new knowledge, you will be able to create your own Domain Specific Language or to create custom tooling around an existing Domain Specific Language.
Some applications and environments just don't fit well into a web app or a Docker container, and not everyone is in the cloud. Most everyone has some on-premise servers and a multitude of virtual machines. Managing all of those servers is difficult and usually involves extensive use of un-documented tribal knowledge to set these servers up or to duplicate these servers for another environment. Ansible automates away these tasks of setting up a server.
Ansible simplifies server provisioning, preparing the server for use, by allowing tasks to be scripted and source controlled. Server configuration is also kept in source control and encrypted. These Ansible scripts, or "playbooks", not only automate server setup, they now become the documentation of that server.
In this session, I will give an introduction of Ansible from the ground up and each topic will show its effects on a server.
No prior knowledge about Ansible is assumed. You will walk away with an understanding of how to do basic tasks with Ansible and when to use Ansible.