“El Experto”

Hace algunos años se hizo popular el siguiente video, que muestra un problema muy recurrente a la hora de ejecutar proyectos, e ilustra el distanciamiento que áreas técnicas y de negocio pueden llegar a tener:

 

En software cualquier cosa se puede hacer. O casi cualquier cosa. La pregunta real no es sí una cosa puede hacerse o no, la pregunta real es si vale la pena hacerse. Esto cambia mucho el ángulo desde el cual se aborda el problema, ya que si suponemos que algo puede hacerse, dejamos de pensar en el cómo para enfocarnos más en el qué y sobre todo en el por qué.

Read more “El Experto”

Mejores prácticas, buenas prácticas en programación Java

Cómo muchos de ustedes saben, esta sección ha tenido un fuerte enfoque en patrones de diseño de software, en buenas prácticas y en cómo desarrollar software específico. El software es un tema muy amplio que tiene bastantes esquinas interesantes para digerir. Pero sin duda, uno de los puntos cruciales de todo el ecosistema técnico y de negocios del software, la calidad del código es una pieza fundamental para un software exitoso.

Hasta ahora nos hemos enfocado en muchas buenas prácticas y patrones de diseño intentando hacer un enfoque global, agnóstico del lenguaje de programación que se utiliza. Sin embargo, gracias a la experiencia en una variedad de proyectos, creo que es necesario una pequeña sección en el sitio sobre buenas prácticas, o mejores prácticas, al momento de escribir el código, pero enfocándonos en el lenguaje de programación que se utiliza para x o y desarrollo. En nuestro caso abriremos una sección de mejores prácticas en Java.

¿Por qué Java? Sencillamente es el que más usamos, el que más conocemos y el que más nos gusta. Espero les guste esta nueva sección, y si tienen comentarios o sugerencias no duden en plantearlas, porque poco a poco hemos comenzado a construir una comunidad más o menos grande, y nos encantaría irla agrandando con el tiempo.
cheap custom essay writing services

Hacer Software NO es programar

Una de las lecciones que más cuesta aprender para un buen programador es la siguiente: programar NO es lo más importante en el software. Un poco irónico, pero cierto. Para ser más específicos, hacer del software un negocio NO se hace programando. Claro, nos toca el orgullo, el karma, el ego. Nos gusta sentirnos esenciales en el proceso. Pero no, al final somos los peones de todo el camino. No nos estoy desprestigiando, somos peones de alto nivel, difíciles de conseguir, que podemos ser caros y lo demás…pero somos altamente reemplazables, y en rol de negocio NO jugamos un papel importante. Así como los cortadores de café no son claves en el negocio del café, o los cocineros en un restaurante de comida rápida poco tienen que decir ese negocio, o como los ingenieros químicos de comidas empacadas tienen poco que decir en su negocio. De nuevo son puestos CLAVES siempre y cuando EXISTA y FUNCIONE el negocio. Pero ellos, al igual que nosotros, no suelen influir desde el punto de vista de negocios.

Read more Hacer Software NO es programar

Patron Adaptador – Pattern Adapter – Patrones de diseño

adaptadorEl patrón estructural que ahora vamos a analizar es muy eficaz así como sencillo. Se puede utilizar en muchos contextos y es de especialidad utilidad cuando se utilizan códigos o librerías ajenos al que estamos utilizando y sobre el que no tenemos control. Este patrón se le conoce como adaptador o adapter en inglés, aunque algunos lo llaman también wrapper, que viene siendo como envoltorio. Ambos nombres tienen bastante sentido y explican el por qué de este patrón.

Read more Patron Adaptador – Pattern Adapter – Patrones de diseño

El ejemplo del constructor

albanilHace ya algunos años lei por primera vez este texto. Quisiera poner la referencia del autor, pero no encontré quien lo pudo haber escrito,  así que si alguien me dice a quién darle el crédito, con gusto se lo daremos 🙂 Aparte de lo gracioso en sí mismo, ahora que lo leo años después, desafortunadamente es muy acertado. Digo desafortunadamente, porque tenemos que cambiar la manare de hacer proyectos de software. Urgentemente. Nuevas metodologías, nuevas herramientas, nuevos paradigmas. Actualmente el proceso de hacer software es más complicado de lo que, en mi humilde opinión, debería ser. ¿Qué piensan?

Read more El ejemplo del constructor

NTR: No Te Repitas (DRY: Don’t Repeat Yourself)

funny_hatchetHace algunos años ya me topé con el libro “Pragmatic Programmer”  de Andrew Hunt y David Thomas. Aconsejo a todos los que tengan la oportunidad que adquieran el libro y le den una buena leída. Muestra de manera clara muchas verdades que conocemos, pero que realmente pocas veces aplicamos. Algún día escribiré un post del libro. Pero hoy quiero enfocarme en el DRY Principle. A este principio se le conoce también como “single point of thruth” o “punto único de verdad”.

El principio establece que, en un entorno informático, la información no debe repetirse. Es decir, el conocimiento almacenado en un programa informático debe mantenerse en un, y sólo en un, lugar. De primas a primeras, el principio parece evidente, pero cuando investigamos algunas piezas de código, incluso las nuestras, nos damos cuenta que constantemente violamos el principio.

Read more NTR: No Te Repitas (DRY: Don’t Repeat Yourself)