IR

Docker

2018-10-11T00:00:00+00:00

General Command of Docker

# create volume
docker volume create myvol

# pull image from cloud/hub
docker pull [user]/image

# build docker image tagged by -t with dockerfile in directory 
docker build -t myimage "X:\MyDirWithDockerfile\"

# run iterativelly with tty /bin/bash as root user using docker image as container
docker run -it "myimagename or myimageid" /bin/bash
## example: docker run interactive image adc7e1e17105 with /bin/bash
docker run -it adc7e1e17105 /bin/bash

# to resume after exit:
## first check id with
docker ps -a
## then use "id" to resume without "" 
docker start -a -i "id"

# issue when doing: RUN ...build.sh
## solution based on (https://github.com/docker/for-win/issues/1166) is to:
before RUN ...build.sh, add a:
RUN chmod +x ...build.sh

# pushing image to cloud
docker login
docker tag myimage [user]/myimage
docker push [user]/myimage

Docker Specifics About Run

# docker run /bin/bash in myimage 
docker run -it myimage /bin/bash

## ... as user myuser  
docker run -it -u myuser myimage /bin/bash

## ... with volume myvolume in ...
### ... /home/myvolume
docker run -it -u myuser -v myvolume:/home/myvolume
### ... /myvolume
docker run -it -v myvolume:/myvolume

# connect to already run myimage
docker start -ia (docker ps -a | grep myimage | awk '{print $1;}')

Docker Specifics About Removal

# remove containers manually
## first get id of our containers (docker container ls - do not work somehow...)
docker ps -a
## now remove by our id (without "")
docker rm "id"

# docker remove all containers
docker rm $(docker ps -a -q)

# remove first from specific containers with mycontainer word in name
 docker rm (docker ps -a | grep mycontainer | awk '{print $1;}')

# remove images with <none> name and force it (usually remove all images -.-)
docker rmi $(docker images -f "dangling=true" -q) -f

Solid Principles

2018-09-11T00:00:00+00:00

Solid Principles

SOLID is one of the most popular sets of design principles when doing OOD (Object Oriented Design). SOLID principles can also form a core philosophy for methodologies such as agile development or adaptive software development.

The intention of these principles is to make software designs more understandable, easier to maintain and easier to extend.

It’s a mnemonic acronym for the following five design principles:

Single Responsibility Principle
Open/Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion

These 5 principles were introduced by Robert C. Martin (Uncle Bob), in his 2000 paper Design Principles and Design Patterns.

S — Single Responsibility Principle(S.R.P)

“A class should have one, and only one, reason to change.” Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. p. 95. ISBN 978-0135974445.

Benefits

It makes your software easier to implement and prevents unexpected side-effects of future changes.

Concepts

A module, class, or function should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class.

Examples

We have a class named Book. We use a method called formatJson() to return the book as a JSON string.

class Book {
  protected $title;
 
  public getBook($title) {
    return $this->title;
  }
 
  public function formatJson() {
    return json_encode($this->getTitle());
  }
}

If we want to change the output of the JSON string, or add another type of output to the class, we would need to alter the class to either add another method or change an existing method to suit.

How can we solve it so that it complies with the Single Responsibility Principle?.

We create a secondary class called JsonPageFormatter that is used to format the Page objects into JSON.

class Book {
  protected $title;
 
  public getBook($title){
    return $this->title;
  }
}
 
class JsonPageFormatter {
    public function format(Book $book) {
        return json_encode($book->getTitle());
    }
}

Doing this means that if we wanted to create an XML format we could just add a class called XmlPageFormatter and write some simple code to output XML.

It is one of the basic principles most developers apply to build robust and maintainable software. You can not only apply it to classes, but also to software components and microservices.

O — Open-Closed Principle

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification” Meyer, Bertrand (1988). Object-Oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3.

Benefits

It promotes the use of interfaces to enable you to adapt the functionality of your application without changing the existing code.

If we could follow this principle strongly enough, it is possible to then modify the behavior of our code without ever touching a piece of original code.

Concepts

We can make sure that our code is compliant with the open/closed principle by utilizing inheritance and/or implementing interfaces that enable classes to polymorphically substitute for each other.

This simply means that a class should be easily extendable without modifying the class itself.

We should always try to add new code instead of changing existing code.

Example

We have two different books and handle them with a switch case. Based on the type variable in the array we load in the correct book class to then echo the correct visual name.

class ScienceBook 
{
    public $type = 'Science';
    private $bookTitle;
    private $bookDescription;
    public function __construct($book) { ... }
    public function getbookTitle() 
    {
        return $this->bookTitle;
    }
    public function getBookDescription() 
    {
        return $this->bookDescription;
    }
}

