Solving issue #3 at Bulk 1/7

programador/como-usar-bug-tracker.md

@@ -7,24 +7,50 @@ translator: Espartaco Palma
 original: http://programmer.97things.oreilly.com/wiki/index.php/How_to_Use_a_Bug_Tracker
 ---
 
-Como sea que lo llames, bug, defecto, o incluso "efecto del lado de diseño", no hay manera de alejarse de ellos. Conocer cómo enviar un buen reporte de error y lo que se debe buscar son habilidades para mantener a un proyecto llevándose bien:
+Como sea que lo llames, bug, defecto, o incluso "efecto del lado de diseño", no
+hay manera de alejarse de ellos. Conocer cómo enviar un buen reporte de error y
+lo que se debe buscar son habilidades para mantener a un proyecto llevándose
+bien:
 
 Un buen reporte de error necesita tres cosas:
 
-* Cómo reproducir el error, lo más preciso posible, y la frecuencia con que ésto hará que aparezca el error.
+* Cómo reproducir el error, lo más preciso posible, y la frecuencia con que
+ésto hará que aparezca el error.
 * ¿Qué debería haber ocurrido? al menos en tu opinión
 * ¿Qué realmente ocurrió? o al menos toda la información que has registrado.
 
-La cantidad y calidad de la información reportada de un error dice mucho acerca del quien reporta como sobre el error mismo. Los errores con enojo o tensión ("¡Esta función apesta!") nos dice que los desarrolladores estaban teniendo un mal momento, pero no mucho más. Un error con gran cantidad de contexto para que sea más fácil reproducirlo gana el respeto de todo el mundo, incluso si ésto detiene una liberación.
-
-Los errores son como un conversación, con toda la historia ahí en frente de todos. No culpes a otros o niegues la existencia del error. En vez de eso pide más información o considera qué pudiste haber olvidado.
-
-Cambiar el estatus de un error, por ejemplo, de Abierto a Cerrado, es una declaración pública de lo que se piensa del error. Tomarse el tiempo de explicar porqué crees que el error debería estar cerrado ahorrará horas de tedio en justificarlo a directores y clientes frustados. Cambiar la prioridad de un error es similar a las declaraciones públicas, y sólo porque es trivial no significa que alguien está dejando de usar el producto.
-
-No sobrecargues los campos del error para tu propio propósito. Agregar "VITAL:" al campo de título de error puede hacer que sea fácil para que puedas ordenar los resultados en algún informe, pero hará que eventualmente sea copiado por otros e inevitablemente será mal escrito, o necesitará ser removido para su uso en algún otro informe. En vez de eso usa un nuevo valor o un nuevo campo, y documenta cómo el campo se supone debe ser usado, así otras personas no tienen que repetirlo.
-
-Asegúrate que todos sepan cómo encontrar el error en el que se supone está trabajando el equipo. Esto se puede hacer mediante una consulta pública con un nombre obvio. Asegúrate que todos están usando la misma consulta, y no actualices dicha consulta sin primero informar al equipo que estás cambiando algo en lo que todos están trabajando.
-
-Finalmente, recuerda que un error no es una unidad estándar de trabajo más que una línea de código es una medida precisa del esfuerzo.
-
+La cantidad y calidad de la información reportada de un error dice mucho acerca
+del quien reporta como sobre el error mismo. Los errores con enojo o tensión
+("¡Esta función apesta!") nos dice que los desarrolladores estaban teniendo un
+mal momento, pero no mucho más. Un error con gran cantidad de contexto para que
+sea más fácil reproducirlo gana el respeto de todo el mundo, incluso si ésto
+detiene una liberación.
+
+Los errores son como un conversación, con toda la historia ahí en frente de
+todos. No culpes a otros o niegues la existencia del error. En vez de eso pide
+más información o considera qué pudiste haber olvidado.
+
+Cambiar el estatus de un error, por ejemplo, de Abierto a Cerrado, es una
+declaración pública de lo que se piensa del error. Tomarse el tiempo de
+explicar porqué crees que el error debería estar cerrado ahorrará horas de
+tedio en justificarlo a directores y clientes frustados. Cambiar la prioridad
+de un error es similar a las declaraciones públicas, y sólo porque es trivial
+no significa que alguien está dejando de usar el producto.
+
+No sobrecargues los campos del error para tu propio propósito. Agregar "VITAL:"
+al campo de título de error puede hacer que sea fácil para que puedas ordenar
+los resultados en algún informe, pero hará que eventualmente sea copiado por
+otros e inevitablemente será mal escrito, o necesitará ser removido para su uso
+en algún otro informe. En vez de eso usa un nuevo valor o un nuevo campo, y
+documenta cómo el campo se supone debe ser usado, así otras personas no tienen
+que repetirlo.
+
+Asegúrate que todos sepan cómo encontrar el error en el que se supone está
+trabajando el equipo. Esto se puede hacer mediante una consulta pública con un
+nombre obvio. Asegúrate que todos están usando la misma consulta, y no
+actualices dicha consulta sin primero informar al equipo que estás cambiando
+algo en lo que todos están trabajando.
+
+Finalmente, recuerda que un error no es una unidad estándar de trabajo más que
+una línea de código es una medida precisa del esfuerzo.
 

