DEV Community: Saúl Zalimben

Software Architecture Styles

Saúl Zalimben — Mon, 23 Oct 2023 15:28:14 +0000

Architecture styles help define the basic characteristics and behavior of an application. Some styles lend themselves to highly scalable systems, whereas others lend themselves to applications that allow developers to respond quickly to change.

Knowing each architecture style’s characteristics, strengths, and weaknesses is necessary to choose the one that meets your specific business needs and goals.

Architecture styles describe the macrostructure of a system. An architectural style improves partitioning and promotes design reuse by frequently solving recurring problems.
Architecture patterns, on the other hand, describe reusable structural building block patterns that can be used within each of the architectural styles to solve a particular problem.
They provide a structured solution to architectural issues, detailing how components and interactions should be structured for specific functionality.

Architecture styles can be composed of architectural patterns, which in turn can be composed of design patterns.

An architecture style can be composed of architectural patterns, which in turn can be composed of design patterns. Design patterns and architecture patterns are typically combined to form a complete solution.

Architecture styles act in the same way, they can also be combined when building software solutions to form a complete solution.

Hybrid architectural styles are common in the real world because not every architectural style can solve every business problem.

The separation of what is architectural and what is design is not commonly agreed upon, nor are the patterns cataloged in any accepted form.

Architecture Classification

Architecture styles are classified as belonging to one of two main architectural structures: monolithic (single deployment unit) and distributed (many deployment units, usually consisting of services).

Monolithic architectures are single deployment units.

While cost and simplicity are the main strong points of a monolithic architecture, operational characteristics such as scalability, fault tolerance, and elasticity are its weak points.

Moreover, mean time to recovery (MTTR) and mean time to start (MTTS) are usually measured in minutes, meaning that once a failure does occur, it takes a long time for the application to start back up. These long startup times also impact scalability and elasticity.

What is Monolithic Architecture?

Monolithic architecture is an architectural style of designing and developing complete applications as a single unit. For example, a traditional application will have a frontend API service, a load balancer, and a database.
In this style, everything from user interface, business codes, and data access operations is included in the same code base. If all the functionalities of a project exist in a single code base, then that application is known as a monolithic application.

Advantages and disadvantages

Since the project is a single code base, it is easy to pull and get started to develop. It is easy to debug business interactions across different modules.

It becomes too large in code size with time. That's why it's difficult to manage, to work in parallel in the same code base, and to implement new features. Any changes need deploying the entire application and so on.

When to Consider This Style

If you are building a small app, go with monolithic architecture because it's simpler. Building, testing, deploying, and troubleshooting them is simple. Scaling up is quick and easy. It is easier to deploy as only a single jar or war file is deployed.

Also, this style should be considered if your team is small, around 3 to 5 people. You can meet all your business needs without dealing with extra architectural complexity. Focus on the business side, not the latest technology options.

You can also use this when making a basic app with a known size and difficulty level. If your application is not very complex and doesn't need to handle a large amount of data, a monolithic architecture is a good choice.

This architecture is a good fit to build a proof of concept and quick launch. This way, you can test your idea and decide to pivot or wrap up the project very fast.

Headless Architectures

Headless architecture separates the website's frontend (UI) and backend (business logic). This way, businesses gain maneuverability and flexibility. This is a step towards distributed architectures like microservices.

Headless architectures consist of decoupling the frontend (presentation layer) and the backend (business logic) layers of a system.

It uses APIs to connect the frontend and backend applications, while the frontend and backend aren't tightly coupled in headless architectures, they need to communicate with each other using the APIs.

Advantages and disadvantages

This architecture separates the frontend and backend layers of a system so developers can make changes to either the frontend or backend without affecting the other component.

The frontend can be deployed independently of the backend (and vice versa). But, if they are not in sync or the compatibility is broken the whole system would fail.

The presentation layer is detached, but it still has the same drawbacks as monolithic architectures.

Modular Monolithic Architectures

A modular monolith architecture is a software development approach that uses one big codebase, like monolithic architecture. However, the codebase is divided into separate modules. Each module can be developed, tested, and maintained independently.

Each module is designed to be loosely coupled, meaning that changes to one module won’t affect any other. This allows a team to work on their own parts of the codebase without understanding the whole system. This makes it much faster and easier to make changes or add new features.

Modular monolithic architectures divide the codebase logically into many modules.

Advantages and disadvantages

With this approach, productivity is increased by using a single codebase. Because developers are able to spot and fix problems as they arise. Developing a module doesn't need any infrastructure or continuous integration, no databases are required either. Modules can be added quickly.

A simpler architecture than microservices, without needing extra tools like API Specifications or Message Brokers, Service Discovery, and so on. Yet, the project can be easily transformed into a microservice architecture by splitting the program into different services.

Unfortunately, the codebase is divided into modules but not as deployment units. This means it has the same drawbacks as monolithic architectures.

Distributed Architectures

Distributed architectures consist of multiple deployment units that work together to perform some sort of cohesive business function.

Distributed architectures consist of multiple deployment units.

The superpowers of distributed architectures usually fall within operational characteristics—things like scalability, elasticity, fault tolerance, and in some cases, performance.

Scalability and elasticity are usually at the service level in these architectural styles. Therefore, the time it takes to start and recover from errors in a modular application is significantly shorter. This time is usually measured in seconds, and sometimes even in milliseconds, instead of minutes.

Advantages and disadvantages

The ability to respond quickly to change is a superpower of distributed architectures. Breaking down the application into smaller units makes it easier to find and make changes. This also reduces the amount of testing needed and lowers the risk of deployment.

However, distributed architectures have a problem called the fallacies of distributed computing.

The fallacies of distributed computing are a set of assertions describing false assumptions that programmers new to distributed applications invariably make. These fallacies are:

The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure
Topology doesn't change
There is one administrator
Transport cost is zero
The network is homogeneous

Which One Should I Choose?

If you're deciding between a monolithic or distributed architecture, ask yourself which characteristics your system needs to support.