class FictionBook 
{
    public $type = 'Fiction';
    private $authorName;
    public function __construct($book) { ... }
    public function getAuthorName() {
        return $this->authorName;
    }
}

class AllBooks
{
    public function show($books) {
        foreach ($books as $book) {
            switch ($book->type) {
                case 'Science':
                    echo $book->getFirstName().' '.$book->getLastName();
                    break;
                case 'Fiction':
                    echo $book->getAuthorName();
                    break;
            }
        }
    }
}

If we add a third book type then we would also need to change the existing switch case and thus break this principle.

How can we solve it so that it complies with the Open-Closed Principle?.

We created an interface which we use to extend each of the Book types. If we now add a third type, then we have no reason to change any existing code. We just add new code to add new functionality.

interface Book {
    public function getName();
}

class ScienceBook implements Book {
    private bookTitle;
    private bookDescription;
    
    public function __construct($book) { ... }
    public function getName() {
        return $this->bookTitle.' '.$this->bookDescription;
    }
}

class FictionBook implements Book
{
    private $authorName;
    
    public function __construct($book) { ... }
    public function getName() 
    {
        return $this->authorName;
    }
}

class AllBooks 
{
    public function show($books) 
    {
        foreach ($books as $book) {
            echo $book->getName();
        }
    }
}

L — Liskov Substitution Principle

Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

Benefits

The behavior of your classes becomes more important than its structure.

Concepts

The Liskov Substitution principle was introduced by Barbara Liskov in her conference keynote Data abstraction and hierarchy in 1987.

Liskov Substitution Principle extends the Open/Closed Principle by focusing on the behavior of a superclass and its subtypes.

The principle defines that objects of a superclass shall be replaceable with objects of its subclasses without breaking the application. That requires the objects of your subclasses to behave in the same way as the objects of your superclass.

An overridden method of a subclass needs to accept the same input parameter values as the method of the superclass. That means you can implement less restrictive validation rules, but you are not allowed to enforce stricter ones in your subclass.

Examples

In this example we extend Square from Rectangle. The difference between a square and rectangle is that a square its sides are always the same size. So if we set height or width we need to change both height and width.

class Rectangle
{
    protected $height;
    protected $width;

    public function setHeight(int $height)
    {
        $this->height = $height;
    }
    
    public function setWidth(int $width)
    {
        $this->width = $width;
    }
}

class Square extends Rectangle
{
    public function setHeight(int $height)
    {
        $this->height = $height;
        $this->width = $height;
    }
    
    public function setWidth(int $width)
    {
        $this->height = $width;
        $this->width = $width;
    }
}

A solution to this example is to have an Abstract class where both will have different setters to calculate the sides and we have one general function which calculates the area.

abstract class AbstractShape
{
    abstract public function Area() : int;
}

class Rectangle extends AbstractShape
{
    private $height;
    private $width;
    
    public function setHeight(int $height)
    {
        $this->height = $height;
    }
    
    public function setWidth(int $width)
    {
        $this->width = $width;
    }
    
    public function Area() : int
    {
        return $this->height * $this->width;
    }
}

class Square extends AbstractShape
{
    private $sideLength;
    
    public function setSideLength(int $sideLength)
    {
        $this->sideLength = $sideLength;
    }
    
    public function Area() : int
    {
        return $this->sideLength * $this->sideLength;
    }
}

I — Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they do not use.

Benefits

You can apply these principles also to microservices.

Concepts

The goal of the Interface Segregation Principle is to reduce the side effects and frequency of required changes by splitting the software into multiple, independent parts.

Examples

We have an interface Book. We implement an Paper class. Then we have a problem, because an Paper is a book, but it can’t be download.

interface Book 
{
    public function read();
    public function download();
}

class Ebook implements Book
{
    public function read() { ... }
    public function download() { ... }
}

class Paper implements Book
{
    public function read() { ... }
    public function download() { /* exception */ }
}

We should solve this by creating a separate interface for digital books and paper books.

interface Book
{
    public function read();
}

interface DigitalBook
{
    public function download();
}

interface PaperBook
{
    public function buy();
}

class Ebook implements Book, DigitalBook
{
    public function read() { ... }
    public function download() { ... }
}

class Paper implements Book, PaperBook 
{
    public function read() { ... }
    public function buy() { ... }
}

D — Dependency Inversion Principle

High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.

Benefits

Decouple your code from its direct dependencies.

Concepts

We have high level modules and low level modules. In simplest terms the high level modules are the ones we call directly and do all the high level business logic. Low level modules are classes that help our high level modules, this can be inserting data to a database or printing a date in the correct format.

