desarrollo

  • Tal vez les parezca una locura encontrar un artículo sobre código cerrado en un blog que promociona GNU/Linux y el software libre. Pero esta entrada nace a raíz de una inquietud que me presentó un colega amigo y decidí ponerme en la piel de alguien que vive de escribir código fuente.

    Un desarrollador me comentó que luego de realizar una aplicación le solicitaron la cotización del código fuente. ¿Existe alguna técnica para valuar el código fuente más allá de hacerlo "a ojo"?.

    El software de código cerrado es un tema delicado en el mundo de los profesionales del desarrollo ya que posee muchas aristas. Por un lado está el punto de vista ético: ¿Todo el software debe ser de código abierto? ¿Cuándo se justifica que un software sea de código cerrado? ¿Soy peor que Hitler si deseo vender el fruto de mi trabajo y esfuerzo, es decir, el código fuente cerrado de mi aplicación? Por otro lado está el problema de la cotización: ¿Cuánto cobro la hora de desarrollo? ¿Puedo quedarme con el código fuente? ¿Cuánto puedo cotizar mi software terminado si alguien me lo quiere comprar?.

    Voy a tratar de abordar alguna de estas cuestiones en este artículo y dejaré el debate abierto para quien se quiera sumar para brindar su opinión o punto de vista.

  • Este artículo explica la diferencia entre un repositorio creado con git init y uno creado con git init --bare.

  • Las ramas (branches) son las diversas líneas de desarrollo que tiene un proyecto. Para trabajar con ramas en git es necesario recurrir al subcomando branch.

  • Supongamos que hemos creado un fork de un proyecto en GitHub y deseamos mantenerlo actualizado con los últimos cambios (commits) que va realizando su creador, autor o equipo de desarrollo original (llamado comúnmente upstream). En este breve artículo voy a explicar cómo hacerlo utilizando git desde línea de comandos en GNU/Linux.

  • Actualmente me encuentro trabajando en un proyecto de desarrollo que involucra diferentes lenguajes y tecnologías, como por ejemplo Java, PHP, MySQL, Bash, etc. Debido a que no me gustan los entornos de desarrollo (IDE), siempre realizo la codificación utilizando editores de texto (por ejemplo Gedit, Kate, Notepad++, nano, vi, etc.). Esta forma de trabajar obliga a escribir más y cliquear menos (algo que aprecian los detractores del mouse, como un servidor), pero también a leer más documentación de librerías, clases, módulos, etc. (que se traduce a lograr un conocimiento más profundo sobre lo que se está haciendo). En definitiva menos "drag and drop", menos autocompletar, menos autocorrección, menos chequeo de sintaxis y más "desarrollo a conciencia".

    Aunque tal vez muchos piensen que es una forma de trabajo obsoleta o retrógrada, no voy a entrar en la eterna discusión "text editor vs. IDE". En este artículo simplemente voy a presentar una forma de configurar el editor de texto nano para facilitar el desarrollo de código (sea cual sea el lenguaje).

  • De todos los lenguajes de programación con los que he trabajado creo que PHP es el más flexible y poderoso. Hoy descubrí un excelente truco que permite crear y evaluar nombres de variables a partir de strings en una misma línea.

  • Una buena práctica, común en equipos de desarrollo ágil, es asegurar que los desarrolladores poseen su propio entorno donde trabajar. Un entorno es un espacio técnico que posee un alcance bien definido y respetado. La principal ventaja de los entornos es que ayudan a reducir los riesgos debido a errores técnicos que puedan afectar de forma adversa a un grupo de personas mayor al absolutamente necesario.

    El modelo de desarrollo, testing y producción es esencial para proveer los controles y el balance necesario para ejecutar un entorno de producción de alta disponibilidad de forma eficiente.

  • Iba a ser un post en Google Plus, pero ¿por qué regalarle contenido a las redes sociales?. Mejor lo publico en mi blog, hosteado en mi propio servidor, que para eso pago.

    Este post surge a causa de un nueva oferta de trabajo que recibo en mi casilla de correo electrónico. Una de decenas que he recibido a lo largo del año, tanto en mi correo como en mi cuenta de LinkedIn. Y, como en todas las oportunidades, la oferta es para trabajar en la capital del país, algo que no pienso hacer a corto plazo. En Argentina tenemos un refrán que dice "Dios está en todas partes, pero atiende en Buenos Aires". No me voy a poner a hablar de federalismo en un blog de tecnología, pero es más o menos así, lamentablemente.