domingo, 27 de octubre de 2013

Ya son mas de 1.000.

Hace menos de tres años escribí en esta entrada que ya teníamos localizados más de 500 candidatos a exoplanetas. Desde 1992 hasta esa fecha se habían localizados 500 planetas fuera del Sistema Solar. Menos de tres años después, ese número supera los 1.000. En concreto, en el catálogo de exoplanets.eu dice que hay:
  • 782 sistemas planetarios, de los que 170 son múltiples (más de un planeta)
  • 1028 planetas
Hemos pasado de detectar 27 planetas al año a detectar más de 150. Antes se localizaban planetas del tamaño de Júpiter o muy superiores y ahora se han localizados planetas con una masa 2-3 veces superior a la de la Tierra. 

El el futuro supongo que se seguirán localizando nuevos plantetas, se afinaran los ya conocidos, algunos se caerán de la lista, otros se incorporarán (en más de 600 casos solo se ha localizado un planeta en su sistema) y aparecerán mas sistemas con múltiples planetas.

Todavía queda mucho para el salto a las estrellas (si es que se produce alguna vez) pero antes de ellos, habrá que hacer el mapa ¿no? Pues eso es esta lista de exoplanetas.

lunes, 21 de octubre de 2013

Cosillas que no te cuentan cuando estás estudiando informática.

En las entradas anteriores vimos como a la hora de emprender un proyecto ni las cosas son tan simples ni tan baratas como se piensa. De hecho, cuando alguien te dice que "yo tengo una web por cuatro duros" (como este blog por ejemplo) obvia el hecho de que detrás hay a serie de horas de trabajo y muchísimas más horas de estudio, preparación y experiencia. Pues aparte de esos, en la vida hay una serie de "sorpresas" que no te suelen contar y con las que posiblemente te vas a encontrar tarde o temprano.

El backup, ese gran desconocido.

Seguramente te habrán dicho millones de veces que es necesario un backup ... y nada más. Te imaginarás que el backup es una cosa sencilla, estandarizada, simplona, barata ..... ¡y una mierda!

Para empezar se pueden hacer copias de muchas cosas. Lo interesante es hacer copias de la cosa correcta y no por ejemplo, de los links simbólicos (ha pasado) 

Se puede hacer copias de muchas cosas:
- Datos. Parece lo mas lógico ¿no? Pues si, el o mas lógico, pero claro hay que saber qué tipos de datos porque no es lo mismo hacer una copia de ficheros de texto o de Word que copiar los datos de una base de datos. Según lo que tengas que sacar, se hace una forma u otra y las hay harto complicadas.
- Fuentes. Cuando están trabajando en un proyecto de desarrollo parece lógico hacer copia de los fuentes, no sirve con dejarlos en el repositorio CVS, hay que salvaguardar éste. La no protección de estos datos te puede dar  lugar a situaciones surrealista como alguien que le dijo a su jefe "Oye, que he perdido los fuentes pero no te preocupes, que tengo los ejecutables"  Lo malo de esto es que no es coña (bueno, pasó hace bastantes años) También recuerdo de una aplicación en mainframe que en lugar de COBOL estaba en ensamblador. La explicación oficial era que estaba así para mejorar las prestaciones. La extraoficial era que se habían perdido los fuentes y se había desensamblado para poder parchear el efecto 2000.Por cierto, ese sistema se quería haber sustituido a principios de los años 90 (por antiguo) y por el 2005 creo que seguía dando guerra.
- Configuraciones. Aunque no lo parezca, hay veces que hace falta reinstalar un sistema y el volverlo a configurar (si ha perdido la configuración o se está creando un nuevo entorno) es de lo más doloroso.
- El Sistemas Operativo. Pues aunque no lo parezca pues puede interesar para recuperar el sistema completo. En virtualización el lanzar un snapshot es na manera sencilla de obtener un backup. En virtualización se hace más o menos bien, pero ojo con las máquinas físicas que si no se sabe lo que hace es fácil obtener ... una máquina lista para formatear y reinstalar, y aunque no lo parezca, el trabajo ese, junto con el lucro cesante por  no tener la máquina operativa puede ser más oneroso que el coste de la máquina.

Afortunadamente hoy en día hay sistemas de backup que simplifican mucho esta labor, pero en el pasado muchos sistemas operaban con una política de backup muy deficiente o casi sin ella (copias semanales o mensuales) Lo malo es que precisamente no son baratos.

Un detalle curioso. Muchos sistemas de esos de cierta empresa de tres letras que no voy a nombrar y que presumen de sus five nines y de que nunca se paran resulta que paran todos los días un par de horas para hacer el backup ....

El restore o ¡que tutto, prefiero la muette!

Que le recupere ¿qué?
Creo que hay por ahí una estadística que afirma que un muy alto porcentaje de los backup que se hacen no se pueden recuperar. No soy yo quien vaya a llevar la contraria al estudio ... pero me lo creo. Dado que por lo general, no se hacen recuperaciones más de que de manera puntual la dificultad de recuperar un dato de un backup aumenta exponencialmente a medida que pasa el tiempo. Es fácil recuperar el último hecho (machacando todo el trabajo) pero como tengas que recuperar información de hace algún tiempo la cosa se complica y mucho. No solo el acceder a la BD de objetos preservado puede ser increíblemente complicado por su número y versiones. El localizar un fichero determinado de hace unos meses que se haya volcado a cinta puede costar varias horas. Afortunadamente, los usuarios  no suelen ser conscientes de estas capacidad, por lo que el tener que restaurar cosas antiguas no suele ser lo normal, aunque en ciertos ámbitos, puede ser normal. Por ejemplo, en un hospital te pueden reclamar una radiografía de hacer un montón de años para ver si una manchita que te han visto estaba allí hace años o es nueva.

Si es posible, o mejor es restaurar en otro sitio aparte y luego, te llevas lo que quieres al sitio correcto.

El firmware y la madre que lo parió.

Al parecer a la gente que se dedica al software no le mola mucho el meterse en las cosas del firmware. Les parecen cosas raras, frikies, .... de muy bajo nivel. Bueno, razón no les falta pero tampoco hay que olvidar que tiene su importancia. Las actualizaciones de firmware puede solventar diversos problemas que no te tienen por qué afectar directamente pero tienen su importancia en dos aspectos claves:

- El fabricante no te da soporte si no tienes la última versión del firmware. Dado que por lo general, una actualización de firmware suele precisar tener el sistema parado a los responsables de explotación no les suele gustar demasiado ... hasta que peta algo, momento en el que se remueve Roma con Santiago para dejarlo todo como se debe en un tiempo record. La frase "como pollos sin cabeza" suele aplicar bastante bien en estas circunstancias.
A ver, tengo que actualizar el firmware del blade,
del switch, de la cabina, del ....


- Las matrices de compatibilidad. Es un sub-caso del anterior, pero un poco más cabrón. Tu puedes tener tu sistemilla funcionando de p.m., sin interrupción y amplias el HW con una cabina ultimo modelo, unos servidores nuevos, unas cabinas de discos superguays .... y de repente te dicen que si quieres soporte es con una versión de firmware determinada .... y entonces es cuando te tiemblas las piernas porque para poner un blade nuevo tienes que actualizar el firmware de la cabinas, pero como esta conectada a un switch de fibra tienes que actualizar el firmware de los SFP y del switch, que por simpatía arrastra el cambio de firmware de otra cabina de disco .... total, que al final acabas actualizado hasta los interruptores de la luz, el extintor de incendios y la cafetera Nespresso. Y no veas el miedito que da todo eso. Eso sí, después de tomar todas las precauciones habidas y por haber, preparar alternativas, HW redundante, comunicaciones alternativas ... va el firmware y actualiza a la primera en 10 minutos dejándote con cara de tonto y pensando "¿y hacía falta todo esto?" Pues sí. Te en cuenta que como se te olvidara algo, te iba a petar ahí. Y por cierto, el caso que acabo de contar ... no me lo he inventado.

No obstante, el numero de máquinas con un firmware obsoleto que ya no existe ni en la fábrica como recuerdo es mucho mayor de lo parece.

Actualizaciones de software. Más peligro que una piraña en un bidé.

Se dice que el hardware es algo que puedes partir de un hachazo, al softwre sólo lo puedes maldecir. Pues es igual de cabrón que el firmware, si no más. Encima, tiene la manía de hacer gracias como cambiar APIS y funcionalidades como hace el JAVA, dejar de funcionar cosas (muy de Windows Update) cambiarte la configuración de red como hace el Linux, .... eso cuando no tenemos la costumbre de reiniciar el ordenador o como poco la aplicación. En aplicaciones que deben funcionar en 7x24 (cada vez más) se hace en horas tan bonitas como la noche del lunes al martes entre las 02:00 y las 03:00 y cosas similares.
- Creo que tenemos un problema ¿actualizamos?
- Nada, tu sigue, que de momento, no hay problemas

Al igual que con el firmware, hay sistemas corriendo en sistemas obsoletos por todas partes con los que los informáticos sudan la gota gorda cuando hay que montar, por ejemplo, un entorno igual para hacer desarrollo, pruebas o sencillamente, cambiar el sistema dónde está corriendo porque es viejo. Vete a buscar el SW que tiene instalado.

Este software tiene bugs ... vamos a actualizarlo.

Esta frase tan inocente es uno de los mayores quebraderos de cabeza con que se suelen encontrar los responsables de los sistemas. No es lo mismo actualizar un PC que un SGBD pero vamos, lo dicho antes aplica aquí. Y al igual que con lo anterior, hay auténticas reliquias por esos mundos de dios.

No busques al enemigo fuera ... lo tienes en casa.

A todo el mundo le suenan los  peligro de la Internet, los hackers y demás mandanga. Pues eso, por lo general, con una buena política de seguridad, un buen firewall y un poco de sentido común añadido todo ello a un buen equipo de BOFHers (no vale el sobrino del jefe) suele estar bien controlado.

No me refiero a eso ... me refiero al enemigo interior. A los errores de la capa 8 del modelo OSI ... y a algo peor, la capa 9 (los jefes de la capa 8)