programador/conoce-bien-dos-lenguajes.md

@@ -7,19 +7,64 @@ translator: Espartaco Palma
 original: http://programmer.97things.oreilly.com/wiki/index.php/Know_Well_More_than_Two_Programming_Languages
 ---
 
-La psicología de la gente programadora han sabido desde hace mucho tiempo que la experiencia de programación está relacionada directamente con el número de diferentes paradigmas de programación que con que el programador se sienta cómodo. No se refiere a sólo saber, o saber un poco, sino a poder programar genuinamente con ellos.
+La psicología de la gente programadora han sabido desde hace mucho tiempo que
+la experiencia de programación está relacionada directamente con el número de
+diferentes paradigmas de programación que con que el programador se sienta
+cómodo. No se refiere a sólo saber, o saber un poco, sino a poder programar
+genuinamente con ellos.
 
-Cada programador inicia con un lenguaje de programación. Este lenguaje tiene un efecto dominante en la forma en que el programador piensa acerca del software. No importa cuántos años de experiencia tenga el programador usando ese lenguaje, si se queda con ese lenguaje, sólo sabrá ese lenguaje. Un programador de un solo lenguaje está limitado en su pensamiento por ese lenguaje.
+Cada programador inicia con un lenguaje de programación. Este lenguaje tiene un
+efecto dominante en la forma en que el programador piensa acerca del software.
+No importa cuántos años de experiencia tenga el programador usando ese
+lenguaje, si se queda con ese lenguaje, sólo sabrá ese lenguaje. Un programador
+de un solo lenguaje está limitado en su pensamiento por ese lenguaje.
 
-Un programador que aprende un segundo lenguaje será desafiante, especialmente si el lenguaje tiene un modelo computacional diferente que el primero. C, Pascal, Fortran, todos tiene fundamentalmente el mismo modelo computacional. Cambiar de Fortran a C introduce unos pocos, pero no muchos retor. Moverse de C o Fortran a C++ o Ada introduce retos fundamentales en la forma en que los programas se comportan. Pasarse de C++ a Haskell es un cambio significativo y por lo tanto un desafío importante. Moverse de C a Prolog es desafío muy concreto.
+Un programador que aprende un segundo lenguaje será desafiante, especialmente
+si el lenguaje tiene un modelo computacional diferente que el primero. C,
+Pascal, Fortran, todos tiene fundamentalmente el mismo modelo computacional.
+Cambiar de Fortran a C introduce unos pocos, pero no muchos retor. Moverse de C
+o Fortran a C++ o Ada introduce retos fundamentales en la forma en que los
+programas se comportan. Pasarse de C++ a Haskell es un cambio significativo y
+por lo tanto un desafío importante. Moverse de C a Prolog es desafío muy
+concreto.
 
-Podemos enumerar varios paradigmas de computación: procedimental, orientado a objetos, funcional, lógico, de flujo de datos (dataflow), etc. Moverse entre estos paradigmas crea los mayores desafíos.
+Podemos enumerar varios paradigmas de computación: procedimental, orientado a
+objetos, funcional, lógico, de flujo de datos (dataflow), etc. Moverse entre
+estos paradigmas crea los mayores desafíos.
 
