fuente

  • 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.

  • En este artículo voy a explicar cómo compilar una versión específica de un paquete, aplicando los últimos parches disponibles.

  • En muchos sitios Web y blogs he visto que cada vez que publican código fuente en una página, lo hacen con un formato colorido para resaltar la sintaxis. Siempre he querido una herramienta así para mi blog, pero nada de cargar scripts js desde sitios de terceros ¬_¬

  • En los sistemas GNU/Linux, para mejorar el rendimiento y eficiencia (y exprimir al máximo las características del CPU) se recomienda compilar todos los servicios, especialmente aquellos críticos, en lugar de instalar los binarios disponibles en los repositorios. En este artículo voy a explicar cómo compilar e instalar el servidor de bases de datos MySQL desde su código fuente. Es bastante sencillo, pero hay que prestar especial atención a algunos detalles.

  • 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).