Cuando hablo de los errores de capa 8 no me estoy refiriendo a las chiquillerías de algunos usuarios inexpertos que se narran magistralmente en algunos blog si no a otros bastante más peligrosos que son perpetrados por presuntos sysadmin que en el mejor de los casos no están preparados para las tareas encomendadas (porque el que sabía ha sido despedido porque el economista de turno ha dicho que era muy caro "y total, eso lo hace cualquiera") Y no solo hablo de conocimientos técnicos (sistemas operativos, bases de datos, administración de redes y demás) sino de conocer un poco la aplicación y su entorno.
Usuario agazapado esperando armarla sin que le pillen.

Para dar algunos ejemplos, hay sitios donde está directamente prohibido instalar nada la última semana del mes (periodo de facturación) ... vete a saber por qué, a saber que gloriosas experiencias habrán tenido.

Hay una gloriosa frase emitida por una directora de una gran empresa ante el error de uno de sus subordinados por "exceso de iniciativa" (vamos, que se saltó todos los procedimientos y metió en producción un parche que no había pasado siquiera por pruebas de sistemas)
¡¡¡ Es que tengo el enemigo en casa !!!
Por cierto, ni que decir tiene que el enemigo llegó muy alto (pero muy, muy alto)

El miedo a cagarla.

Esto podría parecer lógico pero en realidad no lo es tanto. Es como si un electricista le tuviera miedo a un cable y por eso no lo toca. Por supuesto que hay que tener precaución con lo que se hace, preparar las cosas muy bien, revisar los procesos (mejor entre varios que uno solo) pero de un tiempo a esta parte se detecta en el personal en general un miedo a cagarla que por lo general, se avanza muy poquito.

Cierto es que no se puede hacer lo del ejemplo anterior, pero entre la informática kamikaze y el (a mi juicio) exceso de prudencia existente hay un mundo. Se pueden hacer cosas teniendo las precauciones adecuadas y con planes de contingencia se puede hacer cosas, pero últimamente parece que hay tal temor a meter la pata que parece que no se hace nada por no equivocarse. Claro que habida cuenta que muchos de los profesionales que mantenían esos sistemas ya no están (o se han ido o los han ido)


jueves, 3 de octubre de 2013

Vamos a diseñar un sistema informático (III)

En las entradas previas estuve contando un poco como suelen ser las cosas a la hora de montar un sistema informático. Está redactado en clave de humor pero si alguien ha estado metido en dicha vorágine, sabe que las cosas se parecen más a la realidad de lo que le podría parecer a un profano. 

Los sistemas son en realidad más complejos de lo que piensa la gente o más simples de lo que piensan algunos. Para un buen ingeniero informático el sistema tendrá su trabajo y su complejidad pero está controlado. Para un profano lo que empieza como algo simple como un vídeo para cambiar un grifo de Bricomanía se puede acabar complicando más que la Sagrada Familia. Al final, zapatero a tus zapatos y deja al profesional hacer su trabajo que es lo mejor y en la informática no hay excepciones a esta regla. 

Con base en el texto hay una serie preguntas que pueden surgir al respecto:

1.- ¿Son los sistemas informáticos tan caros como parecen?

Pues depende, como diría el gallego.  Depende de lo que incluyan (lo de las licencias de Oracle que puse antes no es coña, es un precio auténtico) Los sistemas hechos a medida son caros porque se hacen desde cero. si se pudieran reutilizar varias veces el precio bajaría en picado. Luego, el número de veces que el cliente cambie de opinión es un sobrecoste, al igual que los cambios no previsto (legislativos, de negocio, ...) Por ejemplo, la empresa MultiEnterprise en el país A y el país B comparten un sistema para dar servicio a sus clientes. El sistema está ubicado en A, pero por la Ley de protección de datos de B, éstos deben residir en éste. Consecuencia, te montas una nueva instancia de la aplicación en el otro país, con todo el coste asociado. Obviamente, un tema legal aquí ha repercutido claramente en el coste de explotación.
Vale, repito gráfico, pero como lo he hecho
yo no pago derechos a nadie.

Otro ejemplo es cierta comunidad que sacó hace años un sistema por unos 7 millones de € ¿es caro? Pues habida cuenta que primero había que descontar el IVA y que luego incluía el precio de las licencias de cierta sistema cuyo importe ascendía 3,6 millones resultó que no era precisamente un chollo. Y la empresa que se lo llevó no acabó en plazo ni de coña, pero eso es otra historia.

Al final, depende de lo que haga, el tiempo, lo que incluya, .... Un sistema de 10 millones de € puede ser barato y otro de 50.000 € puede ser caro. A priori y sin conecer el asunto, no se puede decir. Además, no hay que olvidar que lo que sale en prensa no tiene por qué corresponderse con la realidad. No cuesta lo mismo por ejemplo, montar y explotar una aplicación relativamente simple con una BD en una sitio que no haya nada (lo pagas todo) que aprovechar una infraestructura existente.

2.- ¿Es un sistema una Web y poco más?

Ni de coña. Las web es sólo la capa de presentación de la aplicación. Es cierto que una mala web te puede arruinar la aplicación y merece su trabajo, pero por detrás hay un potente trabajo de análisis, un diseño de la aplicación, una fase de pruebas y una explotación. El uso de metodologías ágiles no evita que como algo nazca torcido sea muy jodido enderezarlo (como todo, cuanto antes detectes el fallo, antes lo arreglas) El problema es cuando el cliente no tiene muy claro lo que quiere o presiona para que las cosas se hagan a toda prisa (el famoso "Si funciona no lo toques") Aquí sale un ejemplo de ello en clave de humor. Claro que cuando has sufrido algo similar ya te hace menos gracia.

3.- Si funciona, no lo toques.

Esta es la mayor falacia en el mundo de la informática. Funcionar funciona pero ¿funciona bien? No es lo mismo funcionar (hacer algo) que funcionar bien (y rápido, claro) Si una aplicación interactiva tarda cinco minutos en resolver una consulta a la BD la cosa no funciona bien aunque la respuesta sea excelente. Recuerdo haber tenido un compañero que era un fiera del SQL pero no dominaba tanto las bases de datos con lo que le gustaba más el JOIN que a un tonto una tiza. La consecuencia es que la BD tiraba a hacer FULL SCAN por menos de nada. Alguien podrá decir "pues mete un índice" y la idea de no es mala ... salvo cuando los administradores de la BD no te dejan (pasa y mucho)

A priori, un sistema, hasta que no ha pasado un tiempo en producción y es estable, va rápido, no pierde iformación, ... no se le puede considerar que funciona (y aún así) De hecho, a los errores y/o problemas que se encuentra un sistema en sus inicios se les conoce como errores de infancia.

4.- Esto falla y no he hecho nada. Ayer iba bien ¿qué ha pasado?

Yo no toco nada ... además, las fotos de gaticos
atraen visitas al blog.
No has tocado nada ... ¡LOS COJONES! no has hecho nada cachoperrohijodemilpadres ¿a quién quieres engañar? Las cosas no pasan por que sí. Siempre hay una relación causa efecto y las cosas no se estropean de un día para otro porque sí. O bien degeneran poco a poco (véase el ejemplo del punto anterior) o si no fallan desde el primer día, no fallan de golpe. Algo han hecho. Volviendo al modo abuelo Cebolleta, recuerdo un caso es que un sistema se nos empezó a caer de un día para otro. El número de usuarios no había cambiado. La última actualización había sido hacía tres meses al menos ... y el cliente no había hecho nada ¡Y UNA MIERDA! El muy perro había desplegado otro sistema que atacaba nuestra BD cada dos minutos con una consulta sin índice. Eso sí, la culpa había sido nuestra, no suya ni de los otros que ni siquiera lo habían probado. Por suerte, se hizo un índice y asunto resuelto tras un rapapolvo por no ser proactivos, no cuidar al cliente ..... (exacto. Como puta por rastrojo)

5.- Un sistema ¿funciona solo, sin nadie que le moleste?

Pues que suerte has tenido ya que desde que comencé a trabajar con entornos en red la mayor pesadilla se encuentra en una cosa llamada interfaces. Incluso cuando trabajábamos con sistemas stand-alone ya tenían interfaces muy simples, a base de ficheros y demás para por ejemplo llevar las facturas del sistema de gestión al de contabilidad.

¿Qué estarás tramando, cacho perro?
Los sistemas han nacido de su padre y de su madre con la tecnología de moda en cada momento y con los presupuestos de cada empresa/departamento. Entonces ¿qué le espera al informático del S.XIX? Pues un batiburrillo de interfaces entre los diversos sistemas de cuidado, eso cuando no se mete un sistema a hacer lo que no debe en la BD del otro o te encuentras que cuatro departamentos, porque ellos lo valen, hacen cuatro aplicaciones similares, cada una personalizada para ellos. Al final, las cuatro van una BD central, sacan una serie de datos de la tabla y se los presentan como les interesa ¿consecuencia? La empresa paga a cuatro equipos de desarrolladores, cuatro instancias de BD (de la buena, de la caras, no de esas baratitas) y explota cuatro sistemas (eso si, creo que al menos compartían algunas máquinas) ¿te piensas que es coña? Pues te aseguro que no.

6. No hay nadie imprescindible. Todo el mundo puede ser sustituido.

Eso es una gran verdad. Lo que no se cuenta es el dolor que lleva detrás esa sustitución. Lo que suele haber es un economista que no tiene ni idea de otra que de números. Esa persona es muy cara ... pon otra más barata. Y te cepillas al que llevaba dos años y se conocía el sistema de pe a pá y te resolvía los problemas en dos horas. El/los sustitutos salen más baratos por jornada pero resulta que lo que el anterior hacía en dos días a estos les lleva dos semanas (y a veces más) y no te digo cuando se hace el off-shroring a la India. Esos ingenieros que cambian de empresa cada seis meses ... lo ideal para la estabilidad de un proyecto.

Vamos, si hay que sustituir a alguien, se le sustituye, pero sustituir por vicio, es tontería.

