Nivel apropiado para aquellas personas que todavía ni siquiera han comenzado a usar redes, software o hardware libres. Siguiendo este nivel aprenderán desde Historia de Internet y de Informática hasta cómo instalar un sistema GNU en su ordenador.
El momento de la verdad se acerca… hemos dejado atrás la primera fase del revelado, que de por sí apenas implica el uso de ningún software; se trata de un momento de observación y de trazado de estrategias que tendremos que llevar a cabo posteriormente aprovechando al máximo el programa que decidamos utilizar. En este caso, Darktable, del que examinaremos a continuación sus numerosas peculiaridades.
Si en el anterior capítulo le dábamos un repaso a los módulos más básicos destinados a la manipulación de la luminosidad, en el de esta semana vamos a centrarnos en los plugins más avanzados, diseñados para trabajar la luz de una manera un tanto más sofisticada. Terminaremos el artículo revisando el resto de plugins de luminosidad, que no encajan en la categoría «básica» ni en la «avanzada». Desclasados ellos.
Este va a ser un capítulo breve (o eso espero) pero no por ello menos importante (y esto lo espero aún más). Vamos a recapitular todo lo aprendido hasta ahora sobre las particularidades de Darktable en torno al revelado en color, y a completar el esquema del flujo de trabajo en esta fase tan importante. Y esto nos servirá para cerrar el que será el penúltimo capítulo de la serie. ¡Ya no queda nada!
Si estás trabajando en un proyecto de software, ya sea solo o en un equipo, considero imprescindible el uso de un control de versiones. En el caso de que estés solo en ese proyecto no tendrás problema con lo que haces en el repositorio, puedes hacer tantos commits como quieras, no te tienes que preocupar de si habrá una nueva versión en remoto ni nada por el estilo. Sin embargo, ¿qué sucede cuando trabajas con un equipo? ¿Qué sucede cuando sois varios los que estáis metiendo mano en el mismo repositorio?
Una vez ya hemos visto lo referente al trabajo con ramas en Git que comentamos en los artículos anteriores, Ramificaciones, flujo de trabajo y etiquetas, estamos en disposición de enfrentarnos a cualquier proyecto cuyo control de versiones se realice con GIT. Sin embargo, no quería terminar esta serie de artículos sobre GIT y GitHub, sin comentar un aspecto muy interesante, como son los submódulos, y las posibilidades que nos ofrecen.
Es habitual, cuando estás trabajando en un proyecto, apoyarte en el trabajo de terceros. Utilizar bibliotecas externas a tu proyecto, iconos, temas, o lo que consideres. En este caso, lo interesante es poder tener este otro proyecto dentro del tuyo propio pero sin que un proyecto afecte al otro. ¿Cual sería el objetivo? Realizar el control de versiones del proyecto principal de forma independiente al proyecto secundario.
¿Como resolver esta situación? Para esto tenemos los submódulos en Git.
Hola, soy Ish Milan, un joven linuxero, administrador de sistemas y estudiante de desarrollo de software. Hace unos meses me enteré de este nuevo proyecto y decidí unirme a el para ayudar en todo lo posible al mundo del software libre. Me parece que crear comunidades es un pilar fundamental, tanto para mejorar plataformas o herramientas como a nosotros mismos, aprendiendo, descubriendo nuevas técnicas para desarrollar nuestro trabajo.