High-level modules, which provide complex logic, should be easily reusable and unaffected by changes in low-level modules, which provide utility features. To achieve that, you need to introduce an abstraction that decouples the high-level and low-level modules from each other.

An important detail of this definition is, that high-level and low-level modules depend on the abstraction.

Examples

interface Adapter
{
    public function getData();
}

class Mysql implements Adapter
{
    public function getData()
    {
        return 'data from database';
    }
}

class Controller
{
    private $adapter;
    public function __construct(Mysql $mysql)
    {
        $this->adapter = $mysql;
    }
    function getData()
    {
        $this->adapter->getData();
    }
}

In this example we can only pass an object of the database type.

interface Adapter
{
    public function getData();
}

class Mysql implements Adapter
{
    public function getData()
    {
        return 'data from database';
    }
}

class Controller
{
    private $adapter;
    public function __construct(Adapter $adapter)
    {
        $this->adapter = $adapter;
    }
    function getData()
    {
        $this->adapter->getData();
    }
}

Now we can pass whatever implementation we want based on our Adapter interface.

References

SOLID
Single responsibility principle
Open-closed principle
Liskov_substitution_principle
Robert C. Martin, The Liskov Substitution Principle, C++ Report, March 1996
Interface segregation principle
Dependency inversion principle

Design Patterns

2018-08-11T00:00:00+00:00

Design Patterns

About Design Patterns

Design Patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is a description, or template, for how to solve a problem that can be used in many different situations. It’s not language-specific. A good design pattern should be implementable in most if not all languages, depending on the capabilities of the language.

There are three basic kinds of design patterns: Creational Abstract Factory, Builder, Factory Method, Object Pool, Prototype, Singleton.

Structural Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.

Behavioral Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor.

Generally, the three groups above define how your program elements relate to each other, how they get created, and how they communicate with each other.

Why use them? Design patterns are well-thought out solutions to programming problems. Let’s draw a parallel with a real-world example. Suppose you are standing at the base of a mountain and have been given the task of reaching its top by the end of the day. Assuming that you are unaware of the available routes to the mountain top, what will you do? Of course, you will start to climb up as per your own understanding. Your lack of knowledge about the right route makes it extremely difficult for you to decide the best possible route. If somebody gives you a detailed map along with all possible routes, including the pros and cons of each, then you will be in a much better position to begin your journey and choose the right route.

Simply put a design pattern is a proven solution to solve design problems

Singleton Design Pattern

Singleton is a creational design pattern, which ensures that only one instance of a class is created.

Singleton may be used when:

you need access to a shared resource.
access to a shared resource will be requested from multiple, separate parts of your program.
only one object can be instantiated.

A good example is a Logger, which is used in every part of the system to log some information. For example, in a social network, every activity of a user should be logged (login, logout, comment, posts, likes). Instead of instantiating a new Logger instance over and over again for each activity type, it would be better to have a single instance and access it when needed. In other words, it is better to use the same Logger instance to log user logins, logouts, comments, posts, and likes, when necessary.

Singletons are intended to be used when a class must have exactly one instance, no more, no less.

Factory Method Design Pattern

Factory Method is a creational pattern that defines an interface for creating an object, but lets subclasses decide which class to instantiate.

The best time to use the factory method pattern is when you have multiple variations of a single entity. For example, let’s consider a program that creates different shapes. For this program, we need to define a ShapeFactory that will act as a common interface for creating shapes. Using this interface, each subclass will create the specific shape by implementing the ShapeFactory’s corresponding “create” method.

To better understand the Factory Method concept, consider a real-world employment agency. The agency helps clients fill positions for their company. The client provides the hiring criteria and then leaves the details of assessing candidates to the agency. The hiring agency takes care of a potential candidate’s eligibility, skill, and experience verification to ensure that the candidate matches the hiring criteria. In this case, the hiring agency acts as the factory. It allows the client to create new objects without having to know the details of how they’re created.

We create objects without exposing the creation logic to the client and refer to newly created objects using a common interface (employment agency).

The factory method pattern relies on inheritance, as object creation is delegated to subclasses that implement the factory method to create objects.

The Factory Method is usually used when creating frameworks, which standardize the architectural model for a range of applications, but allow for individual applications to define their own objects and their instantiation.

A Factory is a creator of objects that have a common interface.

Abstract Factory Design Pattern

The Abstract Factory is a creational pattern, similar to the Factory Method pattern, with the key difference being that the Abstract Factory provides an interface for creating families of related or dependent objects without specifying their concrete classes.

Often, designs start out using Factory Method and evolve toward Abstract Factory as more flexibility is needed.