When systems have different architectural characteristics, they often need a distributed architecture. One example is when customers need a feature that can handle lots of users, respond quickly, be available all the time, and adapt easily. Also, a backend processing functionality that doesn’t need any of those characteristics.

Simple systems or websites usually work best with a simpler and cheaper architecture style. Complex systems that do many business functions work best with more complex distributed architectures.

Distributed architectures are good for high speed, scalability, and fault tolerance.

When choosing between a monolithic or distributed architecture, some important questions to ask yourself are:

What are the architectural characteristics that must be supported?
What are the needs that must be covered?

Monolith First

Distributed architectures are useful, but their supporters admit that using them comes with a big "Premium" problem. This means they are only useful for more complicated systems, not for all. This premium issue, which is the cost of managing services, will slow down a team, favoring a monolith for simpler applications.

A strong argument is made for starting with a monolith-first strategy. You should build a new application as a monolith, even if you think it will need a distributed architecture later.

The logical way is to design a monolith carefully, focusing on making the software modular and organizing the data correctly. Pay attention to API boundaries and how the data is stored. If you do this well, it's quite easy to transition to distributed architectures.

A more common approach is to start with a monolith and gradually peel off small services at the edges. Such an approach can leave a substantial monolith at the heart of the microservices architecture, but with most new developments occurring in the microservices the monolith is relatively quiescent.

Another common approach is to just replace the monolith entirely. Don't worry about creating a monolith that you'll eventually get rid of, especially if it helps you launch quickly.

Monolith First Strategy.

You shouldn't start with microservices unless you have reasonable experience in building a microservices system in the team.

Resources

Richards, M. (2022). Software architecture patterns. 2nd Edition.
Richards, M., & Ford, N. (2020). Fundamentals of software architecture: an engineering approach. O'Reilly Media.
Ozkaya, M. Design Microservices Architecture with Patterns & Principles [MOOC]. Udemy. https://www.udemy.com/course/design-microservices-architecture-with-patterns-principles/
Fowler, M. (2019, August 1). Software Architecture Guide. Martin Fowler. https://martinfowler.com/architecture/
Fowler, M. (2015, June 3). MonolithFirst. Martin Fowler. https://martinfowler.com/bliki/MonolithFirst.html

Acknowledgments

Cover image by @Uwe Hensel on Unsplash

Software Architect

Saúl Zalimben — Fri, 08 Sep 2023 23:37:44 +0000

Software Architect is an expert developer who design software solutions from the ground up, making high-level decisions about each stage of the process including technical standards, tools, design principles, platforms to be used, etc., leading a team of engineers to create the final product.

A software architect makes high-level design choices and frames technical standards. This might include tools, software coding standards, or platforms to be used. To be effective, a software architect needs broad (and deep) technical knowledge to make good decisions.

An architect is expected to define the architecture decisions and design principles used to guide technology decisions within the team, the department, or across the enterprise.

Types of architect

Difference between the types of architect and the style that Dave Rice exemplifies.

Architectus Reloadus is the person who makes all the important decisions. The architect does this because a single mind is needed to ensure a system’s conceptual integrity. Often, such decisions must be made early on so that everyone else has a plan to follow.
Architectus Oryzus, this kind of architect must be very aware of what’s going on in the project, looking out for important issues and tackling them before they become a serious problem.

The most noticeable part of the architect's work is the intense collaboration and guidance.

Expectations of an Architect

Defining the role of a software architect presents as much difficultly as defining software architecture. Thus, we should focus on the expectations of an architect.

There are eight core expectations placed on a software architect, irrespective of any given role, title, or job description. The first key to effectiveness and success in the software architect role depends on understanding and practicing each of these expectations.

Make Architecture Decisions

An architect is expected to define the architecture decisions and design principles used to guide technology decisions within the team, the department, or across the enterprise.

An architect should guide rather than specify technology choices An architect should instead instruct development teams to identify the strengths and weaknesses of each framework, contextualize the problem to be solved, and let the team select the best fit for it.

For example, an architect should advice about the the strong a reactive-based framework for front-end web development, hence guiding the development team in making the choice between Angular, React.js, Vue, or any of the other host of reactive-based web frameworks.

Continually Analyze the Architecture

An architect is expected to continually analyze the architecture and current technology environment, and recommend solutions for improvement.

Architects must focus their energies on continually analyzing existing architectures to maintain or improve architecture characteristics as software evolves. An architect must holistically analyze changes in technology and problem domain to determine the soundness of the architecture.

Keep Current With Latest Trends

An architect is expected to keep current with the latest technology and industry trends.

The decisions an architect makes tend to be long lasting and generally difficult to change. Understanding and following key trends helps the architect prepare for the future and also helps the architect make the correct decision.

Ensure Compliance With Decisions

An architect is expected to ensure compliance with architecture decisions and design principles.

Ensuring compliance means that the architect is continually verifying that development teams are following the architecture decisions and design principles defined, documented, and communicated by the architect.

Diverse Exposure and Experience

An architect is expected to have exposure to multiple and diverse technologies, frameworks, platforms, and environments.

An architect must at least be familiar with a variety of varying technologies. Most environments are heterogeneous, and at a minimum an architect should know how to interface with multiple systems and services, irrespective of the language, platform, and technology those systems or services are written in.

Have Business Domain Knowledge

An architect is expected to have a certain level of business domain expertise.

Effective software architects understand not only technology but also the business domain of a problem space. Without business domain knowledge, it is difficult to understand the business problem, goals, and requirements, making it difficult to design an effective architecture to meet the requirements of the business.

Possess Interpersonal Skills

An architect is expected to possess exceptional interpersonal skills, including teamwork, facilitation, and team leadership.

An architect is not only expected to provide technical guidance on the team, but also expected to lead the development teams through the implementation of the architecture. Leadership skills are at least half what it takes to become effective software architect, regardless of the role or title the architect has.

Understand and Navigate Politics

An architect is expected to understand the political climate of the enterprise and be able to navigate the politics.

Almost every decision an architect makes will be challenged. Architectural decisions will be challenged by product owners, project managers, and business stakeholders due to increased costs or increased effort (time) involved.