7. Se ha caído ¿cómo es que no hay un sistema de respaldo, una copia, un plan B?

Pues por una sencilla razón: eso es caro. Las empresas serias suelen tener sus sistemas duplicados o al menos con copias. La cosa no es simple ni barata (el precio anterior en HW y licencias, pues multiplicado por dos)  precisamente con lo que me temo que hay muchas empresas y aplicaciones que están ligeramente (por decirlo de manera eufemística) en precario. Y aunque el HW suele ser bastante decentito a veces se cae y luego vienen los lloros. Cierto es que no nos podemos blindar ante todas las circunstancias, pero si se puede hacer una protección bastante razonable, aunque como he dicho, eso es caro pero no veas la tranquilidad que da cuando sientes que tu CPD está seguro.

Responsable de IT cuando confía en el sistema de respaldo.
Eso sí, los sistemas de la empresa funcionando en precario, pero luego el economista presume de la pasta que ha ahorrado en esos derrochadores de IT.

8. Pero si cruzar una base de datos con otra es solo apretar un botón.

No sé quien fue el genio que dijo esto, pero cruzar BD de ayuntamientos (por poner un ejemplo) con las de Hacienda para detectar el fraude puede ser una de las cosas más complicadas que existan (con gran alivio de Bárcenas, Fabra, Ignacio González y otros) Supongo que la cosa habrá mejorado algo, pero claro, cada ayuntamiento (en este caso) ha elegido una tecnología según le han dado entender en cada caso, con un esquema de BD, con una serie de datos, con una serie de relaciones entre los datos que han sido las que necesitaban en cada caso. Ahora alguien puede pensar ¿y no había nadie para poner orden? Pues no y olvídalo, aunque lo hubiera habido, hubiera seguido siendo un caos. El Ayuntamiento de Madrid ya estaba informatizado cuando al Ayuntamiento de Bustelfollado ni siquiera había llegado el teléfono. Por aquella época las posibilidades de haber caído con IBM eran muy altas, ahora vamos a SW libre, BD relacionales cuando no a otras cosas más avanzadas. Casi hay que hacer los interfaces entre ellos uno a uno. Se pueden intentar definir una serie de interfaces estándar, pero en ocasiones, hay información de éstos que no hay de dónde sacarla.

9. Si esto es un decálogo ¿cómo es que no hay 10 puntos?

Bueno, nunca dije que fuera un decálogo. A cambio te pongo esta foto (trucada por si alguien no se ha dado cuenta) que le tiré a la última luna llena.

Pues si, el otro día estuve viendo Los Pitufos.

10. Vale, esto es un desastre ¿se puede mejorar?

Pues por supuesto que se puede mejorar, como casi todas las cosas. No es demasiado complicado .... o sí. Todos los costes que hemos visto en el Ayuntamiento de Busltelfollado son bastante elevados y muy complicados de reducir ... para un sólo ayuntamiento. Si en lugar de utilizar el sistema en exclusiva para un solo sitio lo hacemos para dos, los costes bajan no a la mitad, pero bastante cerca, depende de la complejidad que tenga el otro Ayuntamiento pero gran parte de las cosas que hacen los ayuntamientos son las mismas, con lo que mucho se puede reutilizar. El HW por lo general está ocioso, con lo que con el mismo HW se puede dar servicio a más de un ayuntamiento (quizás si son pequeños hasta tres o cuatro) con lo que el coste de las carísimas licencias se diluye entre varios eso sin contar que no es lo mismo llegar a VMware y comprarle media docena de licencias que pedirle cien al comercial (se te puede hacer pis encima de la emoción)

Pero claro, una vez que los ratones han visto la solución a los problemas surge la otra pregunta ¿quien le pone el cascabel al gato? O lo que es lo mismo ¿quien va a coordinar a diversos ayuntamientos para que compartan infraestructura? Y esto no pasa sólo en las AAPP, pasa también en las grandes empresas, cuando más grandes, más atomizadas y con mayores reinos de taifas.
Alguna foto de ordenadores tenía que poner ¿no?

domingo, 22 de septiembre de 2013

Vamos a diseñar un sistema informático (II)

Ya en la entrada anterior habíamos dejado al Ayuntamiento de Bustelfollado metiéndose en la vorágine de las AAPP 2.0. De mano, ya se han gastado 12.000 € y lo que tienen es ... una relación de cosas que quieren hacer y que no han hecho. Si es que eso de que "yo hago la web en dos patás y con tres duros" no a va a ser verdad.

Ahora ya sabemos (más o menos lo que queremos) vamos a ver cómo lo hacemos y qué productos podemos usar. Lo normal sería una arquitectura en tres niveles con capa de presentación, lógica de negocio y datos. Por supuesto, un ayuntamiento tan importante no puede tener sus servicios caídos con los que necesita una cosa llama Alta Disponibilidad o High Availability o HA (Hache-Á como se dice en círculos tésnicos) para los amigos que ya tenemos confianza con ella.

Los tres niveles de marras según la Wiki.
Total, que una vez decidida en un alarde imaginación e ingeniería vamos a ver qué middleware vamos a utilziar.
- ¿Middlequé?- Tranquilo señor secretario que se lo explico (el alcalde ya hace días que decidió que esto le quedaba grande y delegó en el secretario)
Pues básicamente dónde va a correr el SW. Los datos se almacenan en una base de datos, hay una capa de presentación que pinta las pantallitas y una tercera que procesa los datos. Pero vamos a empezar por la BD. Una de las mejores y más extendidas es el SGBD de Oracle. Lleva un montón de años en el mercado, funciona muy bien, es muy potente (y come HW por un tubo) Aparte de eso dicen las malas lenguas que dentro de su nombre, oculta un mensaje al estilo de los discos de rock satánicos de los 80. A saber que será ese mensaje.
¿Hay un mensaje oculto?


Un pequeño problema que tiene el SGBD de Oracle es que precisamente, lo que se dice tener un precio competitivo .... pues como que no lo tiene. Una licencia para un par de máquinas con una CPU configuradas en cluster cuestan tan solo ... 100.000 € más otros 17.000 € al año concepto de soporte. Por cierto, si virtualizars, hay que pagar eso por cada CPU susceptible de usar Oracle. Un ejemplo que pone una conocida empresa de virtualización es que por una licencia de 2 núcleos corriendo en un entorno virtual de unos 144 núcleos pedía Oracle unos cuatro millones de dólares ¿o eran cinco? Vamos, la cifra es anecdótica pero ojo al virtulizar Oracle salvo que se use su propio virtualizador (OVM)