Imagine an application needs to run on different operating systems. In order to achieve this, we need to encapsulate the dependencies of our application. One approach is to have a “factory” object that has the responsibility of providing creation services for the entire platform family. Each time we need a new object for our application, we use the factory. This makes a class independent of how its objects are created (which concrete classes are instantiated).

Consider a “factory” to create UI elements. The same factory can create buttons, textboxes, windows, and other elements for two operating systems - Windows and MacOS. When we want to create a new button, we do not instantiate a new button class for a particular operating system. Instead, we request the factory create a button, and the factory does so, considering the parameters of the operating system. The same applies for any other UI object. As a result, we get the object we need without getting into detail of how the objects are created.

Basically, the Abstract Factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes.

Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton.

Builder Design Pattern

The Builder design pattern is a creational pattern that separates the construction of a complex object from its representation. By doing so, the same construction process can create different representations. Simply said, it builds a complex object using simple objects and a step-by-step approach.

For example, let’s say we need to build cars. Each car has many options. The combination of options would lead to a huge list of constructors for the Car class. To avoid this, we will create a builder class, CarBuilder. We will send each option step by step to the CarBuilder and then construct the final car with the correct options. This approach makes it flexible to add and remove options from the car.

Sometimes creational patterns are complementary: Builder can use one of the other patterns to implement which components are built.

Object Pool Pattern

The Object Pool design pattern is useful when it is necessary to work with a large number of objects that are particularly expensive to instantiate, especially if each object is only needed for a short period of time.

Instead of creating and destroying the expensive objects, the object pool pattern suggests reusing the already created objects.

When a new object is needed, it is requested from the pool. If a previously prepared object is available it is returned immediately, avoiding the instantiation cost. If no objects are present in the pool, a new item is created and returned. When the object has been used and is no longer needed, it is returned to the pool, allowing it to be used again in the future without repeating the expensive instantiation process.

For example, the Object Pool design pattern is used in the .NET Framework Data Provider for SQL Server. As SQL Server database connections can be slow to create, a pool of connections is maintained. When you close a connection, the connection is held in a pool from which it can be retrieved when requesting a new connection. This substantially increases the speed of making connections.

Object Pools are usually implemented as Singletons.

Prototype Design Pattern

The Prototype design pattern is a creational pattern that uses a prototype to create new objects by copying this prototype. In other words, instead of creating new objects, we clone them from the prototype.

The pattern is used when object creation is resource expensive. By cloning new objects, we avoid the inherent cost of creating a new object in the standard way.

Mitotic cell division, which results in two identical cells, is an example of the Prototype pattern. When a cell splits, two cells of identical genotype result. In other words, the cell clones itself.

Prototype is unique among the other creational patterns as it doesn’t require a class - only an object.

Adapter Design Pattern

The Adapter pattern is a structural design pattern that allows the interface of an existing class to be used as another interface. It is often used to make existing classes work with others without modifying their source code.

For example, let’s consider you have an old class that implements some functionality needed in your new project. However, the way it is written is not compatible with the philosophy and architecture of the system currently being developed. In order to use the old class without rewriting the whole functionality from scratch, we can create an adapter, also called a wrapper, that translates, or maps, the old component to the new system. Your program will then call the wrapper, which will redirect to the corresponding methods in the old class.

The key idea in this pattern is to work through a separate Adapter that adapts the interface of an already existing class without changing it.

Bridge Design Pattern

The Bridge pattern is designed to separate the abstraction from the implementations so they can be used and changed independently.

Let’s look at an example to understand when this is useful and what this “confusing” definition means. Say you need to create a shape drawing application that should work on both Windows and MacOS.

You could create a Shape interface, inherit from it the types of the shapes, like Rectangle or Circle, and then inherit from those to create the OS-specific implementations. The class hierarchy would look like this:

Now, consider that you need to support more shape types and more OSes. That would lead to a significant number of classes being added - the number of types multiplied by the number of OS versions.

So, basically, to support five shape types on three different OSes, you would need to write 5*3=15 implementations.

However, the Bridge pattern suggests refactoring this into two separate hierarchies - one for platform-independent abstractions (Shapes), and the other for platform-dependent implementations (OSes). Here is the refactored diagram:

The relationship between Shape and ShapeImplementation is the Bridge.

This pattern is used in situations where it would be best to isolate the handling of the system-dependent stuff from the handling of the system-independent stuf

The Bridge pattern is often confused with the Adapter pattern. Adapter makes things work after they’re designed;
Bridge is designed up-front to let the abstraction and the implementation vary independently. Further, Adapter is retrofitted to make unrelated classes work together. In other words, an adapter is a patch. A bridge is put in place on purpose.

Composite Design Pattern

