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

Eligiendo un camino: ¿Arquitecto de Software o Líder Técnico?

¿Cuál es la diferencia entre un Arquitecto de Software y un Líder Técnico?

La diferencia entre un arquitecto de software y un líder técnico puede variar según la organización, el proyecto y el contexto específico en el que se encuentren. Sin embargo, a grandes rasgos, se pueden identificar algunas diferencias clave:

1. Enfoque: Un arquitecto de software se enfoca principalmente en la arquitectura y diseño de soluciones de software. Su objetivo es definir y garantizar la integridad, calidad y viabilidad técnica del sistema. Por otro lado, un líder técnico se enfoca en liderar y gestionar un equipo técnico, así como coordinar su trabajo con otros equipos y áreas de la organización.
2. Responsabilidades: El arquitecto de software es responsable de diseñar y mantener la arquitectura de software, tomar decisiones técnicas clave, y garantizar la calidad y la escalabilidad del sistema. El líder técnico es responsable de liderar y motivar al equipo técnico, coordinar sus tareas, establecer metas y objetivos, y asegurarse de que se cumplan los plazos y presupuestos del proyecto.
3. Conocimientos técnicos: Ambos roles requieren un conocimiento sólido de la tecnología y las herramientas utilizadas en el proyecto, pero un arquitecto de software se centra más en la comprensión de las necesidades técnicas del sistema, mientras que un líder técnico se enfoca en la gestión y liderazgo del equipo.
4. Nivel de experiencia: En general, un arquitecto de software se considera un rol más especializado y senior, con experiencia en la arquitectura y diseño de sistemas complejos y en la toma de decisiones técnicas críticas. El líder técnico, aunque también es un rol senior, puede requerir menos experiencia técnica y enfocarse más en la gestión de equipos y proyectos.

En resumen, mientras que un arquitecto de software se enfoca en la arquitectura y diseño de soluciones de software, un líder técnico se enfoca en liderar y gestionar un equipo técnico, coordinando su trabajo y asegurándose de que se cumplan los objetivos del proyecto. Ambos roles son importantes para el éxito de un proyecto de software y a menudo trabajan juntos para lograr los objetivos técnicos y empresariales.

¿Puedo pasar de Desarrollador de Software a Líder Técnico o necesito pasar antes por el rol de Arquitecto de Software?

Es posible pasar de desarrollador de software a líder técnico sin necesidad de haber desempeñado previamente el rol de arquitecto de software. Sin embargo, hay algunas habilidades y conocimientos que son importantes para ser un buen líder técnico y que pueden ser desarrollados a través de la experiencia previa en el diseño y la arquitectura de software.

Algunas habilidades que son importantes para un líder técnico incluyen la capacidad de comunicarse eficazmente con el equipo de desarrollo y otros stakeholders, la capacidad de liderar y motivar a un equipo, la capacidad de tomar decisiones técnicas y la capacidad de resolver conflictos. También es importante tener una comprensión sólida de los principios y prácticas de la ingeniería de software, incluyendo la metodología de desarrollo de software, los patrones de diseño y las mejores prácticas de codificación.

Si bien la experiencia previa en arquitectura de software puede ser útil para desarrollar estas habilidades, no es un requisito previo para convertirse en líder técnico. En su lugar, puede ser útil buscar oportunidades para liderar pequeños equipos o proyectos dentro de su función de desarrollador de software actual, y buscar capacitación y orientación en habilidades de liderazgo y gestión de proyectos. También puede ser útil buscar mentores en su empresa o en la comunidad de desarrollo de software para obtener asesoramiento y orientación sobre cómo desarrollar sus habilidades de liderazgo técnico.

Material de lectura

The bearing of a child takes nine months, no matter how many women are assigned

La frase se refiere al hecho de que hay ciertas tareas que requieren un cierto tiempo para completarse, independientemente de cuántas personas estén trabajando en ellas. En este caso, la frase se refiere al embarazo y al parto: sin importar cuántas mujeres trabajen en un embarazo, el proceso de gestación de un bebé generalmente dura aproximadamente nueve meses.

La frase se puede interpretar en términos más amplios como un recordatorio de que algunas tareas simplemente no pueden acelerarse o dividirse en fragmentos más pequeños para que se completen más rápidamente. Algunas tareas requieren una cantidad específica de tiempo y esfuerzo para completarse, y no importa cuántas personas estén trabajando en ellas, esa cantidad de tiempo y esfuerzo no puede ser reducida. Por lo tanto, la frase sugiere que es importante tener una comprensión realista del tiempo y los recursos que se necesitan para realizar una tarea y no tratar de acelerarla o hacerla más rápida simplemente aumentando la cantidad de personas que trabajan en ella.

El programador pragmático

 

Código Sostenible - Cómo desarrollar Software fácil de mantener

 

Code complexity vs. Experience