Architectural decisions will also be challenged by developers who feel their approach is better. In either case, the architect must navigate the politics of the company and apply basic negotiation skills to get most decisions approved.

Resources

Fowler, M. (2003). Who Needs an Architect?. IEEE Computer Society. https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf
Richards, M. (2022). Software architecture patterns. 2nd Edition.

Acknowledgments

Cover image by @kaleidico on Unsplash

Software Architecture

Saúl Zalimben — Tue, 01 Aug 2023 16:19:16 +0000

Architecture is about the important stuff… whatever that is.
--Ralph Johnson

In this rapidly evolving digital landscape, where innovation and efficiency reign supreme, the role of software architecture has become more critical than ever. Fundamentally, software architecture acts as a blueprint for the organization, operation, and communication of software parts. This ensures the robustness, scalability, and upgradability of the system.

A capable software architect creates a solid and elegant software solution that tackles complicated problems and meets user needs, much as a talented architect creates an impressive skyscraper. The complex balancing act required by software architecture ranges from choosing the right design patterns and technologies to enhancing performance and security while staying within budget and time restrictions.

Definition

Despite the lack of a clear definition, we can nevertheless benefit from the following definitions of software architecture:

"In most successful software projects, the expert developers working on that project have a shared understanding of the system design. This shared understanding is called architecture."
-- Ralph Johnson

"Software architecture involves understanding and organising a system, all of its components, their interactions, the environment in which they operate, and the core principles which will be used to design the software."
-- Anna Mleczko

"Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations."
-- Wikipedia

So, we will agree on the following definition:

Software architecture describes how an application is built including its components, how they interact with each other, the environment in which they operate, and so on.

Figure 1. Architecture consists of the structure combined with architecture characteristics (“-ilities”), architecture decisions, and design principles.

Dimensions

Software architecture consists of the structure of the system (denoted as the heavy black lines supporting the architecture), combined with architecture characteristics (“-ilities”) the system must support, architecture decisions, and finally design principles. We can refer to these components as dimensions of Software Architecture.

The structure of the system refers to the type of architecture style (or styles) the system is implemented in (such as microservices, layered, microkernel, and so on). Describing an architecture only by its structure does not wholly explain the architecture.

For example, if an architect is asked to describe an architecture and that architect responds “It’s a microservices architecture”. Here, the architect is only talking about the structure of the system but not the architecture of the system.

Knowledge of the architecture characteristics, architecture decisions, and design principles are also needed to fully understand the architecture of the system.

Figure 2. Structure refers to the type of architecture styles used in the system.

Architecture characteristics are another dimension of defining software architecture. The architecture characteristics define the success criteria of a system, which is generally orthogonal to the functionality of the system.

In general, the characteristics do not need knowledge of the functionality of the system, yet they are required in order for the system to function properly.

Figure 3. Architecture characteristics refers to the “-ilities” that the system must support

Architecture decisions define the “rules” for how a system should be constructed. For example, an architect might make an architecture decision that only the business and services layer within a layered architecture may access the database, thus restricting the presentation layer from making direct database calls.

Architecture decisions form the constraints of the system and direct the development teams on what is and what isn’t allowed.

Figure 4. Architecture decisions are rules for constructing systems.

Design Principles differ from an architecture decision in that a design principle is a guideline rather than a hard-and-fast rule.

For example, a design principle can state that the development teams should leverage asynchronous messaging between services within a microservices architecture to increase performance.

An architecture decision (rule) could never cover every condition and option for communication between services in an architecture decision, so a design principle can be used to provide guidance for the preferred method (in this case asynchronous messaging) to allow the developer to choose a more appropriate communication protocol (such as REST or gRPC) given a specific circumstance.

Figure 5. Design principles are guidelines for constructing systems.

Laws of Software Architecture

Although the range of software design is wide, there are unifying characteristics. The first law was discovered by Mark Richards and Neal Ford by accident as they kept running against it:

Everything in software architecture is a tradeoff.
—1st Law of Software Architecture

Nothing exists on a nice clean spectrum for software architects—every decision must take into account many opposing factors.

If an architect thinks they have discovered something that isn’t a trade-off, more likely they just haven’t identified the tradeoff yet.
—Corollary 1

Resources

Richards, M. (2022). Software architecture patterns. 2nd Edition.
Richards, M., & Ford, N. (2020). Fundamentals of software architecture: an engineering approach. O'Reilly Media.
Ozkaya, M. Design Microservices Architecture with Patterns & Principles [MOOC]. Udemy. https://www.udemy.com/course/design-microservices-architecture-with-patterns-principles/
Fowler, M. (2019, August 1). Software Architecture Guide. Martin Fowler. https://martinfowler.com/architecture/

Acknowledgments

Cover image by Alex wong on Unsplash
Content images were extracted from Richards, M. (2022) and Richards, M., & Ford, N. (2020).

Grafos

Saúl Zalimben — Wed, 30 Mar 2022 17:58:10 +0000

Si acabas de encontrar esta publicación, antes de continuar te recomiendo que le des un vistazo a los demás artículos de la serie.

Los grafos son estructuras de datos no lineales, utilizadas para representar datos adyacentes. Se representa como el conjunto de vértices o nodos y de aristas o arcos. Esta estructura de datos es el principal foco de estudio de la Teoría de Grafos.

Teoría de Grafos. Rama de las matemáticas y las ciencias de la computación que estudia las propiedades de los grafos.

Un grafo G es un par ordenado G=(V,E), donde:

V es un conjunto de vértices o nodos V={v1, v2, ... , vn}, y
E es un conjunto de aristas o arcos E={ {v1, v2}, {v2, v4}, ... , {vm, vn} }, que relacionan los nodos.

Un grafo no contempla las restricciones que existen para los árboles, es decir, no existe un máximo de nodos que pueden apuntar al mismo nodo, se los puede ver como una generalización de la estructura del tipo árbol.

Existen muchas analogías en el mundo real, la red de rutas de un país, la red de enlaces aéreos, red eléctrica, etc. En una red de rutas, los nudos o intersecciones representan los vértices del grafo y las rutas de unión los arcos, de modo que cada arco puede ser asociado a un dato específico tal como la distancia, el consumo de combustible, etc.