The Composite pattern describes a group of objects that is treated the same way as a single instance of the same type of object.

Composite should be used when clients ignore the difference between compositions of objects and individual objects.

For example, when dealing with tree-structured data, programmers often must discriminate between a leaf-node and a branch. This makes code more complex, and therefore, more error-prone. The solution is an interface that allows treating complex and primitive objects uniformly. Other examples are menus that contain menu items, each of which could be a menu. Directories that contain files, each of which could be a directory.

The key concept is that you can manipulate a single instance of the object just as you would manipulate a group of them.

Decorator Design Pattern

The Decorator design pattern allows behavior to be added to an individual object, either statically or dynamically, without affecting the behavior of other objects from the same class.

This is achieved by designing a new Decorator class that wraps the original class. This pattern is designed so that multiple decorators can be stacked on top of each other, each adding a new functionality.

The goal is to make it so that the extended behavior can be applied to one specific instance, and, at the same time, still be able to create an original instance that doesn’t have the new behavior.

This pattern is an alternative to subclassing, which refers to creating a class that inherits functionality from a parent class. As opposed to subclassing, which adds the behavior at compile time, “decorating” allows you to add new behavior during runtime, if the situation calls for it.

For example, consider a window in a windowing system. Assume windows are represented by instances of the Window class, and assume this class has no functionality for adding scrollbars. We could create a subclass ScrollingWindow that provides them, or create a ScrollingWindowDecorator that adds this functionality to existing Window objects. At this point, either solution would be fine.

Now, assume one also desires the ability to add borders to windows. If we had used subclassing, then we have a problem, as we will need to create separate subclasses with the borders functionality for all possible types of windows. With the decorator solution, we simply create a new BorderedWindowDecorator and decorate any window we need during runtime.

So, using decorator, we have the ability to add scrollbars and/or borders to any of our Windows objects.

Notice that if the functionality needs to be added to all Windows, you could modify the base class and that will do. However, sometimes (e.g., when using external frameworks) it is not possible, legal, or convenient to modify the base class.

The I/O Streams implementations of both Java and the .NET Framework follow the decorator pattern by extending the base subclass to add features to the stream classes.

Facade

The Facade design pattern provides a unified interface to a set of interfaces in a subsystem, thus making a complex subsystem easier to use.

A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can: - make a software library easier to use, understand, and test, since the facade has convenient methods for common tasks, - make the library more readable, - wrap a poorly designed collection of APIs with a single well-designed API.

The Facade design pattern is often used when a system is very complex or difficult to understand because the system has a large number of interdependent classes or its source code is unavailable. This pattern hides the complexities of the larger system and provides a simpler interface to the client. It typically involves a single wrapper class that contains a set of members required by the client. These members access the system on behalf of the facade client and hide the implementation details.

The $ in jQuery, which provides a simple interface to common operations, is an example of the Facade design pattern.

Adapter and Facade are both wrappers, but they are different kinds of wrappers. The intent of Facade is to produce a simpler interface, and the intent of Adapter is to design to an existing interface.

Flyweight Design Pattern

The Flyweight design pattern efficiently supports a large number of objects. A flyweight is an object that minimizes memory usage by sharing as much data as possible with other similar objects; it is a way to use objects in large numbers when a simple repeated representation would use an unacceptable amount of memory.

For example, when representing large text documents, creating an object for each character in the document would result in a huge number of objects that couldn’t be processed efficiently. Instead, for every character there might be a reference to a flyweight glyph object shared by every instance of the same character in the document; only the position of each character in the document would need to be stored internally.

As another example, modern web browsers use this technique to prevent loading the same images twice. When a browser loads a web page, it traverses through all images on that page. The browser loads all new images and places them in the internal cache. For already loaded images, a flyweight object is created, which has some unique data-like position within the page, but the image itself is referenced from the cache.

To enable safe sharing between clients and threads, Flyweight objects must be immutable. Flyweight objects are by definition value objects. The identity of the object instance is of no consequence; therefore, two Flyweight instances of the same value are considered equal.

Proxy Design Pattern

The Proxy design pattern provides a placeholder for another object to control access to it.

A proxy is a class functioning as an interface to something else, such as a network connection, a large object in memory, a file, or some other resource that is expensive or impossible to duplicate. A proxy acts as a wrapper object that is being called by the client to access the real serving object behind the scenes. For the client, usage of a proxy object is similar to using the real object, because both implement the same interface.

Possible Usage Scenarios Remote Proxy In distributed object communication, a local object represents a remote object. The local object is a proxy for the remote object, and method invocation on the local object results in remote method invocation on the remote object. An example would be an ATM implementation, where the ATM might hold proxy objects for bank information that exists in the remote server.

