Economía del bien común

Christian Felber:

• Fundador de attac Austria y actual portavoz.
• Iniciador del proyecto “banco democrático”.
• Diseñador de la “economía del bien común”.
• Periodista independiente y escritor

Aquí la trancripción:

“Tengo el honor de presentaros un modelo económico alternativo al sistema de mercado capitalista pero también a la economía planificada.

La economía del bien común. Un modelo económico sostenible para el futuro.

Es un hecho que la gran mayoría de la población está anhelando una alternativa sistémica. Según una encuesta en Alemania y Austria el 90% de la población desea un modelo económico alternativo y la cuestión es a donde ir. Hacia una economía mas ecológica, Hacia una economía mas ecológica mas social, de distribución mas justa. Una economía más democrática, una economía que ponga en el centro al ser y mano y su dignidad. Y la propuesta de la economía del bien común es de todo un poco. El bien común creemos que es el concepto que abarca todos estos valores y todas estas metas y es el concepto más incluyente de todos.

Por ejemplo Alemania, en la Constitución de Baviera, dice literalmente: Toda actividad económica sirve el bien común.  O sea, el concepto no es nada nuevo. Lo nuevo es adaptar la economía real a las metas y los valores de las constituciones.

¿Sobre qué valores reposa la economía del bien común?

Hoy hay dos reglas de juego fundamentales que guían el comportamiento de los actores del mercado que son el afán de lucro y la competencia y estas dos coordenadas producen comportamientos y reproducen valores contrarios a aquellos que permiten florecer nuestras relaciones interhumanas. No importa donde se pregunta a los seres humanos en el mundo cuáles son lo comportamientos y los valores que permiten florecer estas relaciones. En todo el mundo la respuesta es confianza, honestidad, responsabilidad, cooperación, solidaridad, generosidad, compasión. En todo el mundo igual, y la propuesta es transformar estos principios y valores a la economía, en el sentido de que cuando una empresa realmente aplica y vive estos valores en toda su actividad más ventajas legales obtendrá. Para eso es necesario medir estos comportamientos y para esto es necesario redefinir el concepto de éxito económico.

¿Qué mide el balance del bien común?

El éxito económico se mide en todos los niveles con indicadores monetarios. En el nivel Macro a través del PIB, el Producto Interior Bruto, y a nivel micro, a nivel de la empresa concreta, con el beneficio financiero. Ambos indicadores de éxito tienen en común que son indicadores monetarios, dinero, y el dinero tiene la decisiva desventaja de que no es capaz de medir nada de lo que para nosotros, los seres humanos, y para el entorno ecológico es valioso e  importante.

El crecimiento del PIB no nos dice de forma absolutamente nada fiable si estamos en guerra o en paz, si vivimos en una democracia o en una dictadura, si el reparto de la renta es justo o totalmente injusto y hay hambre, si respetamos el medio ambiente o lo destruimos, si en una sociedad la confianza aumenta o hay miedo. Por ello muchas personas se preguntan por qué confundimos el bienestar de una sociedad con el PIB.

En el nivel micro un beneficio financiero mas alto no nos dice si esta empresa crea empleo o lo destruye, si la calidad de los empleos aumenta o baja, si las mujeres y los hombres son tratados de forma igual o desigual, si la empresa destruye el medio ambiente o lo conserva, si esa empresa produce armas o comestibles sostenibles regionales.

El beneficio financiero no nos sirve para medir el éxito y la contribución de una empresa a la sociedad y el bien común.

¿Cómo pueden contribuir las empresas a la economía del bien común?

El balance del bien común mide como una empresa vive la dignidad humana, la solidaridad, la justicia social, la sostenibilidad ecológica y la democracia con todos sus grupos de contacto: los suministradores, los proveedores de dinero, los empleados, los clientes, las co-empresas y el entorno social y ecológico hacia las generaciones del futuro.

Hemos desarrollado hasta hoy unos quince criterios que miden el comportamiento del bien común y lo que se obtendrá no serán unidades de dinero, sino simplemente puntos del bienc omún. Se puede lograr entre cero y mil puntos del bien común y se pueden crear cinco clases y hacer cinco colores del bien común y en cada producto figurará el color del bien común. De esta manera los consumidores tienen una información muy clara antes de tomar su decisión de compra. Pero lo mejor y más decisivo será que las empresas con los mejores resultados de sus balances del bien común obtendrán ventajas legales frente a aquellas empresas que no hacen ningún esfuerzo por el bien común. En concreto esas empresas pagaran menores impuestos, pagaran menores tarifas aduaneras, obtendrán créditos mas baratos y obtendrán prioridad en la compra pública.