Los árboles son una especialización de un grafo, en el cual no existen ciclos, es decir, un árbol es un grafo conexo acíclico.

Operaciones elementales sobre Grafos

Insertar
Eliminar
Buscar
Recorrer

Definiciones sobre Grafos

Se denomina grafo nulo o vacío a aquel grafo que no tiene vértices ni arcos.
El orden del grafo G es igual al número de vértices, |V|.
Un grafo vacío es de orden cero.
El grado de un vértice se define como el número de vértices adyacentes que tiene el vértice.
En grafos dirigidos el grado de entrada de un vértice o nodo V es igual al número de arcos que lo tienen como extremo, es decir, igual al número de vértices adyacentes que tiene el vértice. Mientras que el grado de salida es el número de vértices adyacentes a un vértice dado.

Ejemplo de Grados en un Grafo Dirigido

Ejemplo de Grados en un Grafo No Dirigido

Dos o más arcos son paralelas si relacionan el mismo par de vértices.
Se dice que dos vértices son adyacentes si existe un arco entre ambos vértices. Si el arco es {K, L}, entonces, K es adyacente a L, y L es adyacente a K.
Un camino es una secuencia ordenada de vértices {v0, v1, v2, ..., vn}, también se conoce como el camino desde v0 hasta vn.
Un camino simple no tiene vértices repetidos excepto para el primer y último vértice.
Si en un camino simple, el primer y último vértice son iguales se conoce como un ciclo o bucle, es decir, un arco que relaciona al mismo nodo.

Ejemplo de Grafo con Bucle

Clasificación de Grafos

Los grafos pueden clasificarse acorde a sus propiedades, según su estructura, dirección y conectividad.

Sencillo y Múltiple

Un grafo G se denomina sencillo si se cumplen las siguientes condiciones:

No tiene bucles, no existe un arco tal que {vi, vi}.
No existe más que un arco para unir dos nodos, es decir, no existe más que un arco {vi, vj} para cualquier par de vértices vi, vj.

Un grafo que no es sencillo se denomina grafo múltiple.

Dirigido y No Dirigido

La teoría de grafos considera los siguientes tipos de grafos según su dirección:

Dirigidos, los vértices apuntan unos a otros; los arcos están dirigidos o tienen dirección, si existe un arco {vi, vj}, entonces se dice que existe un camino de vi a vj, pero esto no implica que existe un camino de vj a vi.

Ejemplo de Grafo Dirigido

No Dirigidos, los vértices están relacionados, pero no se apuntan unos a otros, si existe un arco {vi, vj}, entonces se dice que existe un camino de vi a vj y de vj a vi para cualquier par de vértices vi, vj.

Ejemplo de Grafo No Dirigido

Conexo y No Conexo

Finalmente, según la conectividad de los grafos, estos pueden ser:

Conexo o conectado, si existe siempre un camino que une cualquier par de vértices, todos sus vértices están conectados por un camino. Se dice que un grafo es fuertemente conexo cuando es un grafo dirigido tal que para cualquier par de nodos existe un camino que los une.

Ejemplo de Grafo Conexo

Ejemplo de Grafo Fuertemente Conexo

No Conexo o desconectado, existen vértices que no están unidos por un camino.

Ejemplo de Grafo No Conexo

Completos, Dispersos y Densos

Según el número de arcos que contiene, un grafo es completo si cuenta con todos los arcos posibles, es decir, todos los nodos están conectados con todos, es disperso si tiene relativamente pocos arcos y denso si le faltan pocos para ser completo.

Grafos Ponderados

Tanto las arcos como los vértices pueden tener asociada una etiqueta. Si la etiqueta que se asocia es un número se le llama peso, costo o longitud.
Un grafo cuyas arcos o vértices tienen pesos asociados recibe el nombre de grafo etiquetado o también conocido como grafo con pesos o ponderado.
Un grafo donde las aristas no tienen costos o pesos asociados se conoce como grafo sin pesos. También podría considerarse a un grafo sin pesos
como un grafo con pesos donde cada arista tiene un peso igual a 1.

La longitud de un camino en un grafo con pesos es la suma de los pesos de todas las aristas que componen el camino.
Por ejemplo, la siguiente figura ilustra la longitud del camino (1, 4, 7) donde (1-4) = 5,1 y (4-7) = 3,7, por lo tanto (1, 4, 7) = 8,8.

¡Gracias por leer!

Ponte en contacto en Twitter @sZalimben, y si te gusta mi contenido puedes realizar una donación invitándome un café que me será de mucha ayuda!

Árboles

Saúl Zalimben — Wed, 23 Mar 2022 16:58:23 +0000

Si acabas de encontrar esta publicación, antes de continuar te recomiendo que le des un vistazo a los demás artículos de la serie.

Los árboles son estructuras de datos no lineales, donde cada elemento del árbol es una estructura del tipo nodo (node), y hace referencia a otros nodos dentro del árbol, las conexiones entre nodos se denominan aristas o ramas o arcos (edge).

Las estructuras del tipo árbol se usan principalmente para representar datos con una relación jerárquica entre sus elementos, como son árboles genealógicos, jerarquías y agrupaciones militares, dependencias de tareas, etc.

Un árbol A es un conjunto finito de uno o más nodos (n), tales que:

Existe un nodo especial denominado raíz (n0) del árbol.
Los nodos restantes (n1, n2, ..., nn) se dividen en m >= 0 conjuntos disjuntos denominado A1, A2, ..., Am, cada uno de los cuales es, a su vez, un árbol. Estos árboles se llaman subárboles de la raíz.

La definición de árbol implica una estructura recursiva, es decir, un árbol es el conjunto de subárboles.

Definiciones sobre Árboles

Las definiciones a tener en cuenta son:

Raíz del árbol, todos los árboles que no están vacíos tienen un único nodo raíz. Todos los demás elementos o nodos se derivan o descienden de él. El nodo raíz no tiene padre, es decir, no es hijo de ningún otro nodo.
Nodo, son los vértices o elementos del árbol.
Nodo terminal o nodo hoja, son los nodos que no contienen ningún subárbol.
Nodo no terminal, todo nodo que no es hoja se asocia a uno o varios subárboles llamados descendientes o hijos. De igual forma, cada nodo tiene asociado un antecesor o ascendiente llamado padre. También se los conoce como nodos interiores o internos.

Un árbol con ningún nodo es un árbol nulo o vacío; no tiene raíz.
Todos los nodos tienen un solo padre, excepto el nodo raíz, que no tiene padre.
Los nodos de un mismo padre se llaman nodos hermanos.

Se denomina camino a una secuencia de nodos.
Existe un camino de longitud 0 de un nodo a sí mismo que se conoce como camino trivial.
Cada nodo tiene asociado un número de nivel que determina la longitud del camino desde el nodo raíz al nodo específico.
Por cada nodo en un árbol, existe un camino único de la raíz a dicho nodo. La longitud de este camino es conocida como la profundidad o altura del nodo.
La altura de un árbol es definida como la máxima profundidad de cualquier nodo del árbol. La altura de un árbol con un solo nodo es 0 (solo la raíz), mientras que la altura de un árbol vacío es –1, por conveniencia.

El peso de un árbol es el número de nodos terminales.
El grado de un nodo es definido como el número de sus hijos directos.
Un nodo hoja tiene grado cero.
Una colección de dos o más árboles se llama bosque.

Operaciones elementales sobre Árboles

Insertar
Eliminar
Buscar
Recorrer

Árbol Binario

Un árbol binario es un conjunto finito de cero o más nodos, tales que:

Existe un nodo denominado raíz del árbol.
Cada nodo puede tener 0, 1 o 2 subárboles, conocidos como subárbol izquierdo y subárbol derecho.

Un árbol binario es una especialización dentro de las estructuras del tipo árbol.

Árboles Binarios de Búsqueda

Un árbol binario de búsqueda, es un árbol binario que cumple que el subárbol izquierdo de cualquier nodo (si no está vacío) contiene valores menores que el que contiene dicho nodo, y el subárbol derecho (si no está vacío) contiene valores mayores, donde existe una relación de orden establecida entre los elementos de los nodos.

El árbol binario de búsqueda se construye teniendo en cuenta las siguientes premisas:

El primer elemento se utiliza para crear el nodo raíz.
Los elementos del árbol deben ser tales que pueda existir un orden dentro del mismo.
Todos los elementos del subárbol izquierdo son menor o igual al valor del nodo padre.
Todos los elementos del subárbol derecho son mayores que el valor del nodo padre.

Un árbol binario de búsqueda es una especialización de los árboles binarios.

Ejemplo de árbol binario de búsqueda

¡Gracias por leer!

Ponte en contacto en Twitter @sZalimben, y si te gusta mi contenido puedes realizar una donación invitándome un café que me será de mucha ayuda!

Pilas y Colas

Saúl Zalimben — Wed, 16 Mar 2022 12:38:25 +0000

Si acabas de encontrar esta publicación, antes de continuar te recomiendo que le des un vistazo a los demás artículos de la serie.

Las pilas y colas son estructuras de datos lineales, donde existen restricciones para insertar y eliminar elementos. Son casos particulares de la estructura lista, y se pueden implementar mediante vectores o listas enlazadas.

Operaciones elementales sobre Pilas y Colas

Insertar: Push -> apilar (Pila), Queue -> encolar (Cola)
Eliminar: Pop -> desapilar (Pila), Dequeue -> desencolar (Cola)

Pilas

Una Pila o Stack es un caso particular de la lista donde la inserción y eliminación de elementos se realizan solo por un extremo que se denomina cima o tope (top). Funciona exactamente como su nombre lo indica, y con numerosas analogías en la vida real: una pila de libros, una pila de monedas, pila de platos, etc.

Este comportamiento está basado en el principio "último en entrar, primero en salir", también conocido como LIFO, por su nombre en inglés "last-in, first-out", que dicta que el primer elemento que fue añadido a la pila será el último en ser removido de la misma.

Colas

Una Cola o Queue es un caso particular de la lista donde la inserción y eliminación de elementos se realizan por los extremos de la lista; las eliminaciones se realizan al principio de la lista, o el frente (front) de la misma, y las inserciones se realizan en el otro extremo, el final (rear). Algunas analogías en la vida real: cola de personas en el banco, cola de vehículos en el semáforo, etc.

Este comportamiento está basado en el principio "primero en entrar, primero en salir", también conocido como FIFO, por su nombre en inglés "first-in, first-out", que dicta que el primer elemento que fue añadido a la cola será el primero en ser removido.

¡Gracias por leer!

Ponte en contacto en Twitter @sZalimben, y si te gusta mi contenido puedes realizar una donación invitándome un café que me será de mucha ayuda!

Listas

Saúl Zalimben — Wed, 09 Mar 2022 13:41:11 +0000

Si acabas de encontrar esta publicación, antes de continuar te recomiendo que le des un vistazo a los artículos previos de esta serie, que brindan conceptos claves para comprender las Estructuras de Datos.

Las listas son estructuras de datos lineales ordenadas secuenciales de 0 o más elementos homogéneos almacenados en memoria. Donde cada elemento de la lista, excepto el primero, tiene un único predecesor y cada elemento de la lista, excepto el último, tiene un único sucesor.

Se denomina lista vacía a una lista con 0 elementos, mientras que la cantidad de elementos que posee la lista, es el tamaño de ella. El inicio de la lista se denomina cabecera, mientras que el final de la misma es el fin.

Existen dos enfoques para implementar las listas, la primera basada en vectores y la segunda basada en listas enlazadas.

Listas: Estáticas y Dinámicas

Una lista puede ser estática o dinámica dependiendo de cómo es implementada, si es implementada como un vector unidimensional, la lista es estática.

Sin embargo, si es implementada utilizando una lista enlazada, la lista es dinámica. Esta implementación hace uso de la memoria de forma dinámica, es decir, utiliza memoria acorde a su necesidad.