Virtual Proxy In place of a complex or heavy object, a skeleton representation may be advantageous in some cases. When an underlying image is huge in size, it may be represented using a virtual proxy object, loading the real object on demand.

Protection Proxy A protection proxy might be used to control access to a resource based on access rights.

A proxy can:

hide information about the real object from the client.

perform optimization like on-demand loading.

do additional housekeeping jobs like audit tasks.

Technical Books

2018-07-11T00:00:00+00:00

Technical Books

Alice: Would you tell me, please, which way I ought to go from here?. The Cheshire Cat: That depends a good deal on where you want to get to. Alice: I don’t much care where. The Cheshire Cat: Then it doesn’t much matter which way you go. Alice: …So long as I get somewhere. The Cheshire Cat: Oh, you’re sure to do that, if only you walk long enough. (Alice’s Adventures in Wonderland - Lewis Carroll)

A books library for programmers.

The goal of this library is to make you a more proficient developer. You’ll find books that have become timeless classics or I’ve found truly inspiring.

This page is not meant to be comprehensive. The selection of books is opinionated.

Contributing to this book library. Feel free to open a PR to contribute! Thanks.

Agile

Agile Software Development, Principles, Patterns, and Practices (by Robert C. Martin)
Practices of an Agile Developer: Working in the Real World (by Venkat Subramaniam)
Agile Principles, Patterns, and Practices in C# (Robert C. Martin Series)
The Scrum Field Guide: Agile Advice for Your First Year and Beyond (by Mitch Lacey)

Algorithms

The Art of Computer Programming (by Donald Knuth)
Introduction to algorithms (by Cormen & Leiserson & Rivest & Stein)
Algorithms + Data Structures = Programs (by Niklaus Wirth)

APIs

Build APIs You Won’t Hate (by Phil Sturgeon)
Hands-On RESTful API Design Patterns and Best Practices: Design, Develop, and Deploy Highly Adaptable, Scalable, and Secure RESTful Web APIs (by Harihara Subramanian & Pethuru Raj)

Architecture

Clean Architecture: A Craftsman’s Guide to Software Structure and Design (by Robert C. Martin)
Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems (by Martin Kleppmann)
Software Architect’s Handbook: Become a Successful Software Architect by Implementing Effective Architecture Concepts (by Joseph Ingeno)
Cracking the IT Architect Interview (by Sameer Paradkar)
Software Architecture Patterns (by Mark Richards)

AWS

AWS Certified Solutions Architect (by Joe, Hisham, Tim, Biff, Kevin, John and Sean)

Best Practices

Clean Code: A Handbook of Agile Software Craftsmanship (by Robert Martin)
The Clean Coder: A Code of Conduct for Professional Programmers (by Robert Martin)
The Pragmatic Programmer (by Andrew Hunt)
Adaptive Code: Agile coding with design patterns and SOLID principles (by Gary McLean Hall)
Code Complete 2 (by Steve McConnell)
Foundations of Programming (by Karl Seguin)
The Art of Readable Code: Simple and Practical Techniques for Writing Better Code (by Dustin Boswell & Trevor Foucher)
A Philosophy of Software Design (by John Ousterhout)
Structure and Interpretation of Computer Programs (by Harold Abelson)

C

The C Programming Language (by Brian W. Kernighan & Dennis Ritchie)

Continuous Delivery

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (by Jez Humble & David Farley)
Continuous Delivery Handbook : Non Programmer’s Guide to DevOps, Microservices and Kubernetes (by Stephen Fleming)

Continuous Integration

Continuous Integration: Improving Software Quality and Reducing Risk (by Paul M. Duvall)

Databases

MySQL High Availability (by Charles Bell, Mats Kindahl & Lars Thalmann)

DDD

Domain-Driven Design (by Eric Evans)
Domain-Driven Design (by Vaughn Vernon)
Domain-Driven Design: Tackling Complexity in the Heart of Software (by Eric Evans)

DevOps

The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations (by Gene Kim & Patrick Debois & John Willis, Jez Humble, John Allspaw)
Ansible for Devops: Everything You Need to Know to Use Ansible for Devops (by David Johnson)
DevOps with Kubernetes (by Hideto Saito & Hui-Chuan Chloe Lee & Cheng-Yang Wu)
Implementing Modern DevOps: Enabling IT organizations to deliver faster and smarter (by David Gonzalez)

Design Patterns

Head First Design Patterns (by Elisabeth Freeman and Kathy Sierra)
Software Architecture Patterns (by Mark Richards)
Design Patterns: Elements of Reusable Object-Oriented Software (by ErichGamma, RichardHelm, RalphJohnson, and JohnVlissides, The GangOfFour)
Design Patterns in C# (by Steve Metsker)
Patterns of Enterprise Application Architecture (by Martin Fowler)
Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (by Martin Fowler)