El efecto inmediato sería que los productos éticos y justos serían más baratos en el mercado que los productos no justos, no éticos y no ecológicos.

Una situación muy deplorable de hoy, y además en contra del espíritu de las constituciones es que todas las empresas en todo el mundo pueden acceder al mercado sin importar como se comportan. Y esto es dar el mismo trato, el trato igual, a actores totalmente desiguales, eso no es justo, porque las constituciones nos dicen que tratemos igual a los iguales nada más, pero no a los desiguales, a los desiguales hay que tratarlos de forma desigual, hay que discriminarlos. Una empresa de comercio justo que paga un salario justo, que produce de forma ecológica, que da préstamos sociales de todo tipo no es igual a una corporación que viola los derechos humanos, que destruye el medio ambiente y que  no tiene en consideración alguna hacia a la sociedad y el futuro, y a estos desiguales no hay que tratarlos de forma igual porque si se les trata de forma igual la empresa no justa gana porque puede ofrecer a precios menores.

Hoy los injustos, los irresponsables, los no éticos, ofrecen productos más baratos y a través de la discriminación, en su mejor sentido, los productos éticos serán mas baratos que los no éticos.

Según el balance del bien común, ¿Qué aplicaciones estarán permitidas y cuáles no?

El balance financiero se degrada a ser solamente una medida de la actividad empresarial pero ya no expresa el fin de la empresa. Quiere decir, algunos usos de los excedentes financieros ya no estarán permitidos: por ejemplo inversiones meramente financieras, por ejemplo tragarse a otra empresa, por ejemplo dar una parte del beneficio financiero a personas que no trabajan en la empresa, por ejemplo donaciones a partidos políticos.

Para darle también un marco en cuanto a la propiedad proponemos que se limite la desigualdad de renta con salarios mínimos y máximos. Al derecho a tener propiedad privada ponerle un límite y al derecho a heredar también, y lo que exceda ese límite que se reparta entre los que no heredan nada, para tener una mayor igualdad de oportunidades al principio de la vida profesional.

Estas cuestiones proponemos que se negocien y se conviertan en leyes en convecciones económicas, estos deberían ser elegidos por las personas y adoptadas por el pueblo soberano y nadie más. Los cambios son posibles poco a poco pero solo por cada pueblo soberano. Estas son las ideas básicas de la Economía del Bien Común, que no solo es una idea sino que es un proceso social que empezó a implementarse en Octubre de 2010, o sea, ahora llevamos unos 10 meses en el camino y se han adherido más de 340 empresas a este proceso como participantes, 120 de ellas, y de cuatro países,  implementan el balance del bien común este año por primera vez a nivel voluntario. Así no solamente estamos formando un grupo de pioneros sino también un movimiento político porque todas las empresas, las que apoyan este modelo, se entienden como un movimiento político que reivindica al parlamento y al gobierno que convierta esas propuestas en leyes concretas y, mas bien, que se convoque esa convección económica que acabo de presentar.

El modelo no esta hecho, al contrario, el modelo acaba de empezar con unas propuestas y está totalmente abierto y está esperando a que muchas, muchas personas, influyan con sus contribuciones para mejorarlo y desarrollarlo.

La Economía del Bien Común no dice que su modelo sea el mejor de todos o la única vía sino al contrario, hay muchísimas alternativas, hay 30, 40, 100 alternativas que todos necesitamos y que se deben inspirar y apoyar mutuamente como la economía solidaria, como los bienes comunes, como unos mercados financieros o un sistema de dinero sin interés, como la permacultura, como la agricultura sostenible, como salud alternativa, etc.

Hay un gran concierto de alternativas que se deben inspirar mutuamente y la economía del bien común es una de ellas y la invitación es a que todo el mundo contribuya al proceso. Ahora tenemos 12 ramas de actuación por ahora en Alemania, Austria, Italia y  Suiza, pero en cualquier parte del mundo todo el mundo es bienvenidos a empezar un llamado campo de energía regional, buscar las primeras empresas de tu municipio y de esta forma engancharte al proceso. 