Operaciones elementales sobre Listas

Leer
Recorrer
Insertar
Eliminar
Ordenar
Buscar

Tipos de Listas

Acorde su implementación, pueden existir muchas variaciones, donde las operaciones son las mismas pero los detalles de implementación son diferentes.

Listas No Enlazadas

La listas no enlazadas se implementan utilizando un vector unidimensional. El primer paso para implementar este tipo de lista, es definir el tamaño del vector, que será el tamaño de la lista, una vez definido este no puede ser alterado.

Los elementos se almacenan de forma contigua en posiciones consecutivas de la memoria y para acceder a ellos se utiliza el índice, como si fuese un vector.

El principal problema de esta implementación es que se debe definir el tamaño del vector de forma a priori, si el vector se llena, no será posible agregar más elementos, entonces es necesario crear un vector más grande y migrar todos los elementos del vector original, y finalmente liberar el espacio en la memoria.

En general, los vectores no son buenos para implementar listas, considerando que las operaciones de actualización (insertar/eliminar) son costosas, además que la cantidad total de elementos a insertar suele ser desconocida.

Listas Enlazadas

Una lista enlazada es un conjunto de elementos donde cada elemento debe tener al menos dos campos: un campo que almacena el valor o dato del elemento y un campo (puntero) que contiene la posición del siguiente elemento de la lista, esta estructura recibe el nombre de nodo.

Las listas simplemente enlazadas nos permiten a partir de un elemento acceder directamente a cualquiera de los elementos que le preceden.

Existe un puntero inicial denominado cabecera (o head), que marca el comienzo de la lista, este almacena la posición del primer nodo de la lista, mientras que el puntero del último elemento no almacena ninguna dirección, es decir, es nulo, esto denota el final de la lista, y que ya no existen más elementos por recorrer.

Si se conoce la dirección al primer elemento de la lista, es posible realizar todas las operaciones sobre la misma, considerando que solo debemos navegar entre los diferentes nodos conectados por punteros.

En la figura se ilustra una lista enlazada utilizando los nodos para enlazar cada elemento de la lista.

Listas Doblemente Enlazadas

Las listas doblemente enlazadas son listas que pueden recorrerse en ambas direcciones, donde cada nodo contiene el campo de dato y a la vez dos campos punteros; uno apunta al nodo anterior, y el otro al nodo siguiente.

Como cada elemento tiene dos punteros, en consecuencia una lista doblemente enlazada ocupa más espacio en memoria que una lista simplemente enlazada para una misma cantidad de información.

Además, la lista necesita dos punteros cabecera y fin, que apuntan al primer y último nodo, respectivamente.
La variable cabecera y el puntero sig permiten recorrer la lista en el sentido normal y la variable fin y el puntero ant permiten recorrerla en sentido inverso.

Listas Circulares

Las listas circulares o listas en anillo, a diferencia de las listas enlazadas donde el último elemento apunta a nulo, en estas estructuras el último puntero del último elemento apunta al primer elemento de la lista, de forma que es posible iterar sobre la lista, sin necesidad de volver acceder desde la cabecera.

¡Gracias por leer!

Ponte en contacto en Twitter @sZalimben, y si te gusta mi contenido puedes realizar una donación invitándome un café que me será de mucha ayuda!

Vectores (Array o Arreglos)

Saúl Zalimben — Fri, 04 Mar 2022 17:58:12 +0000

Los Vectores (Arrays o Arreglos) son estructuras estáticas lineales finitas ordenadas secuencialmente, y de datos homogéneos, es decir, del mismo tipo de dato y se puede acceder directamente a cada elemento del mismo mediante el uso de índices, donde el índice de un elemento (1, 2, ..., n) designa su posición dentro del vector. Es una secuencia de posiciones de la memoria a las que se puede acceder directamente.

En general, los índices de un vector comienzan en 0, pero este puede diferir acorde al lenguaje de programación utilizado.

Operaciones elementales sobre Vectores

Asignar
Leer
Recorrer (Acceso secuencial)
Insertar
Eliminar
Ordenar
Buscar

Cabe resaltar que otras operaciones pueden ser definidas sobre esta estructura como mezclar, filtrar, copiar, etc., acorde a las necesidades del problema por resolver.

Vector Multidimensional

Un vector multidimensional puede tener n cantidad de dimensiones, en consecuencia se dice que es n-dimensional. También se lo puede ver como un vector de vectores de vectores, cuyos elementos pueden ser referenciados por dos o más índices.

Vector Bidimensional

Un vector multidimensional de 2 dimensiones, es decir, un vector bidimensional recibe el nombre de matriz o tabla, es un caso especial del vector multidimensional,

El mismo puede ser considerado como un vector de vectores. Por consiguiente, es un conjunto de elementos homogéneos, en el cual existe un orden y en el que se necesita especificar dos índices para poder identificar cada elemento, es decir, es necesario definir la fila y la columna en la matriz para poder acceder a cada elemento, Matriz[fila][columna].

Vector n-dimensional

Los conceptos de rango de índices y número de elementos se pueden ampliar directamente desde vectores de una y dos dimensiones a vectores de orden más alto. Un vector puede ser definido de tres, cuatro hasta de n-dimensiones.
En general, un vector n-dimensional requiere que los valores de los n índices sean especificados a fin de identificar unívocamente un elemento. Si cada componente tiene n índices, se dice que el vector es de n dimensiones. En la figura se observa un vector de 3 dimensiones, un Cubo.

Cubo[0][0][0] representa el elemento del cubo resaltado en azul; mientras que el elemento Cubo[2][2][0] esta resaltado en verde.

¡Gracias por leer!

Ponte en contacto en Twitter @sZalimben, y si te gusta mi contenido puedes realizar una donación invitándome un café.

Estructura Datos. Conceptos

Saúl Zalimben — Wed, 23 Feb 2022 19:54:09 +0000

Si acabas de encontrar esta publicación, antes de continuar te recomiendo que le des un vistazo a Introducción a Estructuras de Datos el cual brinda una introducción a los conceptos preliminares para comprender las Estructuras de Datos.

