IT Infrastructure Architecture - Infrastructure Building Blocks and Concepts

Alice and Bob Learn Application Security

 

Open–closed principle (OCP)

Sobre el principio

El principio OCP, por sus siglas en inglés "Open-Closed Principle", es uno de los cinco principios SOLID de la programación orientada a objetos. Este principio establece que una entidad de software, ya sea una clase o un módulo, debe estar abierto para la extensión pero cerrado para la modificación. Es decir, se debe poder extender su comportamiento sin necesidad de modificar el código fuente original.

En el mundo real, podemos hacer una analogía con un edificio. Imagine que tiene una casa y desea agregar una habitación extra. Si el diseño de la casa no se hizo pensando en la posibilidad de agregar una habitación, es probable que tenga que modificar la estructura original, lo que podría ser costoso y requerir mucho tiempo. Sin embargo, si el diseño original fue hecho pensando en la posibilidad de futuras ampliaciones, agregar una habitación extra sería mucho más sencillo y económico. De manera similar, en programación, al aplicar el principio OCP, el diseño de la entidad de software debe ser hecho pensando en la posibilidad de futuras extensiones sin necesidad de modificar su código fuente original.

Es importante aplicar el principio OCP porque permite desarrollar software más robusto, mantenible y escalable. Al seguir este principio, se evitan cambios innecesarios en el código fuente original que podrían generar errores inesperados o problemas de compatibilidad. Además, facilita la creación de nuevas funcionalidades sin necesidad de modificar el código existente, lo que ahorra tiempo y recursos.

Sin embargo, también existen algunas desventajas del principio OCP. En ocasiones, al diseñar una entidad de software para ser extensible, se pueden crear abstracciones innecesarias y complejidad adicional en el código. Además, en algunos casos, la implementación de una funcionalidad específica puede ser más compleja debido a la necesidad de respetar la estructura y abstracciones previas.

Ejemplo del uso del OCP

En este ejemplo, la clase "LogManager" es la encargada de registrar los mensajes de log y recibe una lista de objetos que implementan la interfaz "ILogger". La interfaz "ILogger" define el método "Log" que será implementado por cada uno de los loggers disponibles, en este caso, "ConsoleLogger" y "FileLogger".

De esta forma, si en el futuro queremos agregar un nuevo logger, simplemente debemos crear una nueva clase que implemente la interfaz "ILogger" y definir la implementación de "Log". Luego, podemos agregar el nuevo logger a la lista que se le pasa al constructor de "LogManager".

De esta forma, estamos cumpliendo con el principio OCP, ya que nuestro código está cerrado para modificaciones pero abierto para extensiones. Podemos agregar nuevos loggers sin necesidad de modificar el código original de "LogManager".

En resumen...

El principio OCP establece que una entidad de software debe estar abierta para la extensión pero cerrada para la modificación. Al aplicar este principio, se logra un código más robusto, mantenible y escalable. La analogía con el mundo real nos muestra la importancia de diseñar pensando en futuras ampliaciones. Sin embargo, es importante tener en cuenta que también existen desventajas, como la creación de abstracciones innecesarias y complejidad adicional en el código.

Control de versiones

¿Qué es un sistema de control de versiones?

Un sistema de control de versiones (VCS) es una herramienta que permite a los desarrolladores rastrear y administrar los cambios realizados en el código fuente de un proyecto de software a lo largo del tiempo. 

Revisando la historia, el primer sistema de control de versiones (VCS) fue SCCS (Source Code Control System), creado por Marc Rochkind en los laboratorios Bell de AT&T en la década de 1970. SCCS permitía a los desarrolladores guardar y recuperar versiones anteriores del código fuente, y también permitía a varios desarrolladores trabajar en el mismo código fuente sin sobrescribir los cambios de los demás. SCCS se convirtió en una herramienta muy popular en los años 80, pero fue reemplazado por CVS (Concurrent Versions System) a mediados de la década de 1990. A partir de ahí, se han desarrollado muchos otros sistemas de control de versiones, como Subversion, Git y Mercurial, cada uno con sus propias ventajas y desventajas.

Sistemas de control de versiones más populares

Los sistemas de control de versiones más populares en el mercado son:

1. Git: Es un sistema de control de versiones distribuido, rápido y escalable. Es el más utilizado por la comunidad de desarrolladores en todo el mundo.
2. Subversion (SVN): Es un sistema de control de versiones centralizado, utilizado ampliamente en proyectos de código abierto. Aunque ya no es tan popular como Git, sigue siendo utilizado por algunas empresas y organizaciones.
3. Mercurial: Es un sistema de control de versiones distribuido, similar a Git. Aunque no es tan popular como Git, es utilizado por algunos desarrolladores y empresas.
4. Perforce: Es un sistema de control de versiones centralizado, utilizado principalmente en la industria de los videojuegos y la animación.
5. CVS (Concurrent Versions System): Fue uno de los sistemas de control de versiones más populares en los años 90 y principios de los 2000. Aunque ha sido reemplazado en gran medida por Git y SVN, todavía hay algunos proyectos que lo utilizan.

¿Qué información podemos obtener de un sistema de control de versiones?

Un buen sistema de control de versiones permite responder la siguientes preguntas:

• ¿Quién ha hecho cambios en esta línea de código?
• ¿Cuál es la diferencia entre la versión actual y la de la semana pasada?
• ¿Cuántas líneas de código hemos cambiado en este release?
• ¿Qué archivos hemos cambiado con mayor frecuencia? 

Las respuestas a las preguntas anteriores ofrecen un tipo de información que tiene un valor incalculable para fines relacionados con el rastreo de fallos, las auditorías, el rendimiento y la calidad.

Flujos de trabajo

En un entorno de trabajo colaborativo se hace necesario el uso de un flujo de trabajo, ya que permiten a los equipos trabajar de manera más eficiente, coordinada y organizada, lo que se traduce en un código fuente más sólido y de alta calidad. Entre los más populares flujos de trabajo tenemos:

• GitFlow: Un flujo de trabajo basado en Git que utiliza ramas para gestionar el ciclo de vida del software, incluyendo características, versiones y correcciones de errores.
• GitHub Flow: Un flujo de trabajo simplificado que utiliza ramas para nuevas características y correcciones de errores, y utiliza pull requests para revisión y aprobación antes de fusionar los cambios en la rama principal.
• Centralized Workflow: Un flujo de trabajo centralizado donde todos los desarrolladores colaboran en una rama principal, lo que facilita el control de versiones y la gestión del código fuente.
• Feature Branch Workflow: Un flujo de trabajo basado en ramas, donde cada nueva característica o corrección de errores se implementa en una rama separada, antes de fusionar los cambios en la rama principal.
• Release Flow: Un flujo de trabajo que se enfoca en la gestión de versiones, donde se crean ramas separadas para cada versión del software, lo que permite la implementación de correcciones de errores y la adición de nuevas características sin afectar la versión actual.
• Trunk-Based Development: Donde todos los desarrolladores trabajan en la misma rama principal, y los cambios se integran continuamente. Este enfoque es adecuado para proyectos pequeños y medianos con entregas rápidas y frecuentes.

En resumen 

Un sistema de control de versiones es una herramienta vital para los desarrolladores, permitiendo rastrear y administrar los cambios realizados en el código fuente de un proyecto de software a lo largo del tiempo. La historia de los VCS se remonta a la década de 1970, y desde entonces se han desarrollado muchos otros sistemas, como Git, Subversion, Mercurial y Perforce. Estos sistemas permiten a los desarrolladores responder preguntas importantes sobre el código fuente, lo que es especialmente útil para fines relacionados con el rastreo de fallos, las auditorías, el rendimiento y la calidad. Además, hay varios flujos de trabajo populares, como GitFlow, GitHub Flow, Centralized Workflow, Feature Branch Workflow, Release Flow y Trunk-Based Development, que permiten a los equipos trabajar de manera más eficiente, coordinada y organizada. Para conocer más sobre los sistemas de control de versiones y los flujos de trabajo.

---

¡Gracias por llegar hasta aquí!

Get SQL Server Database Size, Location for all Databases

Here are the SQL Server queries to get all SQL Server database data file and log file Size, Location:

 SELECT DB_NAME(database_id) AS [Database Name],

       Name AS [Logical Name],

       Physical_Name AS [Physical Name],

       (size*8)/1024 AS [Size - MB]

 FROM sys.master_files WHERE database_id > 4







If you want to combine Data File & Log File Size:




SELECT DB_NAME(database_id) AS [Database Name],

       SUM((size*8)/1024) [Size - MB]

FROM sys.master_files

WHERE database_id > 4

group by DB_NAME(database_id)

order by DB_NAME(database_id)




This will give you all Databases attached to a specific instance, excluding SQL Server system Databases like Master, Model, etc. (So we’ve: WHERE database_id > 4)

Source: https://www.sharepointdiary.com/2013/03/get-sql-server-database-size-location.html