-¿Por qué son buenos estos desafíos? Tiene que ver con la forma en que pensamos en la implementación de algoritmos, los modismos y patrones de implementación que aplican. En específico, la fertilización cruzada es la base de la experiencia. Los modismos para la solución de problemas que aplican en un lenguaje podrían no ser posibles en otro lenguaje. Tratar de portar el modismo de un lenguaje a otro nos enseña sobre ambos lenguajes y sobre el problema a ser resulto.
+¿Por qué son buenos estos desafíos? Tiene que ver con la forma en que pensamos
+en la implementación de algoritmos, los modismos y patrones de implementación
+que aplican. En específico, la fertilización cruzada es la base de la
+experiencia. Los modismos para la solución de problemas que aplican en un
+lenguaje podrían no ser posibles en otro lenguaje. Tratar de portar el modismo
+de un lenguaje a otro nos enseña sobre ambos lenguajes y sobre el problema a
+ser resulto.
 
-La fertilización cruzada en el uso de lenguajes de programación tiene enormes efectos. Quizás el más obvio es el uso creciente y cada vez mayor de modos de expresión declarativos en los sistemas implementados en lenguajes imperativos. Cualquier persona versada en programación funcional puede aplicar fácilmente un enfoque declarativo cuando está usando un lenguaje como lo es C. El uso de enfoques declarativos generalmente conduce a programas más cortos y más comprensibles. C++, por ejemplo, sin duda toma esto en cuenta con su apoyo incondicional de la programación genérica, que casi necesita un modo de expresión declarativo.
+La fertilización cruzada en el uso de lenguajes de programación tiene enormes
+efectos. Quizás el más obvio es el uso creciente y cada vez mayor de modos de
+expresión declarativos en los sistemas implementados en lenguajes imperativos.
+Cualquier persona versada en programación funcional puede aplicar fácilmente un
+enfoque declarativo cuando está usando un lenguaje como lo es C. El uso de
+enfoques declarativos generalmente conduce a programas más cortos y más
+comprensibles. C++, por ejemplo, sin duda toma esto en cuenta con su apoyo
+incondicional de la programación genérica, que casi necesita un modo de
+expresión declarativo.
 
-La consecuencia de todo esto es que le incumbe a cada programador el ser diestro en la programación en al menos dos diferentes paradigmas, e idealmente en al menos los cinco arriba mencionados. Los programadores deberen estar siempre interesados en aprender nuevos lenguajes, preferiblemente de un paradigma en el no están familiarizados. Incluso si el trabajo diario siempre usa el mismo lenguaje de programación, la mayor sofisticación en el uso de ese lenguaje cuando una persona puede hacer fertilización cruzada desde otro paradigma no debe ser subestimada. Los empleadores deberían tomar esto en cuenta y permitir en su presupuesto de capacitación de empleados el aprender lenguajes que actualmente no están siendo usados, como un modo de incrementar la sofisticación de los lenguajes que se utilizan.
+La consecuencia de todo esto es que le incumbe a cada programador el ser
+diestro en la programación en al menos dos diferentes paradigmas, e idealmente
+en al menos los cinco arriba mencionados. Los programadores deberen estar
+siempre interesados en aprender nuevos lenguajes, preferiblemente de un
+paradigma en el no están familiarizados. Incluso si el trabajo diario siempre
+usa el mismo lenguaje de programación, la mayor sofisticación en el uso de ese
+lenguaje cuando una persona puede hacer fertilización cruzada desde otro
+paradigma no debe ser subestimada. Los empleadores deberían tomar esto en
+cuenta y permitir en su presupuesto de capacitación de empleados el aprender
+lenguajes que actualmente no están siendo usados, como un modo de incrementar
+la sofisticación de los lenguajes que se utilizan.
 
-A pesar de que es un inicio, un curso de capacitación de una semana no es suficiente para aprender un nuevo lenguaje: Esto generalmente toma unos cuantos meses de uso, aunque a tiempo parcial, para ganar un conocimiento adecuando de un lenguaje. Son sus modismos de uso, no sólo la sintaxis y el modelo computacional los factores importantes.
+A pesar de que es un inicio, un curso de capacitación de una semana no es
+suficiente para aprender un nuevo lenguaje: Esto generalmente toma unos cuantos
+meses de uso, aunque a tiempo parcial, para ganar un conocimiento adecuando de
+un lenguaje. Son sus modismos de uso, no sólo la sintaxis y el modelo
+computacional los factores importantes.