Una Estructura de Dato es una colección de datos que pueden ser caracterizados por su organización y las operaciones que se definen en ella, es la implementación de un TDA en algún lenguaje de programación, es decir, la representación de algún tipo de dato y de sus operaciones asociadas.

Simples y Compuestos

Se dice que son tipos simples o primitivos cuando se definen sobre sí mismos, es decir, no están compuestos de otras estructuras de datos, e.g. números enteros, reales y carácter (char). Mientras que aquellas estructuras que se definen en función a otros se denominan compuestos o agregados, es decir, están construidos basados en tipos de datos primitivos, e.g. el tipo cadena (string) basado en el conjunto de caracteres.

Cada lenguaje de programación dispone de su propio conjunto de tipos primitivos y compuestos

Estáticos y Dinámicos

Las estructuras de datos estáticas son aquellas en las que el tamaño ocupado en memoria es fijo, este se define antes de que el programa se ejecute y el tamaño reservado de memoria no puede ser modificado durante la ejecución del programa.

Mientras que las estructuras de datos dinámicas se pueden ampliar y comprimir a medida que se requieran durante la ejecución del programa, es decir, pueden reservar y liberar espacios de memoria de forma dinámica.

En la siguiente figura se observa que la estructura Vector, tiene un tamaño igual a la cantidad de letras del abecedario, por lo tanto ya no se pueden agregar más elementos, esta estructura es estática. Por otro lado, la estructura Grafo está compuesta por otras estructuras de datos dinámicas denominadas Nodos, que pueden ser instanciadas en cualquier momento, es decir, se pueden agregar más elementos en tiempo de ejecución del programa, esta estructura es dinámica.

Lineales y No lineales

Las estructuras de datos lineales son aquellas donde los elementos ocupan lugares sucesivos en la estructura y cada uno de ellos tiene un único sucesor y un único predecesor.
Sin embargo las estructuras de datos no lineales no cumplen con esta restricción.

¡Gracias por leer!

Ponte en contacto en Twitter @sZalimben, y si te gusta mi contenido, puedes invitarme un café.

Introducción a la Estructura de Datos

Saúl Zalimben — Wed, 16 Feb 2022 15:14:44 +0000

Uno de los aspectos más importantes de la ciencia de la computación es la creación de nuevos tipos de datos que sean apropiados para resolver problemas específicos del mundo real.

Las estructuras de datos son el elemento fundamental de la computación, son construcciones utilizadas para almacenar colecciones de datos y manipularlos. Todos los algoritmos manipulan datos, y éstos deben estar diseñados y estructurados adecuadamente para que puedan conectarse entre ellos.

Preliminares

Tipo

Un tipo es un conjunto de valores que puede poseer una variable, por ejemplo una variable del tipo booleano puede contener dos posibles valores, falso o verdadero, o bien una variable del tipo entero, que puede tomar el valor de todos los números enteros.

Tipo de Dato

Un Tipo de Dato es un tipo junto a todas las operaciones elementales que manipulan dicho tipo, un conjunto de funciones básicas que uno puede aplicar a estos valores, e.g. para los números enteros se pueden aplicar las operaciones básicas de la aritmética (suma, resta, multiplicación y división).

Abstracción

Es el conocimiento que se tiene de una cosa prescindiendo de los detalles que están ligados a ella. Conocemos un objeto viéndolo, sabemos qué es sin necesidad de ver su interior, su implementación o la forma de construcción.
La abstracción de datos consiste en ocultar las características de un objeto, de manera a que solamente utilizamos el nombre del objeto para hacer referencia a él. Es la capacidad para encapsular y aislar la información del diseño y ejecución.

Encapsulación

Proceso de almacenar en un mismo compartimento los elementos de una abstracción, que constituyen su estructura y comportamiento.

Tipo de Dato Abstracto (TDA)

Un TDA es la definición de un tipo de dato como un componente que está definido en términos de su tipo y el conjunto de operaciones sobre ese tipo, en donde las operaciones no se encuentran implementadas, solo su comportamiento, es decir, se define qué debe hacer y no el cómo. Los detalles de implementación están ocultos y encapsulados para el usuario del TDA.

Generalmente, los TDA son conceptos matemáticos o lógicos que pueden ser implementados en diferentes máquinas usando diferentes lenguajes. Son muy flexibles y no dependen de ningún lenguaje ni máquina.

En cada lenguaje de programación, se implementan los TDA utilizando diferentes métodos y lógicas, es posible realizar todas las operaciones asociadas que están definidas para un TDA independientemente del lenguaje utilizado. Por ejemplo, en el Lenguaje C, los TDA se implementan principalmente con estructuras (structure). Mientras que en los Lenguajes C++ o Java, se implementan mediante clases (class). Sin embargo, las operaciones son comunes en todos los lenguajes de programación.

Ejemplos de Estructuras de Datos

Write Git Commit Messages

Saúl Zalimben — Thu, 10 Feb 2022 15:05:33 +0000

This article assumes you already understand basic Git Workflow. If not, I suggest reading previous articles on this series.

Why should you write good commit messages?

"When a programmer first creates his code, only he and God know how it works, a few months down the line and only God knows."

Not sure who said this phrase, but it is so accurate. The same thing happens when we write Commit Messages.

We're often pressed for time when it comes to Git commits, and so we write something random or without meaning in our commit message like "Fixes" or "WIP", even memes, memes!

I challenge you to figure out the following commit message:

Minor fixes

Perhaps the most common commit message, but what does it mean exactly? We can ask ourselves so many questions about it.

Minor fixes on what?
What were the fixes?
Why fixes were needed?
... and many more.

Writing commit messages that are not telling the whole story is a bad practice. Commit messages should be helpful and make sense so people working on the project understand the changes from the message itself.

Using the right commit message helps make it more meaningful and it provides clarity on your updated piece of code, for everyone.

It seems like writing good commit messages is easy and everyone understands the benefits of doing it. Yet, you can find messages like the above.

