Blog Jose Cuellar

//Tech Lead, Senior Backend Developer & Life-long learner

Agilizando la arquitectura de software

por Jose el 23 octubre, 2015

Durante muchos años he diseñado y desarrollado arquitecturas mediante metodologías tradicionales, en los que el análisis exhaustivo inicial era primordial y necesario.

La arquitectura global resultante era muy específica a los requerimientos iniciales de producto, sin tener en cuenta todos los cambios futuros que pudiesen aparecer a lo largo del tiempo, generando así una arquitectura rígida e incrementando la resistencia a cualquier cambio futuro. Teniendo en cuenta que cuanto mayor es el producto a desarrollar sin previas validaciones por parte del consumidor o cliente, mayor será la probabilidad de que los haya.

El desarrollo de producto en grandes lotes, con largos periodos de lanzamiento es la causa.

more →

Hacia #NoEstimates

por Jose el 22 septiembre, 2015

Las opciones o métodos recomendados en entornos ágiles con respecto a la estimación son:

Estimar en puntos de historia abstractos

Desvincular totalmente el tiempo liberándolo de la presión mediante puntos de historia. No se trata de averiguar cuanto se tardará en desarrollar una historia de usuario o saber su alcance exacto, sino simplemente saber el tamaño aproximado «a priori», para intuir cuánto esfuerzo relativo deberá aplicar el equipo.


Imagen extraída del post Agile Concepts: Estimating and Planning Poker

more →

The lean startup. De los imprescindibles

por Jose el 18 septiembre, 2015

El método Lean Startup supone un nuevo enfoque que se está adoptando en todo el mundo para cambiar la forma en que las empresas crean y lanzan sus productos.

Eric Ries define una startup como una organización dedicada a crear algo bajo condiciones de incertidumbre extrema. Prácticas pensadas para ayudar a los emprendedores a incrementar las probabilidades de crear una startup con éxito. No es una fórmula matemática infalible, sino una filosofía empresarial innovadora que ayuda a los emprendedores a escapar de las trampas del pensamiento empresarial tradicional.
more →

Algunas leyes en el desarrollo de software

por Jose el 3 febrero, 2015

Ley de Brooks

Añadir más gente a un proyecto que tiene retraso provoca que tenga aún más retraso.
Fred Brooks

Ley de Conway

Cualquier fragmento de software refleja la estructura organizacional que lo produjo.
Melvin Conway

Regla de Cope

En la evolución hay una tendencia general hacia el aumento de tamaño.
Edward Drinker Cope

Ley de Hoare y Ley inversa de Schainker

Detrás de un gran problema hay siempre un problema pequeño que lucha por salir. Dentro de un problema pequeño hay siempre un problema grande que lucha por salir.
Tony Hoare

Ley de Hofstadter

Una tarea siempre lleva más tiempo de los que esperabas, incluso cuando tienes en cuenta la ley de Hofstadter.
Douglas Hofstadter

Ley de Linus

Con suficientes ojos, todos los fallos (bugs) son superficiales.
Linus Torvalds

Ley de Lister

La gente bajo presión de tiempo no piensa más rápido.
Tim Lister

Primera ley de Nathan

El Software es un gas; se expande hasta llenar el recipiente que lo contiene.
Nathan Myhrvold

Ley de Noventa-noventa

El primer 90% del código lleva el primer 10% del tiempo de desarrollo. El 10% de código restante absorbe el 90% del tiempo de desarrollo.
Tom Cargill

Cuchilla de Occam

En igualdad de condiciones, la solución más sencilla suele ser la mejor (original en latín: «entia non sunt multiplicanda praeter necessitatem», que se podría traducir por «las entidades no deberían multiplicarse más allá de lo necesario»).
William of Ockham

Principio de Pareto (a.k.a. “La regla del 80-20”)

El 80% de las consecuencias procede del 20% de las causas
Vilfredo Pareto

Ley de Parkinson

El trabajo se expande hasta llenar todo el tiempo disponible para completarlo.
C. Northcote Parkinson

Ley de Tesler de conservación de la complejidad

No se puede reducir la complejidad de una tarea más allá de cierto punto. Una vez que se ha alcanzado ese punto, sólo puedes desplazar la complejidad de una parte a otra.
Larry Tesler

La paradoja del Pesticida

Cada método utilizado para prevenir o detectar errores deja otro residuo de errores contra los que estos primeros métodos son ineficaces.
Bruce Beizer

Axioma de Flon

No existe ni existirá un lenguaje de programación en el que sea difícil escribir malos programas.
Lawrence Flon

Leyes de Lehman de la evolución del software

Ley de Demeter

Habla solo con tus amigos cercanos. No hables con extraños.
Un método de un objeto solo puede llamar a métodos de:
1 – El propio objeto.
2 – Un argumento del método.
3 – Cualquier objeto creado dentro del método.
4 – Cualquier propiedad/campo directo del propio objeto.

Amplía la información con los principios básicos en el desarrollo de software

Implementación de Apache Solr

por Jose el 14 diciembre, 2011

Desde hace algunos meses he tenido la oportunidad de realizar tareas de implementación, configuración, adaptación y transicion de consultas SQL sobre una aplicación web de alto rendimiento mediante Apache Solr.

Este hecho me ha permitido acercarme a la tecnología y dar mis primeros pasos en esta magnífica herramienta de búsqueda en la que cada día aprendo algo nuevo.

more →