Lycka Bonita

El monje que vendió su Ferrari, de Robin S. Sharma [2002]. Es un libro ligero y rápido de leer, un cuento que nos narra una fábula a modo de mnemotécnico para ayudarnos a recordar los pilares de la productividad personal. El punto de partida ideal para introducirte en el mundo de la productividad.

Nos presenta a un abogado de éxito quien “aunque lo tenía todo aún no había encontrado lo que buscaba”, llenando su vida de trabajo y lujo que inevitablemente le conduce a un ataque al corazón. Decide abandonar su vida anterior, vender todas sus posesiones (Ferrari incluido) y marchar en la búsqueda de lo que le faltaba. Tras unos meses consigue vivir en un poblado de sabios entre sabios, quienes le revelan sus conocimientos milenarios a cambio que vuelva a Occidente a compartir a su vez sus conocimientos con el mayor número de personas posible.

Tras unos años entre los sabios vuelve a visitar a su antiguo amigo y colega de trabajo, a quien le revela los secretos aprendidos resumidos en una fábula que recoge las 7 virtudes:

Dominar la Mente (Jardín). Nuestros actos nacen en nuestra mente como pensamientos, por lo que expandir nuestra imaginación y cultivar los pensamientos adecuados, que posteriormente recogeremos en forma de actos, marcarán nuestro destino.

Las cosas son creadas dos veces: primero en el taller de la mente y después en la realidad.

Quizás no podamos controlar el tiempo atmosférico, el tráfico o el humor de quienes nos rodean, pero ten por seguro que podemos controlar nuestra actitud hacia esos hechos.[…] No importa lo que te ocurra en la vida, porque tienes la capacidad de elegir tu reacción [...] y uno empieza a controlar su destino.

La mente es un magnífico sirviente pero un amo terrible. […] Recuerda que o tú controlas tu mente o ella te controla a ti.

Dharma (Faro). Encontrar la meta final de nuestra vida y seguirla. De esta manera podremos fijarnos objetivos intermedios con sentido y sentiremos cómo nuestros actos llenan nuestra vida.

El propósito de la vida es una vida con propósito.[...]Definir claramente tus prioridades en cada aspecto de tu vida [...] ofrecerá orientación y refugio.[…] Tómate tiempo para reflexionar. Descubre tu verdadera razón de vivir y luego ten el valor necesario para afrontarla.

Ejercitarse en lograr pequeñas hazañas es prepararse para abordar las grandes.

Kaizen (Luchador de sumo gigante). Crecimiento continuo mediante el autodominio y la renovación, para lo que debemos abandonar nuestra zona de confort. El éxito empieza desde dentro.

No compitas con los demás, compite contigo mismo.

Disciplina (Faja rosa del luchador de sumo). Sin fuerza de voluntad diaria y constante no podremos abandonar nuestra zona de confort, no podremos esforzarnos ni conseguir nuestros objetivos.

Siembra un pensamiento, cosecha una acción; siembra una acción, cosecha un hábito. siembra un hábito, cosecha un carácter; siembra un carácter, cosecha un destino.

Respetar el tiempo propio (Cronómetro). Nuestro tiempo es el activo más importante del que disponemos, activo que no es renovable. Simplifica tu vida, aparta lo espurio, prioriza, elegir hacer algo en un momento dado es lo mismo que elegir no hacer todo lo demás, mantén el objetivo claro.

El mejor momento para plantar un árbol fue hace cuarenta años, el segundo mejor momento es hoy.

Servidumbre (Rosas amarillas). Cuando trabajas para mejorar la vida de los demás, indirectamente estás elevando la tuya.

La mano que da rosas siempre conserva un poco de su fragancia.

Abrazar el presente (sendero de diamantes). Del mismo modo en que viniste al mundo sin nada, tendrás que irte de él sin nada: no es tan importante el final de la vida ni lo que has acumulado en ella, sino la calidad de cada momento vivido, el camino recorrido.

La felicidad es un viaje, no un destino. Puedes maravillarte de los diamantes que hay en el camino o puedes seguir persiguiendo ese cofre del tesoro que a la postre resulta estar vacío. Disfruta esos momentos que cada día te ofrece, porque hoy es lo único que tienes.

Otras citas interesantes que te puedes encontrar en el libro:

Toda adversidad nos enseña una lección [...]Todo revés aporta algún beneficio si uno sabe buscarlo. […]Acondiciona tu mente para traducir cada acontecimiento en uno positivo que te brinda la oportunidad de aprender una lección, te convertirás en el arquitecto de tu futuro.

Invertir en ti mismo es lo mejor que puedes hacer. No sólo conseguirás mejorar tu vida, sino también las de quienes te rodean. […]Decir que no tienes tiempo para mejorar tus pensamientos es como decir que no tienes tiempo para echar gasolina porque estás demasiado ocupado conduciendo.