¡Bienvenido!

Patrones de diseño

¿Qué son los patrones de diseño?


Se entiende por patrones de diseño a soluciones limpias y elegantes a problemas conocidos. Hay patrones de creación, patrones estructurales y patrones de comportamiento. 

Patrones de creación:

• Abstract Factory 

• Builder

• Factory Method

• Prototype

• Singleton

• Abstract Factory
Proporciona una interfaz para crear familias de objetos que dependen entre sí, sin especificar sus clases concretas. El problema que intenta solucionar este patrón es el de crear diferentes familias de objetos.


El patrón Abstract Factory está aconsejado cuando se prevé la inclusión de nuevas familias de productos, pero puede resultar contraproducente cuando se añaden nuevos productos o cambian los existentes, puesto que afectaría a todas las familias creadas.

Estructura 

Cliente: es la clase que usará la factoría adecuada para crear instancias concretas de objetos..

AbstractFactory: define la interfaz de las factorías concretas. Expone métodos para la obtención de cada objeto que puede crear.

Factorías Concretas: diferentes factorías de objetos. Devuelve instancias concretas.

Objeto abstracto: define la interfaz que luego implementarán los objetos concretos. El cliente trabajará directamente sobre esta interfaz y no con los objetos concretos.

Objeto concreto: iplementación concreta de los diferentes productos. El cliente no sabrá si usa unos objetos de un tipo o de otro puesto que trabajará directamente sobre la superclase o interfaz.

• Builder
Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones. A menudo, el patrón builder construye el patrón Composite, un patrón estructural explicado más adelante.


El patrón Builder (Contructor) centraliza el proceso de creación en un único punto, de tal forma que el mismo proceso de construcción pueda crear representaciones diferentes.

Estructura:
Builder: es la interfaz abstracta para crear productos.
Concrete Builder: es la implementación del Builder, construye y reúne las partes necesarias para construir los productos
Director: construye un objeto usando el patrón Builder
Producto: El objeto complejo bajo construcción

Ventajas:
•Reduce el acoplamiento.
•Permite variar la representación interna de estructuras compleja, respetando la interfaz común de la clase Builder.
•Se independiza la creación de la representación. Las clases concretas que tratan las representaciones internas no forman parte de la interfaz del Builder.
•Cada ConcreteBuilder tiene el código especifico para crear y modificar una estructura interna concreta.
•Distintos Director´s con distintas responsabilidades pueden utilizar el mismo ConcreteBuilder.
•Permite un mayor control en el proceso de creación del objeto. El Director controla la creación paso a paso, solo cuando el Builder ha terminado de construir el objeto lo recupera el Director.

  

• Factory Method
Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos. Es una simplificación del Abstract Factory, en la que la clase abstracta tiene métodos concretos que usan algunos de los abstractos; según usemos una u otra hija de esta clase abstracta, tendremos uno u otro comportamiento.

  

• Prototype
Especifica los tipos de objetos a crear por medio de una instancia prototípica, y crea nuevos objetos copiando este prototipo. Este patrón resulta útil en escenarios donde es preciso abstraer la lógica que decide qué tipos de objetos utilizará una aplicación, de la lógica que luego usarán esos objetos en su ejecución. 

• Singleton
Garantiza que una clase sólo tenga una instancia, y proporciona un punto de acceso global a ella. 

El patrón singleton provee una única instancia global gracias a que:

• La propia clase es responsable de crear la única instancia.
• Permite el acceso global a dicha instancia mediante un método de clase.
• Declara el constructor de clase como privado para que no sea instanciable directamente.

Veamos varias implementaciones:

Lazy initialization


public class Singleton {


        private static Singleton _instance; 
        private Singleton() {  } 


        public static synchronized Singleton getInstance() {
                if (null == _instance) {
                        _instance = new Singleton();
                }
                return _instance;
        }
}

Traditional simple way
public class Singleton {


        private static final Singleton instance = new Singleton();

        // Private constructor prevents instantiation from other classes
        private Singleton() { }

        public static Singleton getInstance() {
                return instance;
        }
}

The solution of Bill Pugh

public class Singleton {

        // Private constructor prevents instantiation from other classes

        private Singleton() { }

        private static class SingletonHolder { 

                public static final Singleton instance = new Singleton();

        }

