Házlo simple
A raíz de conversaciones recientes con compañeros del trabajo, me ha venido a la memoria un libro que hace tiempo duerme en mi biblioteca: "Better, Faster, Lighter Java".
Hoy en día nadie cuestiona la utilidad y conveniencia de usar Hibernate o Spring, pero en aquel momento (año 2004) eran afirmaciones polémicas. En concreto, el motivo por el cual he vuelto a ojearlo, es la innecesaria complejidad que tienen muchos desarrollos Java.
Aquí van algunas de las ideas expuestas en dicho libro:
- La simplicidad debería ser un valor principal para todos los programadores Java.
- Existe la creencia, de que si programas código complicado, entonces debe ser dios.
- El código simple:
- Se escribe más rápido.
- Se prueba más fácilmente.
- Apenas tiene dependencias externas.
- Si el desarrollo ha ido realmente mal, la opción de tirarlo todo y volver a empezar es factible.
- Si los requerimientos cambias, se puede rehacer el desarrollo con comodidad.
- En contra de lo que pueda parecer:
- Código sencillo no implica código pensado de "manera simple", normalmente es lo contrario.
- Código sencillo no significa que la funcionalidad deba ser obligatoriamente sencilla..
El capitulo del libro en el que se tratan estos temas se titula Keep It Simple, en algunos sitios he visto que le añaden "and Small" para hacer las iniciales KISS, aunque en otros, lo cambian por "Keep It Simple, Stupid" 
Imprimir este artículo
Vida Inteligente
En una de esas sesiones intensivas de "blog-night" en las que comienzas por un sitio, discurres por muchos y acabas en otro completamente diferente, he tenido la suerte de leer unas más que interesantes relfexiones / pensamientos (cito sólo algunos, pero hay otros igualmente buenos):
"It is my experience that software developers are seen as interchangeable units, with actual hourly cost being the prime driver. The quality of the resultant code, it's correctness and the time taken to deliver it are all intangibles that are left out of the equation. And the time taken to learn the code to be worked on is never, ever, factored into the equation. People out there simply don't understand software, but do understand hourly rates. Only when software developers who truly understand software start to play a more active role in making business decisions will this change."
"En las empresas no se hace Análisis, se hace “Documentación de Análisis”. No se conoce y aplica “buenas prácticas”, sino que “se implanta CMMI”. No se planifica, sino que se hace una planilla en Project. No se contrata a los buenos y no se deja escapar a los mejores, sino que se realiza un “proceso de recruiting”. No se hace código de calidad, sino que se mejoran las métricas. No se aumenta la calidad, sino que se consiguen certificaciones…" (http://juanignaciosl.blogspot.com/)
Maravilloso mundo el de los blogs, es muy gratificante ver que "hay vida inteligente ahí afuera" y que "no estamos solos" 
Imprimir este artículo
¿Te cambias? (de Windows a Linux)
Probablemente te hayas planteado muchas veces cambiar a Linux, o al menos comenzar a usarlo, y seguramente una de las mayores trabas a la hora de hacerlo es la "pereza" de volver a buscar la aplicación adecuada para cada una de las labores que realizas.
Algunos consejos:
- Date tiempo, esto no es cosas de un día para otro. Seguramente lo intentaras varias veces hasta lograrlo de forma definitiva.
- No te engañes, hay que "esforzarse": admitamoslo Windows es todavía un poco mas amigable (aunque cada día falta menos para que se igualen).
- Acepta consejos de otros que lo hayan hecho antes, pero cuidado !!! huye de los fundamentaliastas ¡¡¡¡ en especial de los que te recomienden Debian
- Al la hora de escoger tu "sabor / distribución", usa una mayoritaria, con amplio soporte de la comunidad.
- Para que todo te sea más todavía aún más fácil, usa esta página para buscar las alternativas.
Mi experiencia:
- Desde hace meses, soy un feliz usuario de Ubuntu.
- He descubierto que mi PC esucho más rápido de lo que recordaba
- Puedo contar con orgullo que mi mujer usa Linux.
- He eliminado totalmente Windows de mi equipo ... y ya tengo una excusa perfecta para no trabajar en casa
Mi deseo:
- Que cada vez más usuarios no informáticos usen Linux.
Imprimir este artículo
Errores de una arquitectura de software
Eoin Woods, ha publicado un artículo acerca de lo que él considera los 10 errores mas comunes en una arquitectura de software - errores que habitualmente se aprenden por el camino mas difícil: la propia experiencia.
Desde mi punto de vista, si bien todos ellos son importantes (te recomiendo su lectura completa) algunos tienen más "peso" que otros:
- Desde luego el que hace referencia al alcance del sistema (apartado 1) es una verdad universal, más vale que antes de comenzar un proyecto tengas claro lo que quieres hacer y sobre todo lo que el cliente espera.
- Muy relacionado con "lo que el cliente espera" está el apartado 2: contar con todos los interesados. Es muy habitual que cuando comiences un proyecto trates con un "iluminado" que tiene claro como debería funcionar todo, pero que desgraciadamente no ha tenido en cuenta a los que realmente van a usar el sistema. Es una dificil situación, en estos casos la mano izquierda cuenta mucho ya que será necesario acceder a los verdaderos usuarios sin que por ello el "iluminado" se sienta menospreciado.
- El punto 5, aparentemente entra de lleno en conflicto con los plazos y los costes del proyecto. La experiencia demuestra que la formación del equipo de desarrollo, el realización de pruebas de concepto y la evaluación de alternativas de diseño son las mejores garantías de éxito de un proyecto.
- La escalabilidad y rendimiento (apartado 7) deben estar siempre en primer lugar a la hora de tomar decisiones de diseño. En contadas ocasiones una decisión del tipo "no pasa nada, guárdalo en sesión, serán pocos usuarios" no trae disgustos más tarde o temprano.
Imprimir este artículo
Reglas sagradas de un buen diseño
"bajo acoplamiento, alta cohesión"
Imprimir este artículo