Nunca lamentes tu pasado, acéptalo como el maestro que es. […] No juzgues los hechos como positivos o negativos. Limítate a experimentarlos, festejarlos y aprender de ellos.

Si tienes un ojo puesto en el destino que esperas alcanzar, sólo te queda otro para que te guíe en el viaje.

El autoconocimiento es el primer paso hacia el autodominio. […] Ejercitarse en lograr pequeñas hazañas te prepara para abordar las grandes.

Planeábamos cambiar el mundo. Han pasado veinte años desde entonces y mi ardiente deseo de fomentar el cambio ha dado paso a mi ardiente deseo de liquidar mi hipoteca y aumentar mi fondo de pensiones.

En el mundo real nunca tenemos una segunda oportunidad de vivir la vida con plenitud.

Refactoring Workbook

William C. Wake

Es un buen libro, aunque incompleto y con cierto sesgo “agilista” al intentar justificar ciertas causas de errores frecuentes al carecer de un diseño y una gestión del equipo eficiente. See also “Refactoring” by Martin Fowler.

Refactoring is the art of safely improving the design of existing code keeping the system running at all times. Refactoring provides us with ways to recognize problematic code and five us recipes for improving it.

Actualización

El libro lo puedes descargar en formato PDF gratuitamente desde este enlace.

Sin duda es más fácil escribir código que leerlo; por ello después de cada entrega ya sea por parte del programador o del equipo se debería leer el código que se ha entregado para partiendo de un código que ya funciona llegar a otro que funciona (desarrollar) y es simple de leer (mantener).

Especial atención al “safely” de la definición. Sin ir más lejos en mi actual proyecto intenté refactorizar la capa de control de la aplicación y preparé un carajal curioso : fue demasiado ambicioso, me tomó una semana de trabajo y al liberarlo entró en conflicto con los numerosos cambios que el resto del equipo fue realizando. Tendría que haber dividido la tarea en más pequeñas para conseguir que fuera seguro y no interferir con la marcha normal del proyecto.

Smells are warning signs about potential problems in code; some people prefer to talk about potential problems or flaws.

The Refactoring Cycle

Refactoring works in tiny steps. With a working system, while smells remain :

• Choose the worst smell
• Select a refactoring that will address the smell
• Apply the refactoring

Smells within Classes

• Comments

Symptoms: Comments symbols appear in the code.

Causes: Commnets may be present for the best of reasons: the author realizes that something isn´t as clear as it could be and adds a comment. Some comments are particularly helpful, as those that tell why something is done a particular way or why is’nt or thos that cite algorithms thar are not obvious. Other comments can be reflected just as well in the code itself. For example thie goal of a routine’s name as it  can through a comment.

What to do: When a comment explains a block of code you can often use “Extract Method” to pull the block out into a separate method (the comment will often suggest a name for the new method). Whe a comment explains what a method does better than the method’s name, use “Rename Method” using the comment as the basis of the new name. When a comment explains preconditions, consider using “Introduce Assertion” to replace the comment with code.

Payoff: Improves communication. May expose duplication.

Contraindications: Don’t delete comments that are pulling their own weight.

• Long Methods

Symptoms: Large number of lines

Causes: Code is often easier to write than it is to read.

What to do: Use “Extract Method” to break up the method into smaller piedes splitting it into blocks semantically meaningful.

Payoff: Improves communication. May expose duplication. Often helps new classes and abstractions emerge.

Contraindications: Like almost all smells, the length is a warning sign – not a guarrantee – of a problem; Perhaps the best way to express something is using longer methods.

• Large Class

Symptoms: Large number of instance varialbes, and/or methods and/or lines.

Causes: The author keeps adding just one more capability to a class until eventually it grows too big.