        public static Singleton getInstance() {

                return SingletonHolder.instance;

        }

}

[TODAVÍA ESTOY TRABAJANDO EN ESTA ENTRADA PERO QUERÍA PUBLICARLA YA]

Patrones estructurales:

• Adapter

• Bridge

• Composite

• Decorator

• Facade

• Flyweight

• Proxy

• AdapterConvierte la interfaz de una clase en otra distinta que es la que esperan los clientes. Permiten que cooperen clases que de otra manera no podrían por tener interfaces incompatibles.

  

• Bridge
Desvincula una abstracción de su implementación, de manera que ambas puedan variar de forma independiente.

• CompositeCombina objetos en estructuras de árbol para representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.

• Decorator
Añade dinámicamente nuevas responsabilidades a un objeto, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.

 • FacadeProporciona una interfaz unificada para un conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema sea más fácil de usar.

• Flyweight
Usa el compartimiento para permitir un gran número de objetos de grano fino de forma eficiente.

• Proxy
Proporciona un sustituto o representante de otro objeto para controlar el acceso a éste.

Patrones de comportamiento:

• Chain of Responsibility

• Command

• Interpreter

• Iterator

• Mediator

• Memento

• Observer

• State

• Strategy

• Template Method

• Visitor

• Chain of Responsibility
Evita acoplar el emisor de una petición a su receptor, al dar a más de un objeto la posibilidad de responder a la petición. Crea una cadena con los objetos receptores y pasa la petición a través de la cadena hasta que esta sea tratada por algún objeto.

  

• Command
Encapsula una petición en un objeto, permitiendo así parametrizar a los clientes con distintas peticiones, encolar o llevar un registro de las peticiones y poder deshacer la operaciones.

  

• Interpreter
Dado un lenguaje, define una representación de su gramática junto con un intérprete que usa dicha representación para interpretar las sentencias del lenguaje.

  

• Iterator
Proporciona un modo de acceder secuencialmente a los elementos de un objeto agregado sin exponer su representación interna.

  

• Mediator
Define un objeto que encapsula cómo interactúan un conjunto de objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran unos a otros explícitamente, y permite variar la interacción entre ellos de forma independiente.

  

• Memento
Representa y externaliza el estado interno de un objeto sin violar la encapsulación, de forma que éste puede volver a dicho estado más tarde.

  

• Observer
Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambia de estado se notifica y actualizan automáticamente todos los objetos.

  

• State
Permite que un objeto modifique su comportamiento cada vez que cambia su estado interno. Parecerá que cambia la clase del objeto.

 • Strategy
Define una familia de algoritmos, encapsula uno de ellos y los hace intercambiables. Permite que un algoritmo varíe independientemente de los clientes que lo usan.

  

• Template Method
Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura.

 • Visitor
Representa una operación sobre los elementos de una estructura de objetos. Permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera.

Author

Juan García Carmona

GRASP: General Responsibility Assignment Software Patterns

GRASP son patrones generales de software para asignación de responsabilidades, es el acrónimo de "General Responsibility Assignment Software Patterns". Aunque se considera que más que patrones propiamente dichos, son una serie de "buenas prácticas" de aplicación recomendable en el diseño de software. Las buenas prácticas son las siguientes:

• Experto en información
• Creador
• Controlador
• Alta cohesión / Bajo acoplamiento
• Polimorfismo
• Fabricación pura
• Indirección
• Variaciones protegidas

Experto en información
El GRASP de experto en información es el principio básico de asignación de responsabilidades. Nos indica, por ejemplo, que la responsabilidad de la creación de un objeto o la implementación de un método, debe recaer sobre la clase que conoce toda la información necesaria para crearlo. De este modo obtendremos un diseño con mayor cohesión y así la información se mantiene encapsulada (disminución del acoplamiento)
Problema: ¿Cuál es el principio general para asignar responsabilidades a los objetos?
Solución: Asignar una responsabilidad al experto en información.
Beneficios: Se mantiene el encapsulamiento, los objetos utilizan su propia información para llevar a cabo sus tareas. Se distribuye el comportamiento entre las clases que contienen la información requerida. Son más fáciles de entender y mantener.


Creador
El patrón creador nos ayuda a identificar quién debe ser el responsable de la creación (o instanciación) de nuevos objetos o clases.
La nueva instancia podrá ser creada por una clase que:

• Tenga la información necesaria para realizar la creación del objeto
• Use directamente las instancias creadas del objeto
• Almacene o maneje varias instancias de la clase
• Contenga o agregue la clase.

Una de las consecuencias de usar este patrón es la visibilidad entre la clase creada y la clase creadora. Una ventaja es el bajo acoplamiento, lo cual supone facilidad de mantenimiento y reutilización La creación de instancias es una de las actividades más comunes en un sistema orientado a objetos. En consecuencia es útil contar con un principio general para la asignación de las responsabilidades de creación. Si se asignan bien el diseño puede soportar un bajo acoplamiento, mayor claridad, encapsulación y reutilización.


Controlador
El patrón controlador es un patrón que sirve como intermediario entre una determinada interfaz y el algoritmo que la implementa, de tal forma que es la que recibe los datos del usuario y la que los envía a las distintas clases según el método llamado.
Este patrón sugiere que la lógica de negocios debe estar separada de la capa de presentación, esto para aumentar la reutilización de código y a la vez tener un mayor control.
Se recomienda dividir los eventos del sistema en el mayor número de controladores para poder aumentar la cohesión y disminuir el acoplamiento.


Alta cohesión y bajo acoplamiento
Los conceptos de cohesión y acoplamiento están íntimamente relacionados. Un mayor grado de cohesión implica uno menor de acoplamiento. Maximizar el nivel de cohesión intramodular en todo el sistema resulta en una minimización del acoplamiento intermodular.


Alta cohesión
Nos dice que la información que almacena una clase debe de ser coherente y debe estar (en la medida de lo posible) relacionada con la clase.
1. Cohesión Coincidente: El módulo realiza múltiples tareas, sin ninguna relación entre ellas.
2. Cohesión Lógica: El módulo realiza múltiples tareas relacionadas, 
pero, en tiempo de ejecución, sólo una de ellas será llevada a cabo.
3. Cohesión Temporal: Las tareas llevadas a cabo por un módulo tienen, como única relación el deber ser ejecutadas “al mismo tiempo”.
4. Cohesión de Procedimiento: La única relación que guardan las tareas de un módulo es que corresponden a una secuencia de pasos propia del “producto”.
5. Cohesión de Comunicación: Las tareas corresponden a una secuencia de pasos propia del “producto” y todas afectan a los mismos datos.
6. Cohesión de Información: Las tareas llevadas a cabo por un módulo tienen su propio punto de arranque, su codificación independiente y trabajan sobre los mismos datos. El ejemplo típico: OBJETOS
7. Cohesión Funcional: Cuando el módulo ejecuta una y sólo una tarea, teniendo un único objetivo a cumplir, se dice que tiene Cohesividad Funcional.


Bajo acoplamiento
Es la idea de tener las clases lo menos ligadas entre sí que se pueda. De tal forma que en caso de producirse una modificación en alguna de ellas, se tenga la mínima repercusión posible en el resto de clases, potenciando la reutilización, y disminuyendo la dependencia entre las clases
1. Acoplamiento de Contenido: Cuando un módulo referencia directamente el contenido de otro módulo. (En lenguajes de alto nivel es muy raro)
2. Acoplamiento Común: Cuando dos módulos acceden (y afectan) a un mismo valor global.
3. Acoplamiento de Control: Cuando un módulo le envía a otro un elemento de control que determina la lógica de ejecución del mismo.


Polimorfismo
Siempre que se tenga que llevar a cabo una responsabilidad que dependa del tipo, se tiene que hacer uso del polimorfismo, cuando las alternativas o comportamientos relacionados varían según el tipo (clase), asigne la responsabilidad para el comportamiento- utilizando operaciones polimórficas a los tipos para los que varía el comportamiento. Asigna el mismo nombre a servicios en diferentes objetos.


Fabricación Pura
La fabricación pura se da en las clases que no representan un ente u objeto real del dominio del problema, sino que se ha creado intencionadamente para disminuir el acoplamiento, aumentar la cohesión y/o potenciar la reutilización del código. Es la solución cuando el diseñador se encuentre con una clase poco cohesiva y no tenga otra clase en la que implementar algunos métodos. Es decir que es una clase "inventada" o que no existe en el problema como tal, pero que añadiéndola se logra mejorar estructuralmente el sistema. Como contraindicación deberemos mencionar que al abusar de este patrón suelen aparecer clases función o algoritmo (que tienen un solo método).