Hay versiones mucho más baratas como MySQL que con soporte sale por poco más de 1.000 € por servidor. No tiene ciertas cosas como al Enterprise de Oracle que te garantiza la persistencia de los datos hasta en las peores circunstancias, pero dependiendo de para que la queremos puede servir. El problema es que desde la adquisición de SUN Microsystems por parte de Oracle es un producto de Oracle y éstos podrían "cambiar" la política comercial (por el momento no lo han hecho y dicen que no lo van a hacer, pero allá cada cual) Hay un fork de MySQL llamado MaríaDB que puede ser adecuado, pero personalmente yo no metería en ninguna aplicación seria una BD sin soporte (MariaDB lo tiene de pago) dado que un bug en la aplicación (todas tienen bugs y ésta no es una excepción) te puede tirar una aplicación. También podemos irnos a SQLSERVER de Microsoft, que es más barato aunque luego las licencias de los Windows son un dinerillo unos 900 € por servidor (soporte anual aparte) más el CAL (acceso por clientes) Claro que nos podemos olvidar de Microsoft y irnos a Linux para llevar el susto de las suscripciones (algo similar a la licencia) anuales de Red Hat (con soporte) cuestan prácticamente lo mismo que las de Windows 2012 Server (encima por licencia, no se puede usar RedHat si tener el sistema "suscrito" Claro que hay otras opciones como CentOS (es el RH free) o Ubuntu Server. Es recomendable tener algún tipo de soporte que no va a costar los 5.000 € de Windows o RedHat, pero va a costar.

Subiendo hacia la capa de aplicación y yéndonos a los simple, podemos optar por algo OpenSource baratito estilo Glassfish, Tomcat o JBOSS. Hay versiones con soporte pero aquí le vamos a pasar al muerto a la empresa desarrolladora y que sea ella quien se coma el marrón. Y lo mismo vamos a hacer con la capa de presentación 
- ¿y este chollo?  Pregunta el secretario con algo de esperanza.- Que te lo has creído. Al desarrollador le vas a pagar por hacer la aplicación, probarla  soportarla, las modificaciones, ....
Pues resulta que lo encargados de "hacer" la aplicación en realidad hacen diversas cosas (o al menos deberían) como revisar los requisitos, desarrollarlos, implementar la aplicación, probarla, hacer pruebas de prestaciones, probar la seguridad, desplegar la aplicación, evolucionarla, corregir errores, .... (por todo lo que vayamos eligiendo de esta lista, póngase xx € más) Por cierto, cuando el proyecto va de culo se suele recortar por la parte de final o lo que es lo mismo por el despliegue y las pruebas de sistemas. Craso error. El despliegue te lo puede salvar un equipo muy competente y experto (por cierto, eso es caro, por eso no suele haber) pero lo que se escapa de PS .. se lo come el usuario y suele salir mucho más caro de arreglar.

Un desarrollo de una aplicación de la complejidad que estamos abordando (información del Ayuntamiento, pago de impuestos, notificaciones, ...) puede necesitar de 3 a 6 meses para ponerla en condiciones en funcionamiento. Yéndonos al caso más optimista, vamos a suponer que son 3 personas trabajando ello tres meses. a 200 € la jornada ya son 36.000 €. Otra semanita para desplegarla en condiciones son otros 2.000 €. Y vamos a mantenerla y evolucionarla. Métele 100.000 € más al año (siendo muy optimista y con un equipo de desarrollo muy pequeño)

Y todavía no hemos contado el alojamiento de la aplicación. Llevártela a un datacenter en condiciones de operación fetén (no me vale una VM de Amazón, pedimos algo más) te puede salir yendo muy por lo bajo por 2.000 € al año por servidor virtual. A medida que aumentamos el espacio ocupado en storage la cosa sube, al igual que a medida que suben el número de VM necesarias (si el Ayuntamiento se tiene que montar un CPD le sale más caro hasta llegar a cierto volumen).

Al final el secretario del Ayuntamiento ve que la idea del alcalde le sale tranquilamente por 150.00 € al año (si todo sale bien), sin contar con todo el marrón que se tiene que comer el pobre si lo desarrollan desde el ayuntamiento. Al final llega al despacho del alcalde y le dice.

- Alcalde, al final hemos decidido que lo mejor es sacar esto a concurso público para que una empresa nos lleve todo esto. - ¿Un concurso público? ¿sabes el rollo que es esto por poco dinero?- Es que la broma nos va a salir por más de 150.000 € al año .. si tenemos suerte. Posiblemente el doble. si convocamos un concurso que nos incluya todo (licencias, alojamiento, backup, explotación) por unos 200.000 al año seguro que ahorramos.- Pues nada, llama a la gente que vamos a redactar el pliego.
Al final nos encontramos que el Ayuntamiento de Bustelfollado ha convocado un concurso público para informatizar el ayuntamiento por un importe de 500.000 para tres años. La noticia sale en el principal periódico del pueblo el Bustelfollado Herald Tribune que como en su día la hermana del alcalde no se quiso casar con el director del periódico Peter Jey Ramiro titula en su portada:

Escándalo en Bustelfollado. 
El alcalde dilapida un millón en euros en una aplicación que me ha dicho mi cuñado que se hace en dos patás.
Ni que decir tiene que la noticia llega a portada de Menéame dónde sale la opinión del cuñao del piriodista como una verdad absoluta.

(continuara .... )

lunes, 16 de septiembre de 2013

Vamos a diseñar un sistema informático (I)

Estoy viendo muchas veces en prensa noticias con intenciones más bien malévolas acerca de instituciones públicas o otros organismos diciendo que tal o cual organismo se ha gastado xxx miles de euros (o cienes de miles) en una aplicación web y claro, a continuación salen comentarios de todo tipo acerca de derroche, dispendio, que si eso lo hago yo con cuatro duros, que si patatín que si patatán ... vamos, al igual que cada celtíbero tiene un seleccionador de fútbol en su interior tiene un arquitecto software.

La pregunta es ¿vale una aplicación los dineros que ha salido en el concurso o no? ¿está trincando alguien o no? ¿caso no saben lo que validan en concurso? Pues hay una respuesta muy clara: depende.

Y con esto doy por finalizada mi exposición .... ¿qué pasa? ¿por qué me miran así? ¿no les ha quedado claro? Valeeeee, me explico. Agárrense los machos que esto va a ser largo (por eso de lo del I del título)

Lo primero he de decir que llevo más de veinte años haciendo sistemas informáticos. En ese tiempo he visto evolucionar tecnologías, desaparecer, cambiar, nacer y morir sistemas (y otros que no los matas ni a tiros) y me he presentado a algunos concursos públicos y he contestado a docenas de RFP, RFI y RFQ cosas que por cierto, cuestan dinero y que alguien acaba pagando siempre en forma de costes indirectos (si no es este cliente, es el siguiente) y la primera experiencia es que por lo general, suele saber de lo que habla. El presupuesto de dichos trabajos por lo general suele ser "justito" en el mejor de los casos. Otra cosa es que se pueda manipular el proceso de adjudicación o que en la fase de ejecución la empresa elegida se quede sin dinero y se les caiga el boli hasta que les unten más. Cierta afamada consultora con una letra repetida en su nombre es una experta en ello (aparte de ganar los concursos desde "arriba") Otra cosa interesante de los concursos públicos es que son con IVA INCLUIDO o lo que es lo mismo, en un concurso que el importe total sea de 100.000 € al encargado del proyecto le quedan solo 82.644 para ejecutarlo. buen pellizco ¿no?

Pues como no hay nada mejor que un ejemplo para ilustrar las cosas, vamos a intentarlo. Vamos a imaginarnos una localidad de tamaño medio, de nombre Bustelfollado. En esta localidad el alcalde ha decidido que ya hay que entrar en la era de los ayuntamientos 2.0 (como si hubiera llegado a la 1.0) pero como lo suyo no es la informática con buen criterio decide buscar a alguien que entiende y lo primero que hace es consultar al personal del Ayuntamiento. Por desgracia la rotación en el Ayuntamiento no es muy elevada y el último funcionario accedió a la plaza en 1995 antes de que explotara una cosa llamada la burbuja puntocom y no están muy al día en el tema. Cierto que el Principado de Asturias les ha puesto una serie de ordenadores y algunas aplicaciones que son útiles para ver las parcelas de la gente pero aparte de utilizar cuatro cosas y darle a Ctrl-Alt-Del ocho veces al día de media, la gente no es muy experta. A lo mejor es que los sistemas son un poco antiguos, pero como ya se han acostumbrado al Windows 98 SE los funcionarios no quieren cambiar nada.

¿Os pensabais que me lo había inventado? Pues no. Fuente: Propia.

Tras consultar al personal del Ayuntamiento resulta que el hijo del Ernesto que es un juaker de esos, que  tiene tuinter, feisbú, guasap y lee el periódico en una tele pequeña que resulta que le ha costado tanto como una tele de 42" pulgadas del Media Markt ... hay que ser tonto para comprar eso. Este les habla de algo llamado Open Source, bases de datos, Web 2.0, SSL, Apache, Tomcat ..... total que el alcalde y el secretario salen de hablar con el chaval con una cosa muy clara: ¡qué bonito debe ser eso de hablar idioma y en qué leches estaba hablando el gachó!

Por suerte para el alcalde de Bustelfollado andaba por ahí cerca el marido de la Maru, uno con cara de tonto que dicen que es informático pero que trabaja en una empresa que todo el mundo asocia con otra cosa. Como se aburre por el pueblo se dedica a arreglar grifos, cables o lo que sea con tal de pasar el rato. Y por suerte para el alcalde, tiene una amplia experiencia con altos directivos que curiosamente algunas veces recuerdan a nuestro despistado alcalde. Al final se ponen a hablar con él y ya la primera pregunta que les hace les desconcierta. Menudo resabidillo.
- ¿Qué quieren ustedes hacer con su aplicación?- ¿Cómo que qué queremos hacer? ¡habráse visto semejante morro! ¡que nos lo diga él que es el que sabe!
 Aunque claro, el secretario del ayuntamiento que lleva allí 30 años y ya ha sobrevivido a varios alcaldes empieza a pensar que casi igual tiene razón.
- Alcalde, mira que cuando hacemos un edificio antes pensamos para qué lo queremos ... aunque luego no lo usemos. Recuerda que cuando hicimos el polideportivo era para que los chavales jugaran al baloncesto dentro si llovía (el hecho de que el chaval más joven tenga 38 años es anecdótico) y cuando hicimos el mercado de ganado era pensando en hacer ferias de ganado. Vale que ya todo el ganado se compra y vende en mercados más grandes a 100 kms de aquí, pero tenemos mercado de ganado.
- Pues va a tener razón el jodío este.
- Por ejemplo, podemos utilizar la página para informar de cosas del ayuntamiento, para que los vecinos no tengan que venir a enterarse a la puerta del ayuntamiento. Además Ricardo el pregonero anda jodido del asma y cualquier día se nos muere de tanto soplar la trompetilla.
- Pues no es mala idea.
- Y les podemos informar de cuando se paga el IBI, los vados, el impuesto de circulación, la basura que todos estos se hacen los locos, como que no se enteran.
- También está bien la cosa.
- Y de paso, que se puedan pagar recibos por ahí, que el de la Caja Rural se jubila el año que viene y no creo que pongan otro y la gente tendría que hacerse 40 kms para pagar un recibo.
- Pues me gusta esto del ayuntamiento 2.0 .... además me podrían cambiar el solitario ese del ordenador, que ya me lo sé de memoria. A ver si me ponen un juego de Tute o algo más moderno
- Alcalde creo que no es para eso ....
- Oye (al informático) ¿y si empiezas a trabajar y te vamos diciendo?- ¿y que les parece si me empiezan a pagar lo que les diga y ya voy haciendo? ¿no? Pues yo igual. no ya es perro viejo para que le cuelen eso (AVISO A NEOFITOS: ni se os ocurra aceptar esa modalidad de contrato nunca)
 Pues con esta sencilla conversación se inicia el primer paso de una especificación de requisitos (no requerimientos) de una aplicación. De la capacidad de los ingenieros de requisitos, de la capacidad del cliente para expresar sus deseos y del grado de detalle suele depender bastante el éxito del proyecto (aunque los proyectos por lo general suelen pegar bastantes giros)

Aquí tenemos el primer gasto del proyecto: un equipo bueno de requisitos es caro aunque para el Ayuntamiento de Bustelfollado se lo vamos a dejar baratito: un equipo de dos personas trabajando un mes (toma y redacción de requisitos) son 40 jornadas, a 300 € jornada salen 12.000 € y no hemos tirado una línea de código.

A lo mejor esto puede parecer caro sobre todo si sabemos lo que cobra un informático últimamente pero una jornada de una consultora estrella estilo HP, Accenture, IBM o Indra sale por bastante más caro. Para abaratar sus precios globales suelen recurrir a empresas filiales con un status inferior (sobre todo en sueldo y condiciones laborales) como Coritel o subcontratas a las que se exprime en lo posible (o más) que suelen ser las que hacen el trabajo sucio (a todos los niveles)

Ya tenemos los requisitos establecidos y en un alarde de ingenuidad digno de un recién salido de la Facultad de Económicas (el de Informática ya sale medio resabiao) adorador de Milton Friedman nos creemos que los requisitos son correctos y vamos a diseñar la arquitectura del sistema. Esto es como cuando te vas a comprar un Mercedes. La cantidad de opciones es tan amplia que te puedes hacer un sistema desde una cantidad realmente moderada a gastarte millones de euros. Por ejemplo, sin entrar en la arquitectura software del sistema (eso lo voy a dejar para la siguiente entrada) vamos a echar una risas.
- Alcalde ¿dónde va a correr la aplicación?- ¿cómo que dónde? En la Internete esa ¿no?- Noooo ¿qué dónde van a estar los servidores?- ¿Los servicios? joder, dónde siempre, al final del pasillo a la izquierda. Ten cuidado con la cisterna que si no tiras recto se engancha y queda echando agua ....- Que no, que los ordenadores, que dónde los vamos a poner.- ¡ah! leches que raro habla esta gente. Pues en el ayuntamiento.- Tenemos un problema de infraestructura. Aquí no hay CPD y para todo lo que necesita hay que colocar unas cuantas máquinas.
¿A qué nos referimos? Pues a una condiciones adecuadas para instalar unos cuantos servidores que no son PC de Media Markt para meter unos datos y que no es demasiado grave que se caigan. Si estos servidores se caen, se va todo a tomar por el saco. Vamos pedir una serie de cosas al señor alcalde:
- Sistema de alimentación ininterrumpida. Lo ideal sería una doble acometida eléctrica pero en España dónde las eléctricas campas a sus anchas es prácticamente imposible. Entonces los servidores deben estar alimentados por un sistema de baterías conectado a un generador que se arranque de manera automática en caso de problema eléctrico. Un sistema similar de baterías con un generador de 50 kVA puede salir por unos 10-15.000 € fácilmente instalado.
- Extinción de incendios que no estropee las máquinas. Otros 4-5.000 € (me lo he inventado, no se por cuanto puede salir)
- Sistema de climatización. Por suerte Bustelfollado no está situado en una zona demasiado cálida con lo que no hace falta un equipo demasiado potente. Se puede aprovechar el aire frío del exterior la mayor parte del año con lo que con unos equipos de 4.000 € alcanza.
- Red eléctrica: aumentar la potencia, instalación de acometidas, cuadros, .... Otros 5.000 €
- Comunicaciones. Una red Macrolan (nada de red de backup) de 10 Mbps simétricos ... unos 4.000 € al mes.

Vamos que de mano aflojamos 25.000 € más las comunicaciones.
- Esto ... ¿y no hay otra alternativa más barata?
Hombre, se puede instalar en precario solo con la corriente y si se caen en verano o se quema algo se jode todo .... (pues aunque no lo parezca, esto se hace mucho más de lo que se piensa) o llevarlo a un datacenter que nos cobren por alojarlo.
- ¿Y cuanto nos cobra ese chisme por alojarlo?
Si es mas económico que hacer una inversión de este estilo pero claro necesitamos saber que les vamos a llevar.
- Pues un chisme bueno, claro. 
Pues mira, hay una cosa maja. Un chasis de c7000 de HP que puede alojar hasta 16 servidores. Es uno de los más usados. A ésto se le puede añadir una cabina de discos HP de gama media que va muy bien y tendríamos capacidad actual y de crecimiento.
- Eso me gusta ¿y cuanto vale eso? ¿5.000? ¿6.000 €?- Pues el chasis vacío como unos 30.000 €, cada servidor 6-8.000 dependiendo de la configuración, la cabina de discos varía un poco pero empezando en 60.000 podemos apañar .... señor alcalde ¿se encuentra bien? Se está poniendo de un color muy raro .... señor alcalde responda ......
Captamos la indirecta de que el presupuesto no le convence al alcalde con lo que descartamos a HP y con disimulo ocultamos el presupuesto de IBM que habíamos pedido con la sibilina intención de mostrarle que HP no eran tan caro. Descartamos el alojamiento en máquinas físicas y mejor pensamos en algo en virtual. Al fin y al cabo, el hecho de alojar algo en un DC no estan chollo. Te clavan en torno a 1.000 al mes sin hacer nada y te cobran la corriente que te puede salir por más de 1.500 € al año por KW y esos dos chisme pueden llegar a consumir 14 KW aunque seguramente el consumo real no pase de 7 serían unos 10-11.000 € solo de corriente.

Vámonos a la nube que encima está de moda (pero eso será en la próxima entrada)

sábado, 10 de agosto de 2013

Dosis homeopáticas

El otro día estábamos hablando de homeopatía y como siempre yo me muestro escéptico. Ya he hablado al respecto en un par de entradas aquí y aquí con lo que creo que  mi postura está mas o menos clara.

Esta vez no me voy a liar con números de Avogrado, moléculas ni nada parecido. Voy a ir a algo más simple.

Composición de un medicamento homeopático. Fuente: propia.
En la imagen vemos un frasquito de un medicamento homeopático según ellos a base de Telurio. Supongo que no el que consume esto no sabe que el 65% del Telurio es radiactivo (es radiación Beta o lo que es lo mismo, emite electrones o positrones)  pero habida cuenta de la posibilidad de que te toque una parte de Telurio es como más bien escasa por no decir nula. Aparte de eso es ligeramente tóxico. También llama la atención de que el botecito de marras no ponga la cantidad exacta de gránulos .... leñe, que solo hay que contarlos y se supone que son una industria seria.

La cuestión es que si te pones a mirar una pastilla de paracetamol 650 podemos ver que hay unos 650 miligramos de paracetamol en una píldora que debe pesar en torno al gramo (puede ser más o menos, tampoco es que sea muy relevante) con lo que vemos que de la mitad del medicamento que ingerimos es un principio activo. Si leemos la etiqueta del medicamento homeopático, por cada gramo de producto hay 0,85 gramos de sacarosa y 0,15 gramos de lactosa. Parece que no queda mucho para el producto en sí, aunque claro, cuando algo se diluye 2000 veces  como que no debe quedar mucho ¿verdad? Cualquiera que no crea en la homeopatía podría pensar que lo que está tomando es azúcar con leche y lo cierto es que razón no le falta.

Para que algo haga efecto o no depende de la dosis. Cosas como el arsénico (que mata) son inocuas por debajo de cierto límite. Y cuando no hay dosis, ni efecto ni leches,

viernes, 9 de agosto de 2013

Disparando un cañón de las guerras napoleónicas (II)

En la entrada previa habíamos visto cómo se hacía el primer disparo de un cañón y dado que continúo con el rollo seguro que algún sagaz lector se habrá dado cuenta de que hay ciertas cosillas que hacer antes de volver a disparar de nuevo. A diferencia de en las películas, lo de pegar cañonazos es una cosa muy seria y por lo general, el artillero quiere sobrevivir al disparo. Antes de contar lo que hay que hacer vamos a echar un ojo al siguiente dibujo:
Diversos instrumentos de artillería.
Lo primero que vemos, con el numero 5 es un palo largo con dos cabezas. La parte de la izquierda es el atacador o rammer en inglés. Sirve para llevar los diversos elementos del disparo hasta el final de la recámara. Los atacadores se siguen utilizando en cañones modernos de retrocarga cuando por ejemplo, la carga de proyección y el proyectil no van unidos. Aunque los hay manuales suelen ser hidraúlicos. La parte de la derecha es la que nos interesa ahora. En inglés se llama la esponja aunque solía ser de lana de cordero o otros materiales similares. Quizás por eso en español se llama lanada Su utilidad, la veremos luego. El número 6 es otra lanada.
Debajo vemos con el número 7 otro artilugio con dos utilidades, aunque al igual que el anterior, podían ser dos. La parte izquierda se utiliza para medir la dosis de pólvora en caso de disponer de cartuchos preparados. Se metía hasta el fondo de la recámara, se le daba la vuelta y se vertía la carga. El lado derecho, aunque lo parezca, no se usaba para descorchar las botellas de sidra antes de la batalla. En inglés se llama worm (gusano) pero en castellano debe ser algo como sacabalas. Aparte del uso que comentaré más adelante también se usaba para descargar el arma si ya no se iba a disparar (con dos cojones)
En el número 8 se ven dos ejemplares de botafuego o lo que es lo mismo, un palo con una mecha lenta que se usa para darle candela a la pólvora. Para finalizar, vemos los punzones utilizados para perforar los cartuchos de pólvora (cuando se usan) a través del oído del arma.

Bueno, como decíamos antes, hemos dejado un cañón recién disparado y nos preparamos a largarle al prójimo que tenemos enfrente con una bayoneta dispuesta a guardarla en nuestras tripas una nueva descarga para sugerirle que igual atacar directamente una batería de artillería no es la mejor idea ¿cual es el siguiente paso? Previamente habíamos visto que lo primero que hacíamos era introducir una carga de proyección, pero claro, la pólvora negra tiene algunas propiedades curiosas como que su velocidad de deflagración no es muy alta. Eso permite cargar el cañón sin peligro de que reviente pero dentro del ánima pueden quedar pavesas ardiendo que podrían prender la nueva carga enviando al atacador junto con el artillero que lo maneja a tierra de nadie. Para evitar esto, con la lanada se debe limpiar muy bien el ánima, dejándola libre de pavesas y otras porquerías ardientes.

Voy a hacer aquí un inciso para comentar una cosa sobre el material de los cañones. Lo normal era que se hicieran de dos materiales: hierro o bronce. El hierro era más barato y se utilizaba sobre todo y curiosamente, en las piezas navales, mucho más pesadas. El bronce era más caro pero a cambio era más ligero y flexible. La utilidad de la ligereza se ve claramente al tener que mover las piezas por tierra pero la flexibilidad era una ventaja a la hora de disparar muchas veces sin que el arma se recalentara y explotara (la vida útil de un cañón eran unos 2-3.000 disparos) Los cañones navales españoles tenía una ventaja: avisaban mediante grietas antes de reventar. Pues dado que los cañones calentaban, de vez en cuando, hacia falta enfriarlos y el sistema era mojando la esponja y refrescando el ánima cada cierto número de disparos (depende del clima, la cadencia, ....) Para ello en la dotación de la pieza se incluían varios cubos.

Una vez limpia el ánima, se introducía el sacabalas y se extraía la parte inferior del saco que contenía la carga de proyección dado que no se había consumido y el arma ya está dispuesta para comenzar de nuevo la tarea de carga. Por supuesto, dado que no existe ningún mecanismo que amortigüe el retroceso del arma es preciso volver a poner el arma en posición y apuntar de nuevo. Todas estas tareas llevan su tiempo, con lo que el tiempo necesario entre dos disparos puede variar, según el calibre y el estado de los artilleros de uno a tres minutos fácilmente. Supongo que el cargar los cañones navales, mucho más grandes y pesados y en posiciones más angostas debía ser incluso más complicado, aunque seguramente las tripulaciones tuvieran un entrenamiento más exhaustivo por las cuenta que les tenía (vale, menos los españoles en Trafalgar con artilleros recién reclutados) Al parecer en un día "animado" un cañón podía disparar hasta 200 veces en un día lo que sale a unos 20 disparos la hora o lo que es lo mismo, uno cada tres minutos.

En otra entrada mencionaba la carga de la Brigada Ligera en Balaclava. La última andanada de los rusos se produjo sin limpiar los cañones, una situación muy peligrosa pero en este caso, se consideraba menos peligroso no limpiar el cañón que encontrarse con 600 animales a la carrera montados en otros tantos caballos con intenciones harto aviesas aunque equivocadas (el objetivo de la carga no debían ser los cañones de final del valle, si no los cañones turcos que habían capturado los rusos y se estaban llevando como trofeo en la derecha del valle)

jueves, 8 de agosto de 2013

Disparando un cañón de las guerras napoleónicas (I)

En el apartado anterior había hablado un poco de lo complicado que era mover un ejército en épocas pasadas, en especial la artillería. No es que hoy sea fácil sino todo lo contrario, pero por lo menos, hay máquinas y vehículos para ayudar, en lugar hacerlo casi todo por medio de la fuerza bruta (humana o animal) Lo cierto es que la mecanización no es tan reciente como pensamos. Ya en la Segunda Guerra Mundial se utilizaron cientos de miles de caballos para el transporte de tropas y materiales. Tan sólo los USA estaban completamente mecanizados aunque no movieron tanto gente como por ejemplo, alemanes o soviéticos.

En el apartado de hoy voy a intentar contar un poco lo que era el trabajo del artillero. Por algún motivo se necesitaba que los artilleros fueran personas fuertes. Los que voy a contar aplica principalmente a la artillería terrestre, pero es similar en la naval. Una excelente referencia de cómo funciona la artillería naval se puede encontrar en los libros de Patrick O'Brien.
Pieza naval capturada a un navío de la Pérfida Albión. Fuente: propia.


Pues el trabajo de los artilleros comienza transportando los cañones. Ya vimos que no era un trabajo trivial ya que un cañón podía llevar media docena de caballos y una docena de personas. Una vez decidido el emplazamiento de los mismo, se procede a desenganchar tanto el cañón como las municiones. Si hay suerte, el cañón se puede poner en posición, sino, hay que preparar la posición para el cañón y dado que la excavadora y el bulldozer no se habían inventado no quedaba más remedio que utilizar pico y pala. Si tenías suerte y elegías el lugar dónde combatir, te daba tiempo a proteger tu posición con trincheras, parapetos y otras construcciones de carácter defensivo. Si no te daba tiempo, pues nada, a pecho descubierto o como se pueda.

Una vez emplazados los cañones, se retira el carro con las municiones unos 20 pasos. Los cañones se separan unos metros unos de otros, para evitar que el fuego enemigo afecte a más de una pieza a la vez. Y a la espera de que empiece la batalla.

La munición a emplear puede ser de diversos tipos, aunque en el ejército,a  diferencia de la marina que tiene proyectiles más especializados, dispone de tres tipos de munición principalmente (no voy a meter los howitzer y morteros, me voy a quedar sólo con los cañones)
  • Bola de hierro. Es el proyectil que suele salir en las películas. Una bola de hierro capaz de llevarse por delante hombres, caballos, fortificaciones, etc. Disparado en diagonal contra una formación de infantería a la distancia correcta puede llevarse por delante a bastante gente. Es el proyectil con más alcance y más preciso (es útil hasta algo más de 1.000 metros, aunque en realidad puede llegar bastante más lejos)
  • Latas (o bolsas) de metralla (Cannister Shot). Pues se trata de eso, unos recipientes repletos de proyectiles de mosquete o similares que se expanden al salir del cañón con un efecto similar a los perdigones de una escopeta. Terroríficos contra la infantería, pero con un alcance aproximadamente la mitad que el anterior.
  • Racimos de proyectiles (grape-shot) similar al anterior, pero de mayor calibre y con un poco más de alcance. Se montaban en una estructura que recordaba un racimo de uvas.
También existen granadas para asedio, pero en esta caso, me centro en la artillería de campaña. La idea era utilizar los cañones con uso equivalente al que hoy en día tendrían las ametralladoras: barrer el campo de batalla para evitar el avance de la infantería o caballería. No conviene olvidar que por aquel entonces la infantería avanzaba en masas compactas intentando llegar al enfrentamiento a la bayoneta. Como el alcance útil de un mosquete eran menos de 100 metros, con lo que la artillería les batía desde al menos 10 veces esa distancia. Por fortuna para los infantes, la cadencia de fuego de la artillería y su precisión dejaban bastante que desear pero una serie de cañones bien colocados podía hacer mucho daño y frenar el avance de las tropas. Esta forma de combatir se mantuvo hasta la llegada de la ametralladora en la Primera Guerra Mundial, pese a la mejora de los fusiles que podían alcanzar fácilmente un blanco a más de 500 metros. Un campo de batalla cubierto por unas pocas ametralladoras con suficiente munición era un infierno.

Volviendo a las Guerras Napoleónicas, pues no encontramos a una formación de infantería avanzando todos elegantes, perfectamente alineados, con esos uniformes de "camuflaje" de color azul o rojo hacia nuestra batería. El jefe de la batería ordena cargar con balas de hierro dado que es lo más eficaz a distancia. Los artilleros corren hacia las municiones y traen la carga y el proyectil, dependiendo de lo que haya disponible, la cosa puede variar:
  • La carga de proyección: es un saquito de pólvora negra previamente pesado para asegurarse de que todos los tiros vayan al mismo sitio.
  • El taco: para interponerse entre la pólvora y el proyectil.
  • El proyectil. En este caso, una bola de hierro de un calibre inferior al del ánima.
Si la cosa va bien, la carga, el proyectil y el taco vienen sujetos por unas abrazaderas de latón lo que facilita la carga del proyectil y la velocidad de disparo, si la cosa no va tan bien, vienen por separado, y si la cosa está fatal, hay que medir la pólvora con una especie de cucharón y se vierte al final del cañón. El proceso es siempre el mismo, se introduce el componente por la boca y se ataca (empuja) hasta el final con el atacador (rammer) que es similar a una baqueta talla XXXL. Si el disparo está previamente preparado, la operación se hace una vez, si vienen suelto, se mete la carga de proyección y se empuja hasta el final, luego la estopa y se vuelve a atacar, luego el proyectil y por último, un nuevo taco. Ni que decir tiene que la cadencia de fuego con los disparos preparados previamente es mayor que si lo hacemos por partes. Tras ello, se introduce un punzón por el oído del arma para perforar la carga de proyección y se rellena de pólvora más fina que será la encargada de cebar la carga principal. Esta última carga era muy sensible a la lluvia o al viento. Por ejemplo, en los libros de Patrick O'Brien se describe que el artillero debe taparlo con la mano para evitar que se vuele.

En la imagen inferior, proveniente de la wikipedia aparecen numerados los siguientes componentes de un disparo:
  1. Cebo de la carga
  2. Carga de proyección
  3. Estopa (haciendo labor de taco)
  4. Proyectil (una bola de hierro en este caso)
  5. Estopa (sellando el proyectil para evitar que se pierdan los gases)
Corte un cañón cargado. Fuente: wikipedia
Una vez cargado el arma toca apuntar. Como siempre las armas se apuntan en una dirección determinada (azimut) y para cierto alcance (elevación) El alcance depende de la inclinación del cañón, a más inclinación hasta cierto ángulo, pues mayo alcance. Eso se hace variando la inclinación del tubo, bien por medio de una cuña o como por ejemplo, en la foto inferior, por medio de un tornillo. Por medio de una escuadra y una plomada era posible estimar el alcance. La dirección de tiro era más sencilla de ajustar: a base de músculo y de una serie de palancas se movía la pieza a izquierda y derecha.
Tornillo de reglaje del alcance. Fuente: propia
Una vez todo listo, solo quedaba aplicar un fuego a la carga de cebo para producir el disparo.Esto se podía hacer de diversas maneras aunque lo más común debía ser aplicar una mecha aunque otros cañones disponían de mecanismos de disparo al estilo de las pistolas.

Una vez producido el disparo ¿los siguientes son iguales? Pues no del todo, pero eso lo veremos el próximo día.

domingo, 16 de junio de 2013

Artillería napoleónica


El otro día estaba discutiendo hablando con un amigo que acaba de sacar un libro sobre los partes de Guerra de Wellington (ISBN 978-84-96186-86-9) en España, un subconjunto de todos los escritos por el británico a lo largo de su vida y que afecta a la guerra Peninsular, concretamente, a la zona de Salamanca, Castilla, ... . Previamente había sacado un libro de lectura un poco menos densa del que ya he hablado previamente. La cuestión es que yo le sugería para la tercera entrega escribir algo de cómo se hacían las cosas en la época. El tema de movilizar 40, 50.000 o más soldados no era una tarea sencilla y exigía un esfuerzo organizador más que considerable. De hecho, muchas veces, la guerra no la ganaba el mejor general sino el que mejor se organizaba. El llegar a la batalla con las más tropas, más descansadas, mejor equipadas y en el momento justo no es moco de pavo. Puede llamar la atención de Wellington haya puesto sitio a los franceses en Burgos y haya tenido que retirarse por no haber llevado artillería .... ¿cómo es eso posible? Pues voy a ver si explico algo lo que es la artillería a finales del s.XVII y principios del s.XIX.

Hoy en día los términos artillería de campaña, artillería de sitio, obuses, cañones, .... pierden un poco de sentido. Hoy en día los cañones son muy versátiles, pudiendo actuar en muchos roles. Además, el alcance se ha multiplicado por 10 (al menos) Un cañón moderno del 105 como el L118 puede actuar como cañón (tiro por debajo de 45º) como howitzer (por encima de 45º) ser remolcado, puesto en posición fija, disparar a más de 15 km y tirar una gran variedad de proyectiles. Pero esto hace 200 años, no era así ni mucho menos.

Hace 200 años, como ahora, los cañones más poderosos se montaban como siempre en los barcos aprovechando la movilidad de estos. Por motivos de distribución de pesos, los más pesados se ponían en los puentes inferiores, aligerando el calibre según se iba subiendo en el barco. En la cubierta más inferior se montaban las piezas de 36 o 24 libras que podían lanzar proyectiles de unos 14 o 12 kilos. A medida que se subían a las cubiertas superiores el calibre iba disminuyendo. Por ejemplo, el Santísima Trinidad montaba cañones de 36, 24, 12 y 8 libras. Desde una perspectiva moderna estos valores dicen poco, pero si decimos que un cañón de 36 libras puede llegar a pesar casi cuatro toneladas podemos pensar que el moverlo en tierra era ligeramente "complejo". Si nos ponemos en el periodo entre la toma de Badajoz y la Batalla de Salamanca (aquí conocida por los Arapiles) en que los ejércitos Anglo-Portugués-Español y Francés marcharon en paralelo a escasa distancia el andar arrastrando un cañón de 36 libras no debía ser lo más cómodo y eso que estamos hablando de las llanuras de Castilla. Debido a esto, vamos a ver la clasificación de la artillería.

Artillería de sitio y de guarnición.

Con la excepción de la naval, es la que dispone de mayores calibres, desde las 4 a las 24 libras o incluso mayores. Comprende cañones, morteros, obuses, .... Los morteros pueden llegar a las 15 pulgadas de calibre (estos me miden por el tamaño de la boca en lugar de por el peso del proyectil) No estñan pensados por lo general para ser móviles por lo que pueden tener cureñas como las de la foto de abajo que es un cañón naval, pero puede ser utilizado para guardar el puerto, si es preciso.

Cañón de 9 libras inglés capturado en Donosti. Fuente: propia
Aunque los cañones sean grande y pesados siempre se les puede mover con la ayuda de grúas y similares siempre que se cuenta con la ayuda de unos fuertes brazos y tiempo suficiente.

Artillería de campaña

Es la que se lleva a la batalla. Cuando leemos sobre las batallas de la época napoleónica es a la que se suelen referir aunque en esto hay excepciones. Si por ejemplo, un ejército se acerca a una ciudad controlada por el otro, es posible que pueda tirar de la artillería de plaza.

En el ejército francés la artillería de campaña era de 4, 8 y 12 libras tan solo en comparación con la mayor variedad de calibres de la artillería anterior ¿cual es el motivo? Pues por un lado, el simplificar un poco la cadena logística, no es lo mismo llevar municiones para tres calibres que para 8 y por otro lado, el peso. Un cañón de 24 libres pesa casi tres toneladas contando su afuste y solo el tubo mide  2,5 metros. El cañón de 12 libras pesa sólo 900 kg .... ¡ande vamos a parar! Aún así, para mover el bisho en cuestión eran necesaria media docena de caballos y 15 personas para servir la pieza. A todo eso, sumemos los carros para las municiones, equipos, .....   Por ejemplo, un cuerpo de artillería que acompañara a un ejército que constara de 200 cañones precisaría 440 carros y ¡2.840 caballos! y unos 2.000 hombres sólo para la artillería.

Artillería montada.

Artillería a caballo. fuente Wikipedia
Se trata de unidades hipomóviles diseñadas para llevar la artillería a dónde era necesaria en el curso de batalla. Las piezas excesivamente pesadas como las 24, 12 u 8 libras están directamente descartadas. Los normal era utilizar piezas de 6 libras ya que las de 4 eran demasiado ligeras (hablando de poder de fuego) Pensemos que la idea era batir una fortificación inesperada o rociar de metralla un cuadro de infantería
Cuadro de infatería. Fuente: wikipedia
para sugerirles que quizás emprender la huida fuera mejor idea. El cañón de 6 libras era una solución intermedia y bastante adecuada sobre todo teniendo en cuenta a las distancias en que se combatía en la época. Teniendo en cuenta que los mosquetes de la época eran muy imprecisos por encima de los 100 metros (ojo, que también había rifles, bastante más precisos) poder situar un cañón al triple de esa distancia y rociar a los infantes con metralla con suma eficacia era lo que deseaban todos los comandantes (vamos, lo que llevaban los cañones, porque a los de enfrente maldita la gracia que las haría) Gracias a estas unidades, el poder de fuego artillero se podía llevar al lugar que se necesitaba en un tiempo moderado y retirarlo fácilmente si las cosas se ponían feas, cosa que no sucedía con las piezas más pesadas. De hecho, la toma de cañones se consideraba como una victoria, por ejemplo, la famosa carga de la brigada ligera en Crimea, aparte de la cagada de "solo veo unos cañones" iba destinada a evitar que los rusos retiraran los cañones de las posiciones turcas claro que por un malentendido acabaron cargando contra los cañones rusos. Al final, ni pa tí ni pa mí (rusos y anglo franceses se adjudican la victoria), pero se en la tontería, se quedaron más de 400 muertos y 900 heridos en el campo entre unos y otro.

De esto podemos concluir que el ejercicio logístico de mover un ejército de la época napoleónica era una empresa arduo complicada. De hecho, desde los tiempos de Roma y de Anibal y con muy pocas excepciones, el tamaño de los ejércitos en campaña era de pocos miles, especialmente, lejos de sus bases. Tampoco se podía desplazar a todo el ejército el mismo día por la misma ruta, sencillamente, ni cabían, ni había forma de darles de comer. Por ejemplo, en el libro de Wellington que menciono antes se describe el movimiento de una división francesa entre Ciudad Rodrigo y Alcántara y se desplazan de brigada en brigada, una cada día. Además, las cosas que han de planear con tiempo habida cuenta del retraso de las comunicaciones (desde varias horas a varios días, dependiendo de la distancia)

Al final, resulta que lo que sale en las películas no se parece en mucho a la realidad, al menos, en las cosas mas mundanas.

domingo, 9 de junio de 2013

Necesitamos nombre para una nueva ¿ciencia?

Estaba últimamente dándole vueltas a ciertas similitudes que hay entre la astronomía y la economía y estoy pensando que recientemente (bueno, no tan recién) ha nacido una nueva disciplina a la que debemos de poner nombre, porque se podría confundir con otra disciplina ya existente.

¿Por qué hago una comparación con la economía y la astronomía? Pues la cosa es relativamente simple. Hace unos miles de años, en Grecia, en una cálida noche de verano, como diría Sheldon Cooper, el hombre miró al cielo y observó que, entre varios miles de estrellas, había varias que no se comportaban como el resto (la luna, según Sagan ya la tenía controlada Moonwatcher bastante antes de saber manejar el hueso para recuperar el charco) Esa gente se dio cuenta de que unos puntos que brillaban en el cielo se movían .... uno antes o después de la salida o la puesta de Sol, otro de color rojo, otro muy brillante, .... 
Moonwatcher iniciando sus estudios astronómicos en 2001 (Kubrik/Sagán)

Como el hombre es muy dado a averiguar cómo funcionan las cosas (y si no, se lo inventan en una cosas llamadas religiones) alguien empezó a medir el comportamiento de esos cuerpos errantes (que en griego se dice πλανήτης y que se pronuncia algo así como planetas) De paso, también ocurría que la Luna hacía cosas raras de vez en cuando. Resulta que a veces, desaparecía y volvía a aparecer. Lo mismo ocurría con el Sol, pero con una frecuencia mucho mayor. Gente muy observadora y muy lista fue poco a poco capaz de predecir los movimientos de los astros y claro, si eres capaz de predecir el movimiento de los astros ... ¿cómo no vas a ser capaz de predecir el resto de cosas? Lógico, normal. Si la Luna Nueva entra en conjunción con Júpiter ese va a ser año de malas cosechas ... seguro (incluso, a lo mejor resultó que un año de malas cosechas coincidiera con una conjunción astral determinada) pero vamos, que la influencia de Júpiter en cualquier cosa relacionada con la Tierra .... salvo en parar cometas y cuerpos provenientes de fuera del Sistema Solar, como que no influye mucho. 

Aunque en su época, la observación y la predicción (de los cuerpos celestes y del futuro vario) iban de la mano aunque poco a poco se fueron separando. Gente como Galileo, Newton, Cassini y tantos otros sentaron las bases de una ciencia seria, basada en hechos contrastados y repetidos y cuyas teorías se elaboraban con una base científica y que eran confirmadas en base a observaciones. Por ejemplo, el planeta Neptuno fue localizado en base a unos extraños comportamientos de Urano. Sin embargo, unos extraños movimientos de Mercurio se suponía que eran provocados por un planeta interior llamado Vulcano. Dicho planeta nunca apareció y el movimiento anómalo de Mercurio acabó siendo explicado por la deformación del Espacio-Tiempo provocado por el efecto gravitatorio del Sol.

Al final parece que los astrónomos son gente seria, metódica, que se piensan las cosas razonablemente bien, as diferencia de sus primos, los astrólogos que son todo lo contrario aunque también se basan en las estrellas y en cosas peores. Sus cálculos no son precisos ni actuales, de hecho, siguen con el Zodiaco de hace 3.000 años, aunque no coincida. Claro que no influye mucho en lo que aciertan o no.

Pues con la economía pasa algo parecido. La economía nace como la necesidad de saber lo que tienes, lo que haces, lo que produces y lo que gastas. La cosa proviene de muy antiguo. Ya en el Paleolítico el hombre sintió la necesidad de contar y hacer operaciones matemáticas.
Hueso de Ishango. Fuente: Wikipedia

El hueso que aparece a la izquierda es de los primeros registros que se tienen de un sistema de conteo y/o matemático. En una época en que la primera ocupación era conseguir comida y no ser comido por otro bicho más gordo, si un homínido se entretuvo en hacer marcas en un hueso, era porque le era útil (un calendario, por ejemplo) y no por gusto. Al igual que los astrónomos, las matemática y la economía van creciendo de la mano. Ya en Egipto hace falta un sistema de contabilidad complejo para la recaudación de impuestos. Las campañas militares exigen un complejo sistema logístico en el que los números son importantes. Por ejemplo dice el Faraón: trae unas cabras para comer mañana .... ¿cuantas cabras traemos? ¿cuantos son a comer? ¿y si traemos hipopótamos? ¿a cuantas cabras equivale un hipopótamo? ¿hay hipopótamos de ración?

Pues a base de observar, los escribas del faraón llegaban a conclusiones y previsiones lógicas: si el ejército come tres hipopótamos al día y sólo tenemos treinta .... sólo podemos hacer diez días de campaña y si nos pasamos, pasaremos hambre (las cabras tienen menos chicha que el hipopótamo)

Ya por aquella época había gente que aparte de hipopótamos tenía oro y lo prestaba y también guardaba oro de otro a cambio de un interés y lo solían hacer con bastante seriedad porque entre otras cosas, si lo hacía mal, podía acabar clavado en un palo en medio del desierto y no es precisamente una forma agradable de hacer turismo por las dunas. Vamos, que la gente se tomaba la economía en serio. Siempre hubo desfalcos y robos, pero en lugar de que el visir anticorrupción pudiera la absolución, como mínimo salían con las costillas calientes y es posible que con algún miembro de menos eso si no acababan como pienso macrobióticos de algún cocodrilo.
Funcionario de la hacienda egipcia sancionando a un infractor.

Total, que va pasando el tiempo, y la ciencia economía poco a poco va mejorando, contemplando más cosas, ... Cierto que durante la antigüedad hubo hambrunas, catástrofes y otras cosas para entretener a la población, pero seguro que a nadie se le ocurriría echar la culpa de lo de Pompeya a los contables de la zona ¿verdad?

Incluso se empezaron a dar las primeras burbujas de las que se tiene conocimiento como la holandesa de los tulipanes aunque posiblemente el tráfico de reliquias fuera otra industria similar muy pujante en la Edad Media. Vamos, que nadie se iba a molestar en montarse un tinglado como éste si no fuera porque daba dinero. Luego vendría Lutero para joderles en invento en Centroeuropa.

Ya en el siglo XVIII los economistas empiezan a jugar a filósofos y la cosa empieza a torcerse, aunque los comienzos no son malos. Ya Adam Smith se da cuenta de que el sistema imperante hasta el momento con monopolios y privilegios era altamente ineficiente y que la competencia es una cosa buena. Claro que el muy pardillo pensaba que el mercado se regulaba a sí mismo y sabemos que en el momento en que puede, uno se come al resto. Luego vinieron otros como Marx, Malthus con sus teorías económicas que en unas cosas acertaban y en otras cosas no o mejor dicho, lo que decían se cumplía en un contexto determinado, lo que no implicaba que en otro funcionara o fuera real. Lo cierto es que esta gente si tenía un peso importante, pero tampoco se les hacía caso al 100% ni mucho menos. Por ejemplo, en la muy comunista y recién creada Unión Soviética (que por aquel entonces ni siquiera se llamaba así) cambió el modelo comunista por uno capitalista a pequeña escala (se permitía el pequeño comercio y agricultura privada) en 1921: se llamaba la Nueva Política Económica (ya se la cargaría Stalin más adelante) Los muy liberales EEUU ya había publicado leyes contra el monopolio 30 años antes, la ley Anti-Trust. Vamos, que parafraseando a Churchill, la economía era un asunto muy serio para dejárselo a los economistas.

Pasan los años, viene la depresión del 29, las políticas de Roosevelt prohibiendo la posesión de oro, creando empleo público sacan a los EEUU de la gran depresión a la que la había llevado una tremenda burbuja bursátil. Al parecer nadie se había dado cuenta de que el crecimiento ilimitado no existía .... 

La SGM y la Guerra Fría fueron, aunque no lo parezca, un empuje para la ciencia, la economía (bueno, salvo que te devastaran el país) y la economía. Había dinero para proyectos científicos que, aunque tenían la sana idea de acabar con el prójimo, acabaron dejando una huella beneficiosa en la sociedad. Parece mentira que el GPS que ahora nos ayuda a llegar a nuestro destino sea el heredero de un cacharro que se lanzó aprovechando un misil nuclear que teníamos por ahí a mano. Menos mal que se acordaron antes de desmontar la cabeza nuclear.

Lo cierto es que la economía estaba controlada y el mundo iba más o menos bien. El nivel de vida de la gente iba mejorando poco a poco (en unos sitios más que en otros, como siempre) y por ejemplo, en EEUU en 1980 pagaba el 70% de impuestos por cada dólar que ganara por encima de 108.300 (si estaba soltero, claro) Como para quejarse de la subida que nos ha metido el Mariano. Por cierto,el paro de EEUU era el 7,5% (un poco alto para EEUU) 


¿Pensábais que era broma? Pues no.

Y llegaron los filósofos liberales (Tatcher, Reagan) .... y la cagamos. No a corto plazo, claro. Al principio, todos muy felices, llegaba mucho dinero (no confundir dinero con riqueza) ganabas más pero claro, las cosas eran más caras con lo que se llevaba una parte de tu incremento de riqueza, pero claro, había margen de crecimiento. Se externalizaban la producción (lo que se suele llamar riqueza) a otros países, a costa de dejar sin empleo a los del propio (mientras puedas crear nuevas industrias de otra cosa, tampoco tiene por que ser malo) y empezamos a dejar el control de las empresas a unos señores que se decían economistas pero que en realidad, atendían poco a la economía real sino que más bien eran seguidores de escuelas filosóficas-teológicas (pal caso ...) que no paraban de repetir mantras como el mercado se regula solo (falso) el estado no debe intervenir para nada (hombre, no veo una empresa estatal que fabrique por ejemplo tablets, pero si regulando el mercado para que no se desmande) regalando empresas a sus colegas o a sí mismos .... Ya a finales del s.XX ya tuvimos el primer aviso con la burbuja de las puntocom. En España su máximo exponente fueron aquellos 150 € por acción que se pagaron por Terra, recomprada por Telefónica años después  por 5 €. Aquella burbuja fue dirigida por unos ingenieros que no sabían de economía y por unos economistas que no sabían ... de nada. Pero la fiesta seguía y de las puntocom pasamos (o más bien seguimos) con el ladrillo. La siguiente crisis definida como crisis NINJA (No Incomes, No Job)


Los economistas (por llamarlos de alguna manera) sabían como iba esto, pero claro, como todos lo hacen, nadie dice nada (como si fuera una secta) Luego nos peta Fannie Mae, Enron, .... y te dices ¿quien coño dirige todo esto?

Y vemos que ahora, los gurús de la economía seguidores de Milton Friedman premio Nobel de Economía (esto del Nobel de Economía parece que se está convirtiendo en un cachondeo similar al Nobel de la Paz) y hay gente que los sigue sin pensar que ni todos los paises son iguales ni todos las situaciones son las mismas. Pueden meter la pata hasta en los cálculos que sus seguidores continúan diciendo lo mismo. Incluso ahora empiezan a darse cuenta de que igual se han pasado un pelín .... por supuesto nada es culpa de estos gloriosos economistas que dan lecciones a todos.

Se dice que los economistas hacen grandes predicciones sobre el pasado (y encima, cobran por ello) No vamos a ser crueles, y vamos a considerar que en realidad son análisis de lo que ha pasado. El problema es cuando basándose en lo que ha ocurrido en el pasado, intentan predecir el futuro. Nos podemos pensar que eso es la base de la ciencia pero el problema es que dado que las condiciones económicas, sociales, políticas, climáticas, ... están en constante cambio, este tipo de previsiones, no son demasiado fiables. Es fácil deducir que si gastas más de lo que ganas tendrás problemas en un futuro más o menos próximo (dependerá de la cantidad de cada uno) pero claro, luego hay una cosa llamada inflación que hace que las deudas de hoy valgan menos mañana (entre otras cosas, por eso se pagan intereses) con lo que si no te desmadras, es posible hacerlo (EEUU lleva haciéndolo muchos años, dándole a la máquina de imprimir dólares cuando hace falta) También les gusta hacerse trampas a sí mismos (lo de imprimir billetes cuando hace falta es una de ellas, pero ojo, que puede ser peligroso si no tragan todos) o cambiar de nombre las cosas para que no cuenten como tales.

Vamos, que al igual que los astrónomos tienen su alter ego magufo en los astrólgos, los economías (esa gente seria que lleva las cuentas, analiza los datos, intenta llegar a conclusiones, ...) hay otra, de momento con el mismo nombre que se dedica a hacer predicciones con una base cuanto menos débil ¿cómo llamamos a esa ciencia? Ecología no, que es otra cosa (que también tiene si parte seria y sus magufos) ¿Economología? Yo habida cuenta la fe de sus seguidores y que cambian como las religiones, cuando les conviene o son ya muy evidentes, propongo algo así como Teoeconología, ecoteonomía, o simplemente, teología económica. Lo cierto es que a esta economía yo la veo más en la rama de la filosofía o de la teología que en la de las ciencias.

Y por supuesto, en esta nueva "ciencia" no faltan los partidarios del Apocalisis (que va retrasando poco a poco)


Armaduras.

He de reconocer que últimamente no me estiro demasiado en el tema bloguero este. Tampoco voy a molestarme en hacer propósito de enmienda so...