Commit messages can communicate why a change was made, they help the narrative of the project. Poetically, commit messages are telling the story of the project, and you can read it using the git log command.

Don't destroy a good story, build one.

How to write good commit messages?

There are several conventions used by different teams, projects, and developers. I'll just give you some general guidelines and pointers, but it's up to you to decide which convention you want to follow.

If you work for a company or contribute to open source, you have to adapt to their convention.

Check out this thread for some commit message conventions, discussion proposed by @bolajiayodeji.

6 General Rules

Capitalization and Punctuation: Capitalize the first word and do not end in punctuation.
Mood: Use the imperative mood in the subject line. Example: Add fix for dark mode toggle state.
Type of Commit: Specify the type of commit. It is recommended and can be even more beneficial to have a consistent set of words to describe your changes. Example: Bugfix, Update, Refactor, Bump, and so on.
Length: The first line should be no longer than 50 characters, and the body should be restricted to 72 characters.
Content: Be direct, try to cut filler words and phrases in these sentences. Examples: though, maybe, I think, kind of.
Issue Tracker: If you use an issue tracker, add a reference(s).

Journalism Questions

When a journalist is writing an article they look to answer who, what, where, when, why, and how. It is similar when we are writing commit messages, we need to answer some questions about the changes.

Sometimes it is not easy to put in words the changes that we made. To simplify that process and come up with thoughtful commits, consider the following "journalism" questions:

Why are the changes necessary?
How do changes address the issue?
Why have I made these changes?
What effect have my changes made?
What side effects do the changes have?
What are the changes in reference to?

Answering these questions will help you to write a better commit message.

Commit Message Template

I merged the 6 General Rules with Journalism Questions, to have a well-format compact template:

#                Header (up to 50)              #  
<issue|type>: <title>

#                Body (up to 72)                           #   
<description>

# Description of changes. Answer the following questions:
# Why are the changes necessary?
# How do changes address the issue?
# Why have I made these changes?
# What effect have my changes made? 
# What side effects do the changes have?
# What are the changes in reference to?

Where:

issue|type: If you are using an issue tracker, set the reference(s), otherwise, set the commit type.
title: " Issue name or a short summary of changes."
description: " More detailed explanatory text, if necessary. It should answer the template's questions."

The result is:

JIRA-921: Remove the X

X was removed because it is obsolete

Git Configuration

Templates can be added to your Git Configuration, so every time you make a commit:

git commit

the commit message editor will display the template, and you only have to update it. To tell Git to use the template file (globally), you can use the following command:

git config --global commit.template git-message-template.txt

By default, Git uses whatever you’ve set as your default text editor to create and edit your commit and tag messages. To change that default to something else, you can use the core.editor setting:

 git config --global core.editor vim

Conclusion

The most important part of a commit message is that it should be clear and meaningful. It helps you communicate and collaborate with your team.

There is an existing set of agreed-upon standards you can follow. But, you can tweak the convention to get a more appropriate convention for your team or project.

Thanks for reading! Let me know what you think in the comment section, don't forget to leave a ❤️ and share it within your network!

Connect with me on Twitter @sZalimben, and if you like my content you can Buy Me a Coffe.

Resources

Git Branching Strategy

Saúl Zalimben — Mon, 17 Jan 2022 14:56:33 +0000

In this post, we will go over Git Branching Strategy and Git Workflows, it will not focus on comparing Git Branching Models, nor explain one by one since that story has been told more than once, but you will be able to find the links and examples in this post.

If you're looking for a Git Tutorial, I recommend my previous post on it, Git Explained by DEV Community.

Introduction

Git has become the de-facto standard for source control management. Branching is an essential feature of a VCS (version control system), that allows developers to diverge from the main branch and continue their work on multiple feature branches in parallel, without affecting the main branch.

Git does NOT enforce any particular branching strategy.

Git allows teams to tweak Git Workflows, as it fits the team’s culture. As a result, teams and organizations are often required to choose a particular branching strategy that matches their release cadence, while optimizing productivity depending on their team size, strengths and weaknesses.

Some Git Branching Models are the best in certain situations, but none can be considered the "best", therefore, it is important to mention that there is no such thing as "Best Git Branching Model" or "Best Git Workflow" or "Best Gitflow" or any of its variations, but what you may find is "A successful Git branching model for X situation" which is true as Git Workflows are flexible and change as needed, so in certain situations, one Git Workflow is better than others, simple as that.

There is no such thing as "Best Git Branching Model".

Git Workflows

A Git Workflow is a recipe or recommendation for how to use Git to accomplish work in a consistent and productive manner, and deal with the branching problem.

Gitflow is not Git Workflow
In some cases, the term Gitfow is used to refer to the actual Git Workflow used by a team or organization, but this is incorrect. A Git Workflow could be any of the Git Branching Strategies that the team or organization is using and a Gitflow is a type of Git Workflow.

Git Branching Models

Here a list of some well-defined models:

Git Commonflow

Gitflow

GitLab Flow

GitHub Flow

Trunk Based Development

This post performs a comparative analysis of the three most popular branching strategies, namely, Git Flow, Trunk Based Development and GitHub Flow.

Custom Git Branching Models

There are also several custom Git Branching Models; In some cases, teams take a well-defined git workflow and modify it based on the needs of the project. Therefore, it is very common to find mutations of the git branching models mentioned above.

Example: Git Environment Branching Flow

This strategy focuses on branches per environment (development, staging and production), where each branch is restricted by rules.

Initially, three branches are required: staging, develop and master (or main).

Branch	Environment
develop	Development
staging	Staging
master	Production

Conclusion

There is No Silver Bullet for Git Branching, each strategy has a list of pros and cons. Choosing the "best" requires researching the well-defined models and the needs of the project, and checking if the model covers all you need or maybe a custom model based on a well-defined one.

Also, it is okay to make mistakes when selecting the correct model, if that happens remember you can always modify the current strategy or move to another one, Git allows that.

Let me know what you think in the comment section, please comment with your suggestions and feedback. If you like this article, don't forget to leave a ❤️ and share it within your network, and if you want to share your own recommended Git Workflow, please do so!