What to do: If the class has Long Methods, address that smell first.The most common approaches to break up a class are “Extract Class” if you can identify a new class that has part of this class`s responsibilities, “Extract Subclass” if you can divide responsibilities between the class and a new sublcass and “Extract Interface” if you can identify subsets of features that clients use.

Payoff: Improves communication. May expose duplication.

• Long Parameter List

Symptoms: A method has more than one or two parameters

Causes: You may be trying to minimize coupling between objects letting the caller locate everything, or a programmer generalizes the routine to deal with multiple variations and a lot of control parameters.

What to do: If the parameter value can be obtained from another object this one already knows, “Replace Parameter with Method”; if the parameters come from a single object, try “Preserve Whole Object”; If the data is not from one logical object, you still might group them via “Introduce Parameter Object”.

Payoff: Improves communication. May expose duplication. Often reduces size.

Contraindications: Take a look on dependencies between two classes, or you cann’t design meaningful groups.

• Type Embedded in Name (Including Hungarian)

Symptoms: Names are compound words consisting of a word plus the type of the arguments, for example a method addCourse (Course C); names are in Hungarian notation, where the type of an object is encoded into the name, for example iCount as an integer member variable; variable names reflect theri type rather than their purpose or role.

What to do: “Rename Method” or field or constant to a name that comunicates intent without being so tied to a type.

Payoff: Improves communication. May make it easier to spot duplication.

Contraindications: rarely you might have a class that wants to do the same sort of operations to two different but related types, for expample a Graph class with addPoint() and addLink() methods.

• Uncommunicative Name

Symptoms: a name doesn´t communicate its intent well enough : one or two character namens, names with vowels omitted, numbered variables like pane1, pane2…, odd abbreviations, misleading names.

Causes: you haven’t took a minute, fucking lazy boy/girl.

What to do: Use “Rename Method”

Payoff: Improves communication.

Contraindications: i/j/k are oftenly used for loop indexes and c form characters if their scope is reaseonably short.

• Inconsistent Names

Symptoms: One name is used in one place and a different name is used for the same thing somewhere else, for expample find() and list() for the same basic feature.

Causes: different people may create the classes at differente times, vamos que falta un diseño único documentado y consistente.

What to do: Pick the best name and use “Rename Method” or field or constant to give the same name to the same things. Then look for duplication smell. Note that the Eiffel language uses a common pool of words for the names of its library features.

Payoff: Improves communication. May expose duplication.

• Dead Code

Symptoms: a variable, parameter, field, code fragment, method or class is not used anywhere or just in tests.

Causes: Requirements have changed or new approaches are introduced without adequate cleanup. Complicated logic results in some combinations of conditions that can’t actually happen.

What to do: delete the unused code and any associated test.

Payoff: Improves communication. Improves simplicity. Reduces size.

Contraindications: be aware that code aparently dead can be used dinamically or by another software modules.

• Duplicated Code

Symptoms: Two fragments of code look nearly identical or have nearly identical effects.

Causes: programmers working independently (vamos una mala gestión y una carencia en el diseño), and copy and paste code that is almost right and make slight alterations.

What to do: If the duplication is within the same class, use “Extract Method” to pull the common part out into a separate method; if it is in two related classes use Pull Up Field or Method to bring the common parts together; if it is in two unrelated classes use Extract Class for extracting the common part into a new class, or decide in which class should be.

Payoff: Reduces duplication. Reduces size. Can lead to better abstractions and more flexible code.

• Null Check

Symptoms: there are repeated occurrences of code like this : if (xxx == null) …

Causes: someone decides “we’ll use null to mean the default”

What to do: if there’s a resonable default value, use that. Otherwise “Introdue Null Object” tocreate a default object that you explicitly use. Watch out for a case where null means two or more differente things in different contexts.

Payoff: Reduces duplication. Redeces logic errors and exceptions.

Contraindications: if only occurs in only one place, it’s usually not worth the effort to create a separate Null Object. If you can’t define a safe behavior for each method, you may not be able to use a Null Object. Precisamente por esto prefiero, facilita detectar errores no previsto e interrumpe el flujo de ejecución en caso de error no previsto ni controlado.

• Complicated Boolean Expression

Symptoms: code has complex conditions involving and, or and not.

Causes: injustificable.

What to do: Introduce “Explaining Variable” to make each clause clearer.

Payoff: Improves communication.

Contraindications: if simpler exressions comunicates less well.

Smells between Classes

Objects are about data and behavior together, and your code will be more robust if you organize objects by behavior.

• Primitive Obsession

Symptoms: Uses primitive or near primitive types as int, float, String…; Constants and enumerations representing small integers; String constants representing field names.

Causes:

What to do: For missing objects, encapsulate primitives types into new classes.

Payoff: Improves communication. May expose duplication. Improves flexibility. Often exposes the need for other refactorings.

• Data Class

Symptoms: the class consists only of public data members or of simple getting and setting methods. This lets clients depend on the mutability and representation of the class.

Causes:

What to do: “Encapsultate Fields” to block direct access to the fields allowing access only through getters and setters; “Remove Settings Methods” for any method you can and use “Hide Method” to eliminate access to the getters and setters where they’re not used (aquí no estoy de acuerdo, coste / beneficio no suele merecer nunca salvo en un Façade); “Encapsulate Collection” to remove direct acces to any collection-type fields.

Payoff: Improves communication. May expose duplication.

• Message Chains

Symptoms: Yo see calls like a.b().c().d()

What to do: Use “Hide Delegate” to make the method depend on one object only, so rather a.b().c().d() put the d() method on the “a” object. (Revisar, mi primera idea es que sería mejor crear un nuevo objeto x que contenga el método d(), y que “a” invoque a “x”)

Notes: Follow the object oriented programming maxim Tell, Don´t Ask so instead of asking for objects so that you can manipulate them, you simply tell them to do the manipulation for you, as the Law of Demeter says: A method should only talk to itself, never to strangers.

RGA recopila en formato libro de bolsillo los pasajes originales de Heródoto y Diodoro de Sicilia respecto este imperecedero evento. He leído bastante sobre este hecho, pero nunca de sus fuentes "originales", y gracias a un estupendo día de lluvia en Mallorca he podido degustar el original escuchando llover en una terraza.

PD Mucho tiempo sin leer con eso de ir a trabajar en coche… y sin tocar la guitarra, y sin… en fin, el estilo de vida moderno!

PPDD, nada más publicar esta entrada ya sale como resultado nº1 de google al buscar "la batalla de las termópilas rga", antes que RGA, antes que la wikipedia.

Siendo un hombre, ¿cómo puede uno saber de manera infalible lo que sea?[...] De ahí que los éxitos suelan sonreir generalmente a las personas decididas a actuar [...] en lugar de a analizar y vacilar ante todo.

Este ha sido uno de las adquisiciones en esta reciente Día del Libro. Otra ha sido una copia de Alamut, libro que ya había leído y comentado aquí gracias a una amgia que me lo prestó.

El libro que nos ocupa en esta ocasión es una magnífica novela por su ligereza y profundidad de pensamiento. Aunque no estoy de acuerdo en muchas de sus propuestas, me ha encantado el tener delante otro punto de vista (el oriental) presentado en un formato muy cercano (una novela escrita para occidentales). Entiendo que esta es la razón de su éxito en la generación beat.

El autor nos acerca a la vida de una persona (Siddharta, cuyo nombre es el mismo que el del fundador del budismo el buda Siddharta Gautama) en la búsqueda por la sabiduría a través de las disitintas etapas vitales por las que atraviesa desde su juventud como Brahmán integrado en su comunidad, su vida como asceta, su encuentro con el fundador del budismo, su acercamiento a la vida mundana y carnal a través de una cortesana y un rico comerciante y su humilde retiro como barquero de un río.

Es un libro de obligatoria lectura y relectura. Para esta segunda recomiendo conocer un poco más en profundidad términos como Samana, Brahmán, ATMAN, OM, Nirvana, Sansara, Maya.

Es bueno probar personalmente todo lo que hace falta aprender. Ahora lo he vivido y ahora lo sé no sólo porque me lo enseñaron.

Sólo soy un barquero. He cruzado a muchos y para todos ellos mi río sólo ha sido un obstáculo más en su camino.

cuando alguien busca, su ojo sólo se fija en el objeto que busca. Al no hallarlo no puede dejar entrar en su ser otra cosa que está a la vista.

 

Gomorra es un vómito literario sobre la mafia del Sur de Italia narrado por el periodista Roberto Saviano. Está basada en hechos reales y en experiencias propias del autor, quien se sumergió en dicho mundo para describirlo de primera mano. O eso dice él

Ey, has dicho vómito literario y lo recomiendas ? Sí. La realidad que describe es muy desagradable, es cercana, la situación normal del día a día sin visos de que vaya a cambiar. Es el Sistema. Y es presentada con la naturalidad y crudeza de quien abre su alma y vomita en el papel todo lo que arrastra desde hace años : no es una narración, no tiene una trama, la temática es confusa, desorganizada y difícil de seguir, no esperes una prosa bonita con recursos literarios.

En resumen, se presenta a el Sistema como corporaciones familiares similares a las corporaciones multinacionales por todos conocidas. El objetivo prioritario y único en ambos casos es maximizar su beneficio económico, pero para conseguirlo las multinacionales, limitadas por leyes, buscan todos los medios para interpretarlas en su beneficio. Mmientras el Sistema aprovecha esos nichos a las que las multinacionales no llegan (drogas, juego, prostitución, falsificaciones…) ya que no reconocen más ley que el beneficio económico : capitalismo salvaje en estado puro.

La sinceridad es siempre de mi gusto, pero en lo personal me gustaría que más adelante en el tiempo sacase otra publicación (al que seguramente llamarían en un alarde de originialidad Sodoma) al que podamos llamar libro, reposado, pensado, escrito en prosa, bien organizadito…

La película va más en este estilo, es más organizadita pero menos cruda en sus descripciones. Escoge una serie de personajes anónimos para mostrarnos cómo le afecta esta situación a la gente normal que vive en el Sur de Italia.