Enlace en Amazon
El libro trata sobre la mala calidad de la interacción entre humanos y tecnología en general partiendo de la base de que "tecnología" significa computadoras (ordenadores).
Me lo estoy leyendo en este momento...
lunes, 19 de mayo de 2008
"1984" de George Orwells
Enlace en Amazon
Excelente continuación de Animal Farm. Se adentra un poco más en la motivación y los mecanismos utilizados por aquellos que están en el lado del poder, los que saben lo que está pasando.
No comparto la opinión de que haya tanto desconocimiento entre los que gobiernan y que lo hagan sólo porque crean que hacen lo correcto, pero sí de que el objetivo primordial es mantenerse en el poder.
Me encanta el análisis de la historia de la humanidad hecho. No es históricamente estricto y no es aplicable en general, pero da muchísimo en qué pensar. No soy historiador ni filósofo ni leo demasiado sobre esos temas así que pudiera ser que haya puntos de vista y análisis más interesantes y estrictos sobre lo mismo, pero no los conozco.
El hecho de que se defina que siempre han habido 3 clases: poderosos, sirvientes y manipulados, y no sólo 2 como me habían enseñado tan bien: explotados y explotadores, ha sido toda una revelación para mi, como también lo es la forma en que esas 3 clases interactúan y sobre todo, la forma en que los manipulados no cambian nunca y que siempre son los que peor viven, quizás merecidamente.
Excelente continuación de Animal Farm. Se adentra un poco más en la motivación y los mecanismos utilizados por aquellos que están en el lado del poder, los que saben lo que está pasando.
No comparto la opinión de que haya tanto desconocimiento entre los que gobiernan y que lo hagan sólo porque crean que hacen lo correcto, pero sí de que el objetivo primordial es mantenerse en el poder.
Me encanta el análisis de la historia de la humanidad hecho. No es históricamente estricto y no es aplicable en general, pero da muchísimo en qué pensar. No soy historiador ni filósofo ni leo demasiado sobre esos temas así que pudiera ser que haya puntos de vista y análisis más interesantes y estrictos sobre lo mismo, pero no los conozco.
El hecho de que se defina que siempre han habido 3 clases: poderosos, sirvientes y manipulados, y no sólo 2 como me habían enseñado tan bien: explotados y explotadores, ha sido toda una revelación para mi, como también lo es la forma en que esas 3 clases interactúan y sobre todo, la forma en que los manipulados no cambian nunca y que siempre son los que peor viven, quizás merecidamente.
"Refactoring: Improving the Design of Existing Code" de Martin Fowler
Enlace en Amazon
No puede compararse la importancia de este libro con "Patterns of Enterprise Application Architecture" pero aún así es un libro que me alegro de haber leído.
Siguiendo el estilo del autor, brinda muchos consejos basados en su experiencia sobre cómo debe afrontarse un proceso de refactorización, cómo valorar si vale la pena refactorizar y la importancia que tiene refactorizar el código sobre la marcha.
Yo me permito añadir a sus consideraciones que la refactorización es mucho menos importante cuando la calidad del código que se está generando no representa un valor añadido. Este es el caso de la mayoría de proyectos hechos por consultoras para clientes externos, al menos según el modelo que se utiliza en España.
En este tipo de proyectos, mi experiencia indica que los desarrolladores "rasos" deben limitarse a hacer refactorizaciones a nivel de métodos, y que sólo el arquitecto o alguien con una visión global de los objetivos de la aplicación y con un excelente juicio sobre el impacto en el proyecto deben acometer una refactorización más compleja.
Como regla general, las refactorizaciones deben estar orientadas a lograr una disminución de la complejidad del proyecto y a un adelanto de la fecha de terminación.
No puede compararse la importancia de este libro con "Patterns of Enterprise Application Architecture" pero aún así es un libro que me alegro de haber leído.
Siguiendo el estilo del autor, brinda muchos consejos basados en su experiencia sobre cómo debe afrontarse un proceso de refactorización, cómo valorar si vale la pena refactorizar y la importancia que tiene refactorizar el código sobre la marcha.
Yo me permito añadir a sus consideraciones que la refactorización es mucho menos importante cuando la calidad del código que se está generando no representa un valor añadido. Este es el caso de la mayoría de proyectos hechos por consultoras para clientes externos, al menos según el modelo que se utiliza en España.
En este tipo de proyectos, mi experiencia indica que los desarrolladores "rasos" deben limitarse a hacer refactorizaciones a nivel de métodos, y que sólo el arquitecto o alguien con una visión global de los objetivos de la aplicación y con un excelente juicio sobre el impacto en el proyecto deben acometer una refactorización más compleja.
Como regla general, las refactorizaciones deben estar orientadas a lograr una disminución de la complejidad del proyecto y a un adelanto de la fecha de terminación.
"Patterns of Enterprise Application Architecture" de Martin Fowler
Enlace en Amazon
Este libro lo compré hace cerca de 1 año en Amazon. Creo que es uno de los mejores libros que he leído sobre diseño y arquitectura de aplicaciones. El autor expresa en forma de patrones su experiencia en el desarrollo de aplicaciones en el mundo real, que según mis propias experiencias, dista muchísimo del académico.
Comentario en Amazon:
Desde que terminé mis estudios universitarios de informática y comencé a trabajar, me di cuenta de que las aplicaciones del mundo real son mucho más complejas que crear unas cuantas clases y una interfaz. Más sobre este problema aquí
Martin Fowler ataca los problemas más comunes a los que me había enfrentado y brinda soluciones. No son soluciones "abstractas" ni incompletas, sino que están expresadas en forma de patrones, y muy bien documentadas además.
Aunque diste de ser la solución definitiva a todos los problemas y de que no quede nada más por investigar y aprender después de leer este libro, debe ser un ejemplo para todos los demás autores.
El libro en sí es un resumen, así que no se puede resumir. Se ha convertido en mi libro de cabecera y de consulta, acompañado del sitio web del autor:
http://martinfowler.com/
http://martinfowler.com/books.html
y en particular su famosísima página de patrones:
http://martinfowler.com/articles/enterprisePatterns.html
Es un libro que deberían utilizar para la preparación de programadores para evitar este problema: Por qué no es lo mismo una aplicación "de escuela" que una aplicación "del mundo real"
Este libro lo compré hace cerca de 1 año en Amazon. Creo que es uno de los mejores libros que he leído sobre diseño y arquitectura de aplicaciones. El autor expresa en forma de patrones su experiencia en el desarrollo de aplicaciones en el mundo real, que según mis propias experiencias, dista muchísimo del académico.
Comentario en Amazon:
Desde que terminé mis estudios universitarios de informática y comencé a trabajar, me di cuenta de que las aplicaciones del mundo real son mucho más complejas que crear unas cuantas clases y una interfaz. Más sobre este problema aquí
Martin Fowler ataca los problemas más comunes a los que me había enfrentado y brinda soluciones. No son soluciones "abstractas" ni incompletas, sino que están expresadas en forma de patrones, y muy bien documentadas además.
Aunque diste de ser la solución definitiva a todos los problemas y de que no quede nada más por investigar y aprender después de leer este libro, debe ser un ejemplo para todos los demás autores.
El libro en sí es un resumen, así que no se puede resumir. Se ha convertido en mi libro de cabecera y de consulta, acompañado del sitio web del autor:
http://martinfowler.com/
http://martinfowler.com/books.html
y en particular su famosísima página de patrones:
http://martinfowler.com/articles/enterprisePatterns.html
Es un libro que deberían utilizar para la preparación de programadores para evitar este problema: Por qué no es lo mismo una aplicación "de escuela" que una aplicación "del mundo real"
Suscribirse a:
Entradas (Atom)