Learning on the Job

In the modern day of distributed systems, the unsung hero of production debugging is having a centralized log systems and visualizer. A centralized log system is to have a central location that all logs from relevant systems would be dumped, for developers to navigate through to determine the health and confidence in a deployed system.  In today's development world, your systems will most likely consist of several systems (microservice architecture) or load balanced instances that make it hard to have your logs on one machine or database or other location.  The solution is to have all these systems pass their logs over to a central entity to be processed. Our system I first realized this need after working in a multi-tenant, multi-service environment.  To me just saying that screams head ache for anything deployed, where we don't have the ability to step through the code step by step. We previously set up our service to use Serilog, a structured logging framework for .

Abstract Factory Type: Object Creational Intent : Provide an interface for creating families of related or dependent objects without specifying their concrete classes.  This will give you the ability to have diverse implementations for a common interface. Rough Description : Abstract Factory is the interface that you define to encapsulate all the objects of a certain family.  From there you can create what are called "Concrete Factory", which actually instantiates the family of objects for you.  Your client or consumer will only know of the interface.  Somewhere in your code, you will set the interface to your Concrete Factory which will do the heavy lifting of instantiating your objects. Applicability A system should be independent of how its products should be created, composed, or represented. A system should be configured with one of multiple families of products. A family of related products need to be configured together, and relations enforced . You

Essential Patterns to Know In the new posts, I'll be focusing on some suggested design patterns and evaluating them based on the components described in the last post. I will be covering: Abstract Factory (Creational) Adapter (Structural) Composite (Structural) Decorator (Structural) Factory Method (Creational) Observer (Behavioral) Strategy (Behavioral) Template Method (Behavioral) The following design patterns have been organized into three categories: Creational, Structural, and Behavioral.  Additionally there are categorize them by the scope of the pattern, if it is on the class (structure) or the object (implementation). Pattern Types Creation Design Patterns deal with how you create objects.  Creational class patterns will defer object creation to subclasses, whereas Creational object patters defer it to another object. Structural Design Patterns deal with the composition of classes and objects.  Structural class patterns use inheritance to compose

What is a Design Pattern? Going through the the design patterns book, one of the introductory paragraphs is to define what a design pattern is and why they exist.  The book splits it up into the following components: Pattern Name and Classification  - All design patterns have a name that is universally recognized and can describe it in a small amount of terms. Intent  - This is a short statement that answers the following What does the pattern do? What is the rationale and intent? What particular design issue or problem are we trying to address? Also Known As  - Other well-known names this algorithm may go as Motivation  - A scenario that illustrates a design problem and how the organization of your code can solve a particular problem. Applicability - In what situations can this pattern be applied Structure  - A graphical representation of classes in the pattern and how they interact between objects Participants  - Classes or objects participating in the design patte

Interfacing with Interfaces One of the first lessons that the design pattern book threw at me was to "Program to an interface, not an implementation".  Having more experience under my belt, I've begun to notice the importance of decoupling requirements and code, such that we can create well-defined, manage-able code. So what does this mean to me?  For a long time, interfaces to me was more boilerplate code that I would have to set up to define an object that I already had.  But as I grew to work on more and more complex systems, its been a godsend to be able to use interfaces to dynamically swap components at run time, and to allow our architecture to be more flexible and robust. How do I use it? One of the greatest uses of interfaces is to facilitate the contract / handler pattern that allows us to decouple our implementation of a service, and allow us to swap in any other service that follows the same spec. Designing Your System for Change Let look into this b

Angular Angular 2 Web build process CocoaPods Bot Framework AWS SSL Certificates and Security Evaluating an SDK (mobile) JSON and response handling GIT branching strategy Clean Code Push Notification Architecture (iOS and Android) Mocking a service Development Environments and promotion What it means to be QA iOS permissions and best practices