Instalar Subversion en Dropbox

Dado que no es precisamente económico para un particular dispuesto a hacer sus pequeños proyectos personales de software desde diferentes localizaciones disponer de un servidor equipado con un sistema de control de versiones mediante el cual pueda mantener alineadas todas las versiones del mismo proyecto en todos los dispositivos desde los que trabaje, muestro aquí en unos simples pasos cómo montar un sistema de gestión de versiones online gratuito gracias a la combinación Subversion + Dropbox:

  1. Instalar Dropbox y abrir cuenta si no se dispone ya de una.
  2. Instalar TortoiseSVN.
  3. Crear carpeta ‘svn’ dentro de la carpeta ‘Dropbox’ instalada en nuestro PC.
  4. Hacer click derecho sobre la carpeta ‘svn’ y seleccionar TortoiseSVN > Create repository here.
  5. Elegir la opción de ‘Create folder structure’ y después dar ‘OK’. Con esto hemos creado el repositorio.
  6. Para sincronizar nuestros proyectos con el repositorio: sobre la carpeta en la que almacenemos nuestros proyectos hacemos click derecho y seleccionamos TortoiseSVN > Import.
  7. Ponemos como URL del repositorio la dirección de la carpeta ‘svn’ creada en el paso 3. (Ejemplo: file:///D:/Dropbox/svn)
  8. Aceptamos y comprobamos cómo se suben los ficheros del proyecto al repositorio.
  9. Sobre la carpeta de nuestros proyectos, hacemos click derecho y elegimos ‘SVN Checkout…’
  10. En ‘URL of repository’ ponemos la misma del paso 7 y en ‘Checkout directory’ la carpeta de nuestros proyectos, quitando el ‘/svn’ que añadirá por defecto al final de la URL y pulsamos ‘OK’.
  11. Ya tenemos lista la carpeta de nuestros proyectos para hacer Commits y Updates haciendo click derecho sobre ella. :)

Si trabajamos con un IDE de desarrollo que incorpora plugins para Subversion no es necesario sincronizar manualmente la carpeta de nuestros proyecto (pasos 6 a 11), sino que sería suficiente con indicar en la configuración del plugin la dirección del repositorio (carpeta ‘svn’ de ‘Dropbox’).

Por cada uno de los PCs en los que vayamos a trabajar, habrá que repetir los pasos 1, 2, 9 y 10. Los demás pasos son sólo para el primer ordenador.

¿Por qué los jefes de proyecto ganan más que los programadores?

Estaba preparando un artículo sobre gestión básica de requisitos en los proyectos de software, pero he preferido dar un volantazo y exponer mi punto de vista sobre un asunto que se discute estos días en la red sobre por qué los jefes de proyecto cobran más que los programadores.

Según he podido ver en artículos como éste (bien es cierto que tan solo se trata de una traducción al español de la respuesta dada por un internauta en stackexchange), culpan de este supuestamente injusto hecho ni más ni menos que a nuestra sociedad [sic], aduciendo una visión de la remuneración orientada a la jerarquía y un modelo de gestión poco menos que represor. Como prueba de ello, completan su análisis exponiendo el vocabulario habitual entre los jefes de proyecto: recursos, procesos, eficiencia, control, etc. En contraposición expone el caso de las compañías de software que funcionan de forma análoga a como lo hacen los estudios cinematográficos, en los que cada miembro es remunerado en función del valor que aporta al producto final independientemente de su posición en la jerarquía.

En mi opinión en esta manera de explicar por qué los jefes de proyecto ganan más que los programadores radica un profundo desconocimiento de las leyes del mercado. El hecho de que el trabajo de los programadores sea más complicado o no que el de los jefes de proyecto es aquí completamente irrelevante. El problema radica en la escasez, o lo que es lo mismo, en la ley de la oferta y la demanda. Un jefe de proyecto debe tener una serie de habilidades que, independientemente del valor que aporten al producto final (muy difícil de medir ya que se trata en su mayoría de un trabajo de gestión) y de la complejidad que implica el desarrollo de dichas habilidades, lo cierto es que escasean más que las habilidades aportadas por los programadores.

Con esto no quiero decir que cualquiera pueda programar o que los buenos programadores abunden, nada más lejos de mi intención. Lo que quiero decir es que si cualquiera no puede programar, menos aún puede ser jefe de proyecto. Y si los buenos programadores escasean, más aún escasean los buenos gestores.

Google lanza su propio lenguaje de programación

Se llama Go, y aunque aún no se confía en una inmediata incorporación al entorno productivo, ya se sabe que Google no es una empresa conocida precisamente por su falta de ambición. Aún así surgen varias preguntas acerca del nuevo producto:

¿Es realmente necesario un nuevo lenguaje de programación?

¿Qué características nuevas aportará?

¿Estará enfocado al entorno académico o al empresarial?

¿Vendrá acompañado de una plataforma de desarrollo competente?

Vía | Genbeta | Barrapunto