Docker

Docker Cookbook: Over 100 Practical and Insightful Recipes to Build Distributed Applications With Docker , 2nd Edition (by Ken Cochrane)

Java

Java All In One (by Doug Lowe)
Effective Java (by Joshua Bloch)
Thinking in Java (by Bruce Eckel)
Think Data Structures: Algorithms and Information Retrieval in Java (by Allen Downey)

JavaScript

JavaScript: The Good Parts (by Douglas Crockford)

Laravel

Laravel Code Bright (by Dayle Rees)
Laravel From Apprentice to Artisan (by Taylor Otwell)
Laravel Testing Decoded (by Jeffrey Way)
Laravel Design Patterns (by Arda)
Laravel Cookbook (by Christopher Pitt and Taylor Otwell)
Implementing Laravel (by Chris Fidao)

Machine Learning

Machine Learning Algorithms (by Giuseppe Bonaccorso)

Management

The Manager’s Path (by Camille Fournier)
The Mythical Man-Month: Essays on Software Engineering (by Frederick P. Brooks Jr.)
Peopleware: Productive Projects and Teams (by Tom DeMarco & Timothy Lister)
The Deadline: A Novel About Project Management (by Tom DeMarco)
Software Estimation: Demystifying the Black Art (by Steve McConnell)
Unite the Tribes: Leadership Skills for Technology Managers (by Christopher Duncan)
Notes to a Software Team Leader (by Roy Osherove)
Making Things Happen: Mastering Project Management (by Scott Berkun)
Confessions of an Unintentional CTO: Lessons in Growing a Web App (by Jack Kinsella)
Practical Change Management for IT Projects (by Emily Carr)

Mathematics

Mathematical Foundations of Nature-Inspired Algorithms (by Xin-She Yang & Xing-Shi He)

Microservices

Building Microservices (by Sam Newman)
PHP Microservices. Transit from monolithic architectures to highly available, scalable, and fault-tolerant microservices (by Carlos Perez Sanchez & Pablo Solar Vilarino)
Advanced Microservices: A Hands-On Approach to Microservice Infrastructure and Tooling (by Thomas Hunter Ii)
Microservices AntiPatterns and Pitfalls (by Mark Richards)

PHP

Modern PHP (by Josh Lockhart)
Scaling PHP Apps (by Steve Corona)
Modular Programming with PHP 7 (by Branko Ajzele)
PHP the right way (by Josh Lockhart and the PHP community)
Mastering PHP Design Patterns (by Junade Ali)
DDD in PHP (by Carlos Buenosvinos)
PHP 7 Data Structures and Algorithms: Implement Linked Lists, Stacks, and Queues Using PHP (by Mizanur Rahman)

Python

Python: Master the Art of Design Patterns (by Dusty Phillips)
Test-Driven Development With Python: Obey the Testing Goat: Using Django, Selenium, and JavaScript (by Harry J. W. Percival)
Python Data Structures and Algorithm. Improve the performance and speed of your applications (by Benjamin Baka)

Refactoring

Working Effectively with Legacy Code (by Michael Feathers)
Refactoring: Improving the Design of Existing Code (by Martin Fowler)
Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis (by Adam Tornhill)
Refactoring to Patterns (by Joshua Kerievsky)

Symfony

A Year With Symfony: Writing healthy, reusable Symfony2 code (by Matthias Noback)
Symfony Framework Deep Dive - Security (by Joshua Thijssen)
Mastering Symfony (by Sohail Salehi)

Soft Skills

Soft Skills: The software developer’s life manual (by John Z. Sonmez)
The Phoenix Project (by Gene Kim, Kevin Behr and Kim Spafford)
Grokking Algorithms: An illustrated guide for programmers and other curious people (by Aditya Bhargava)
97 Things Every Programmer Should Know: Collective Wisdom from the Experts (by Kevlin Henney)
Code Simplicity: The Fundamentals of Software (by Max Kanat-Alexander)
Cracking the Coding Interview (by Gayle Laakmann McDowell)
Coders at Work: Reflections on the Craft of Programming (by Peter Seibel)
The Practice of Programming (by Brian W. Kernighan & Rob Pike)
Facts and Fallacies of Software Engineering (by Robert Glass)
The Passionate Programmer: Creating a Remarkable Career in Software Development (by Chad Fowler)
The Self-Taught Programmer: The Definitive Guide to Programming Professionally (by Cory Althoff)
The Problem With Software: Why Smart Engineers Write Bad Code (by Adam Barr)
The Full Stack Developer: Your Essential Guide to the Everyday Skills Expected of a Modern Full Stack Web Developer (by Chris Northwood)
The Best Software Writing I: Selected and Introduced (by Avram Joel Spolsky)
Joel on Software (by Avram Joel Spolsky)