Indirección
El patrón de indirección nos aporta mejorar el bajo acoplamiento entre dos clases asignando la responsabilidad de la mediación entre ellos a un tercer elemento (clase) intermedio
Problema: ¿Dónde asignar responsabilidades para evitar/reducir el acoplamiento directo entre elementos y mejorar la reutilización? 
Solución: Asigne la responsabilidad a un objeto que medie entre los elementos.


Variaciones Protegidas
Es el principio fundamental de protegerse del cambio, de tal forma que todo lo que preveamos en un análisis previo que es susceptible de modificaciones, lo envolvamos en una interfaz, utilizando el polimorfismo para crear varias implementaciones y posibilitar implementaciones futuras, de manera que quede lo menos ligado posible a nuestro sistema, de forma que cuando se produzca la variación, nos repercuta lo mínimo.

Author

Juan García Carmona

SOLID

Estos cinco principios hay que tenerlos siempre presentes si queremos desarrollar un software de calidad, legible, entendible y fácilmente testeable:

Inicial	Acronimo	Concepto
S	SRP	Principio de Única Responsabilidad (Single Responsibility Principle) Un objeto solo debería tener una única responsabilidad.
O	OCP	Principio Abierto/Cerrado (Open / Closed Principle) Las entidades de deben estar abiertas para su extensión, pero cerradas para su modificación.
L	LSP	Principio de sustitución de Liskov (Liskov Substitution Principle). Objetos de tipo T podrán ser convertidos a objetos de tipo S, un subtipo de T, sin perder información relevante a objetos de tipo S.
I	ISP	Principio de Segregación de la Interface (Interface Segregation Principle) Muchas interfaces cliente específicas son mejores que una interfaz de propósito general.
D	DIP	Principio de Inversión de Dependencia (Dependency Inversion Principle) Depender de Abstracciones y no de concreciones.

Autor:

Juan García Carmona

Preparar el entorno para desarrollar para Android

1º Instalar Eclipse (clásic), el SDK de Android y el plugin de Android.

No me enrollo mucho con ésto porque hay un montón de manuales al respecto.

2º Instalar subclipse, es según leo es el cliente de subversion más utilizado con eclipse.

Un buen manual aquí:
http://mundogeek.net/archivos/2009/02/22/subclipse-plugin-de-subversion-para-eclipse/

Aunque habría que actualizar la fuente del plugin u usar el último de la página de subclipse:
http://subclipse.tigris.org/

De momento mi entorno está preparado. Voy a configurar mi repositorio y a buscar un emulador de dispositivos Android. ¡Encontrado!:
http://developer.android.com/guide/developing/devices/emulator.html

Días Ociosos

No sabría ubicar en el tiempo mi primera línea de código pero si que recuerdo mi primer gran error en informática. Allá por el neandertal intenté arreglar el ordenador a un niño amigo mío, el ordenador de su padre en realidad, un IBM PS1 o incluso anterior. La experiencia me decía que era fácil arreglar un disco escribiendo format a: pero el ordenador de mi amigo no reaccionó nada bien después de decirle format c: y su padre tampoco.

Equivocarse en informática es fácil. ¿Cuántas veces hemos oído aquello de "por culpa de un error informático"? Pues demasiadas. Desgraciadamente los errores son nuestros por culpas de despistes, de mala organización o de mala aplicación de la tecnología. Somos nosotros, los informáticos, quienes aplicamos con mayor o menor fortuna nuestros conocimientos en informática y quienes, a veces, provocamos cagadas estrepitosas.

Comienzo este blog en mi primer día de baja, de momento, a falta de pruebas, no se cuánto va a durar ésto. Como me veo delante del ordenador diez horas al día o más y no quiero volverme loco de remate de tanto programar he decidido publicar cada investigación que haga para compartirlo con cualquiera y también así tenerlo accesible cuando lo pueda necesitar.

Quiero repasar, reafirmar y mejorar mis conocimientos en ingeniería del software, en gestión de proyectos, .NET y JAVA además de aprender HTML5 y a programar aplicaciones para dispositivos móviles.

Durante estos días ociosos éste blog será el canalizador de mi paciencia. Empezaré por una lista con cosas que hacer.