TDD

Test Driven Development: By Example (by Kent Beck)
Growing Object-Oriented Software, Guided by Tests (by Steve Freeman & Nat Pryce)
ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (by Markus Gärtner)

UX/UI

Don’t Make Me Think, Revisited: A Common Sense Approach to Web Usability (by Steve Krug)

Dilbert’s Guide to the Rest of Your Life: Dispatches from Cubicleland (by Scott Adams)
The Computational Beauty of Nature: Computer Explorations of Fractals, Chaos, Complex Systems, and Adaptation (by Gary William Flake)
Nine Algorithms That Changed the Future: The Ingenious Ideas That Drive Today’s Computers (by John MacCormick & Chris Bishop)
Technopoly (by Neil Postman)
Developer Hegemony (by Erik Dietrich)
Gödel, Escher, Bach: An Eternal Golden Braid (by Douglas Hofstadter)
World Without Mind (by Franklin Foer)
Algorithms of Oppression. How Search Engines Reinforce Racism (by Safiya Umoja Noble)
Weapons Of Math Destruction (by Cathy O’neil)
Automating Inequality: How High-Tech Tools Profile, Police, and Punish the Poor (by Virginia Eubanks)
Modern Monopolies: What It Takes to Dominate the 21st Century Economy (by Nicholas L. Johnson)
The Four: The Hidden DNA of Amazon, Apple, Facebook and Google (by Scott Galloway)
Ten Arguments for Deleting Your Social Media Accounts Right Now (by Jaron Lanier)
Who Owns the Future? (by Jaron Lanier)
You Are Not a Gadget: A Manifesto (by Jaron Lanier)
To Save Everything, Click Here: The Folly of Technological Solutionism (by Evgeny Morozov)
The Net Delusion: The Dark Side of Internet Freedom (by Evgeny Morozov)
The Filter Bubble: What The Internet Is Hiding From You (by Eli Pariser)
Technoutopia: How optimism ruined the internet (by Alex Warren)
What Algorithms Want: Imagination in the Age of Computing (by Ed Finn)
The Shallows: What the Internet Is Doing to Our Brains (by Nicholas Carr)
The Glass Cage: Automation and Us (by Nicholas Carr)
Utopia Is Creepy: and Other Provocations (by Nicholas Carr)
Superintelligence: Paths, Dangers, Strategies (by Nick Bostrom)
L’humanité augmentée. L’administration numérique du monde (by Eric Sadin)
La vie algorithmique. Critique de la raison numérique (by Eric Sadin)
Los dueños de internet: Cómo nos dominan los gigantes de la tecnología y qué hacer para cambiarlo (by Natalia Zuazo)
Guerras de internet: Un viaje al centro de la red para entender cómo afecta tu vida (by Natalia Zuazo)

Not Only Tech

Homo Deus: A Brief History of Tomorrow (by Yuval Noah Harari)
21 Lessons for the 21st Century (by Yuval Noah Harari)
Liquid Surveillance: A Conversation (by Zygmunt Bauman & David Lyon)
Liquid Modernity (by Zygmunt Bauman)

IR

Docker

General Command of Docker

Docker Specifics About Run

Docker Specifics About Removal

Solid Principles

Solid Principles

S — Single Responsibility Principle(S.R.P)

Benefits

Concepts

Examples

O — Open-Closed Principle

Benefits

Concepts

Example

L — Liskov Substitution Principle

Benefits

Concepts

Examples

I — Interface Segregation Principle

Benefits

Concepts

Examples

D — Dependency Inversion Principle

Benefits

Concepts

Examples

References

Design Patterns

Design Patterns

About Design Patterns

Singleton Design Pattern

Factory Method Design Pattern

Abstract Factory Design Pattern

Builder Design Pattern

Object Pool Pattern

Prototype Design Pattern

Adapter Design Pattern

Bridge Design Pattern

Composite Design Pattern

Decorator Design Pattern

Facade

Flyweight Design Pattern

Proxy Design Pattern

Technical Books

Technical Books

Agile

Algorithms

APIs

Architecture

AWS

Best Practices

C

Continuous Delivery

Continuous Integration

Databases

DDD

DevOps

Design Patterns

Docker

Java

JavaScript

Laravel

Machine Learning

Management

Mathematics

Microservices

PHP

Python

Refactoring

Symfony

Soft Skills

TDD

UX/UI

Related Tech Books

Not Only Tech