iPlayas en el desafío Abredatos 2011
En 
El desafío
El fin de semana pasado, sábado 7 y domingo 8, tuvo lugar la segunda edición del concurso Abredatos. El desafío: desarrollar una aplicación en 48 horas que utilice datos públicos y que proporcione un servicio de cualquier tipo a los ciudadanos. El objetivo: crear conciencia en las instituciones públicas para que liberen los datos públicos y mostrar el potencial y la utilidad práctica que pueden suponer para todos nosotros. Algunas instituciones ya lo hacen, como la DGT o el Ayuntamiento de Zaragoza entre otras, pero no es suficiente.
Uno de los principales problemas actualmente es que los datos públicos no están preparados para ser consumidos por aplicaciones, sino para ser visualizados en un navegador. Esto obliga a los desarrolladores a utilizar web scrapping, lo cual puede ser más o menos costoso en función de como estén los datos. En el caso de iPlayas, la aplicación que desarrollamos nosotros, saca los datos de la “Guía de playas” del Ministerio de Medio Ambiente. Como se puede observar, no es más que un formulario y un listado de playas, por lo que hay que programar un script que simule rellenar los datos de ese formulario, haga click en el botón “Buscar”, y después extraiga las playas una por una, simulando los clicks necesarios para navegar entre las páginas de los listados. Todo esto supone esfuerzo y tiempo. Si el ministerio tuviera una guía de playas en XML, o un api Rest para consultarlas, no habría sido necesario hacer el scrapping y podríamos haber dedicado tiempo a introducir nuevas funcionalidades a la aplicación.
Nuestra aplicación
¿Y qué es iPlayas? Es un buscador de playas por proximidad para móviles. Imagina que estás de vacaciones en la costa y quieres saber qué playas hay cerca. Si tienes un móvil con GPS, navegador e internet (Android, iPhone, etc) puedes visitar iPlayas.es y te dará un listado de las playas que hay por la zona, ordenadas por distancia para que elijas cuál quieres visitar. De cada playa te dará la información que hemos sacado del ministerio de medio ambiente: si tiene bandera azul, puesto de cruz roja, acceso minusválidos, si se puede bucear, el tamaño de la playa, si es nudista, etc. Pero ¿cómo sabemos a qué distancia está? pues a partir de la posición que nos da el GPS de tu móvil (la latitud y longitud) y la posición de la playa, se calculan los metros de distancia que hay y se muestra primero la que está mas cerca (es decir, la que tiene una distancia menor).
En mi opinión, uno de sus puntos fuertes es que es extremadamente simple de usar: olvídate de registros o logins, al entrar en la aplicación aparece directamente el listado de las playas más cercanas, sin tener que hacer nada. Después se selecciona una playa y se muestra su información con un enlace para situarla en Google Maps y ya está. Aún así, el verdadero valor está en que se puede afinar la búsqueda usando “playas con aseos y cruz roja”, “nudistas en benidorm”, “que alquilen sombrillas y hamacas” o “accesible para discapacitados y con duchas”, todo en tres páginas y dos botones. Potencia, sencillez y usabilidad.
El desarrollo de la aplicación lo hicimos entre Adrián de la Horra, Marco Martinez y yo. Utilizamos Groovy para el scrapping de playas, Grails para la web de la aplicación, jQTouch para el diseño y SolR para guardar y buscar toda la información de las playas. El sábado lo dedicamos a crear el repositorio en Google Code, al scrapping de las playas, a preparar el esquema del SolR y programar los formularios y listados de la aplicación. El domingo registramos el dominio, hicimos el diseño de la página, maquetamos con jQTouch la aplicación, afinamos las búsquedas en SolR, pusimos algunos iconos y desplegamos la aplicación en el hosting. La verdad es que fue un fin de semana de trabajo intenso pero muy divertido: música a tope, risas y pizzas en las oficinas de Paradigma Tecnológico junto con otros tres equipos más que participaron en el desafío Abredatos con las aplicaciones miboe.es y Tus alertas de tráfico.
Conclusión
Sin duda ha merecido la pena: hemos hecho una aplicación que nosotros mismos usaríamos, usando datos públicos y creemos que bastante útil en general para el ciudadano: estás en Cádiz de vacaciones y te apetece ir a la playa, pero tienes un familiar en sillas de ruedas, así que usas iPlayas para buscar la playa más cercana con acceso para minusválidos. Objetivo cumplido. Esperemos contribuir, junto con el resto de aplicaciones, a que gobierno y administraciones públicas hagan sus datos más accesibles, transparentes y abiertos. Al fin y al cabo, los pagamos entre todos.
Si quieres probar iPlayas, puedes hacerlo desde tu móvil o desde tu ordenador de sobremesa visitando http://iplayas.es. La posición geográfica se obtendrá a través de la IP que te haya dado tu proveedor de internet, que puede estar más o menos cerca de donde estás físicamente.
Más información:
- Sobre nuestra aplicación iPlayas.es: página del equipo y código fuente.
- Listado completo de aplicaciones y equipos que hemos participado en el desafío.
- Noticias sobre el desafío 2011 en los medios: Euskadi-innova, La información y Rtve.es.
- Posts de los equipos de Polendamus, Congreso abierto, Primer viernes, Tricktrack y ZGZagua explicando sus experiencias y aplicaciones.
¿Has encontrado una noticia que se haga eco del desafío de este año, o has hecho una aplicación y has escrito un post contando la experiencia? ¡Pon el enlace en un comentario!
Tu navegador dice mucho de ti…
- A http://albertovilches.com/
- B https://www.bankinter.com
- C http://coderfacts.com/
- D http://dev.ringio.com/
- E http://www.elmundo.es/
- F http://www.facebook.com/
- G http://greach.es
- H http://hootsuite.com/dashboard
- I http://www.ingdirect.es/
- J http://javahispano.org/
- K http://kenshira.com/
- L https://www.linkedin.com/
- M http://www.memegenerator.net/
- N url de trabajo (Ringio), no publicable
- Ñ ¡no sale nada!
- O http://observatoriodegrails.com/
- P http://pixlr.com/
- Q url de trabajo (NH), no publicable
- R http://runkeeper.com/home
- S http://sixservix.com/blog/david/
- T http://www.tumblr.com/dashboard
- U http://www.uoc.edu/portal/castellano/index.html
- V http://vagos.es/
- W http://www.tumblr.com/
- X http://superuser.com/questions/52483/terminal-tips-and-tricks-for-mac-os-x
- Y http://www.youtube.com/
- Z http://www.zazzle.es/
Por cierto, a los que les salga alguna página NSFW en el historial: ¿es que no conocéis el navegar en incógnito? ¿y si coge el ordenador vuestra madre? :-)
Lo que es seguro es que todos, todos, todos tenemos a youtube en la Y, me apuesto 10 jeroclos de plata. Como me parece un meme interesante y gracioso, desde aquí invito a quien lo desee a que publique en su blog lo que su navegador dice sobre él (pon un enlace a tu post en los comentarios, para que todos podamos verlo).
¡Coderfacts!
De programador a programador: os invito a que visitéis coderfacts.com. Coderfacts es un blog donde se publicarán principalmente viñetas originales (es decir, creadas por mí mismo o enviadas por cualquier colaborador que lo desee) y cuya temática es la programación y la tecnología, pero sobre todo, el humor.
Y es que trabajando y programando tanto tiempo al día durante tantos años al final siempre ocurren las mismas situaciones, y merece la pena reirse de ellas. Estas viñetas están inspiradas en los programadores: en ti, en mí, en ese compañero que todos tenemos, en ese jefe, en ese cliente, en esa oficina llena de geeks, frikis, progamadores o como nos quieran llamar, pero en el fondo (pero muy en el fondo), personas: a todos ellos van dedicadas estas viñetas. :-)
Tecnicamente el proyecto es más sencillo que el mecanismo de un chupete: está alojado en tumblr.com, conectado con Disqus para los comentarios y Feedburner para el RSS. ¡Y tiene incluso su propia cuenta Twitter! El blog es abierto y cualquier puede participar: para crear las viñetas se puede usar Memegenerator, este editor de Rage comics, Superlame, Photoshop, el Paint o lo que quieras. Por supuesto que las viñetas enviadas llevarán el nombre/web del autor, faltaría más.
¡Os espero en coderfacts.com! Suscríbete por RSS o por Twitter en @coderfacts y, si quieres, ¡participa!
Razones por las que ir (y no ir) a mi taller de DSLs en Groovy
Este viernes en el Spring IO, a las 15:00, daré un taller de creación de DSLs en Groovy.
Será parecido al seminario que dí el año pasado sobre DSLs, solo que está vez será, principalmente, práctico en vez de teórico. La idea es que todos empecemos a programar siguiendo unos pasos definidos para que sea más interesante y los conocimientos se aprendan. Sin embargo, el Spring IO de este año está divido en tres tracks, de manera que tenemos que elegir a qué charlas vamos a ir porque siempre nos vamos a perder algo. A continuación unas razones porqué deberías ir (o no) a mi taller:
Por qué ir:
- Porque vamos a dar una charla rápida y explicar qué es un DSL.
- Porque vamos a meternos en las tripas de Groovy ver qué nos ofrece para crear DSL.
- Porque vamos a jugar con IntelliJ IDEA 10 Community.
- Porque vamos a hacer un DSL para crear PDFs, y hasta la fecha no hay ninguno: puedes acabar el DSL en tu casa y después publicarlo y ser famoso.
- Porque según lo vayamos creando, saldrán algunos problemas típicos y tendremos que refactorizar.
- Porque el taller está dividido en pasos claramente separados donde se ve la evolución del DSL que vamos a crear (y está la solución en el paso siguiente, por si alguien se atasca).
- Porque veremos algunos trucos de Groovy interesantes que tengo preparados.
- Porque podremos (¡debemos!) preguntar y hablar y opinar y dar ideas sobre el DSL y podremos probarlo sobre la marcha.
- Porque vamos a programar.
Y por qué no ir:
- Porque a la misma hora hay cuatro charlas interesantes, de las que destaco especialmente la de “Tunning your Grails applications” de Peter Ledbrook.
- Porque las otras tienen bastante buena pinta también: será interesante ver la experiencia de Juan Manuel y Michel Jensen enseñando Grails en la Universidad de Cadiz ¡qué suerte tienen sus alumnos!
- Porque no conoces (¡como yo!) ni Spring Hadoop ni Summer (la librería de HTML5 para Java y Scala) y te apetece saber qué son y como funcionan.
- Porque vienes a Spring IO por Spring y Java, y no te interesa Groovy o los DSLs.
- Porque a las 15:00 no perdonas nunca la siesta. ;)
- Y porque vivo en Madrid, y sabes que si hay suficiente gente interesada podremos repetir el taller cuando quieras: seminarios.
¡Nos vemos en el Spring IO!
Recortando el currículum y el primer empleo
Homer una vez tuvo que leer un currículum que tenía cuatro páginas.
De vez en cuando, como casi todo el mundo, me gusta actualizar el currículum y añadir lo último en lo que he estado trabajando o lo nuevo que he aprendido. Según dicen algunas normas no escritas, lo suyo es que el currículum no pase de dos páginas, o directamente nadie lo leerá. Así que, si durante toda nuestra vida laboral no hacemos más que añadir y añadir cosas, llega un momento en el que, después de doce años trabajando, tu currículum puede llegar a ser aburridamente largo. Y hay que meter tijera para reducirlo, por supuesto.
Por donde empezar está claro: en tecnología, cuanto más antiguo es un trabajo, menos relevancia tiene hoy en día. Así que tu primer empleo, después de unas cuantas sesiones reductoras, pasa de ser una larga descripción, para convertirse, año tras año, en una simple frase que casi da hasta pena dejarla. Y en ese momento piensas ¿debería directamente eliminarlo? Pues no, yo no quiero quitar mi primer trabajo porque le tengo mucho cariño. Y es que, aunque nada de lo que usaba por aquel entonces se use ya ahora, aprendí a trabajar en una oficina, a tener un jefe, un horario y a que las vacaciones no duraban 4 meses, sino 22 días laborables. Y como me apetece hablar un poco ello, a modo de historia del abuelo cebolleta, hoy contaré como fue mi primer trabajo.
Si, yo tuve uno de estos.
Junio de 1998, era la época del rincón del vago, los móviles Nokia 5110 y la PlayStation, los monitores de 14″ con culo y los Pentium II con 128Mb, el inicio de la burbuja puntocom y la salida a bolsa de terra.es. Internet llevaba ya algunos años en España con cosas tan penosas como Infovia y no existía infojobs o jobsket para encontrar empleo, ni nada parecido. Así es que tuve que buscar mi primer trabajo como seguramente hicieron nuestros padres: mirando en el periódico (de papel, me refiero; en concreto el segundamano) y llamando por teléfono desde casa (casi nadie de mi edad teníamos móvil). Llevaba ya algunos años programando en Clipper por mi cuenta con libros en casa, así que probé suerte y llamé a la única oferta que había de “Programador Clipper”. Y como en el carné de conducir, que aprobé todo a la primera; al primer sitio que llamé, les gusté y me contrataron. Por aquel entonces había una gran demanda de programadores, pues había que adaptar todas las aplicaciones para evitar el efecto 2000 y también para que aceptaran la nueva moneda que se avecinaba, el euro.
La empresa donde entré a trabajar se llamaba Teleinformática (que fue comprada por Azertia, que fue comprada por Soluziona, que fue comprada por Indra) y su principal cliente era el BBV (que todavía no se había fusionado con Argentaria).
Me incorporé a un equipo de diez programadores que desarrollaban aplicaciones de banca electrónica. En aquellos tiempos los bancos no tenían páginas web tan buenas como ahora, así que tenían que crear aplicaciones para que sus clientes (generalmente empresas) pudieran enviar operaciones al banco (a través de un modem) para hacer transferencias, consultar movimientos y todas estas cosas que ahora hacemos desde internet a diario.
La aplicación estrella se llamaba SIETE: una aplicación de escritorio desarrollada en Clipper y que corría sobre MS-DOS. Entonces Windows 95 era relativamente joven y, aunque ya había un departamento que creaba la misma aplicación para Windows en Delphi, se mantenían las dos versiones. Poco a poco el departamento de Windows creció y el de MS-DOS desapareció, pero eso es otra historia.
Empecé a interesarme en Clipper en el 90, mis padres me compraron todos estos libros en el corte inglés (tuve una adolescencia muy dura). Ahora los guardo como un tesoro (que solo yo puedo apreciar, claro). Pincha en la foto para verla un poco más grande.
Clipper era un lenguaje procedural, no orientado a objetos, con un sistema integrado muy cómodo para manejar base de datos, pues estaba basado en dBase III. No teníamos potentes IDEs como ahora, programábamos con editores prehistóricos como QEdit, Aurora y otros más que no recuerdo. Compilábamos con scripts en BAT que tardaban minutos en generar un ejecutable. Tampoco teníamos control de versiones, así que usábamos una carpeta compartida entre todos en un servidor remoto y avisábamos cuando alguien tenía que tocar algo para no pisarnos los fuentes.
No había internet, ni correo electrónico, ni nada por el estilo, así que las tareas las definía tu jefe de proyecto, las estimaba con Microsoft Project, las imprimía y te las daba en un papel donde ibas tachando las que ibas haciendo. La única manera de “comunicación” era compartir carpetas y copiar archivos, y los disquetes de 3.5″ claro. Ni comparación con ahora, que no podemos trabajar sin internet o correo (ya sea corporativo o gmail/hotmail/etc), buscar documentación o ejemplos o tutoriales o lo que sea, vamos.
 Programando como machos con el QEdit. Era duro, pero peor era el Edit... |
 Los profesionales usábamos Aurora, ¡con sintaxis coloreada! |
No había patrones, ni buenas prácticas ni metodologías ágiles. Te daban cientos de fuentes caóticos que habían sido tocados por decenas de personas antes. Y había que buscarse la vida. Al final, al cabo del tiempo, le cogías el truco, pero era bastante duro, pues te pasabas la mayor parte del tiempo intentando descifrar lo que había hecho el programador anterior. Por supuesto no existían las pruebas unitarias ni nada parecido, pero había algo que no fallaba: un departamento de control de calidad exclusivo para probar, que pasaban cientos de baterías de pruebas y hasta que no se pasaban todas, no se liberaba una versión. Así que al final, entre todos y con mucho esfuerzo, sacábamos el trabajo y conseguíamos hacer funcionar esa endemoniada aplicación que después correría en los PCs de cientos de clientes del BBV.
Y así pase dos años y medio, primero con Clipper y luego con Delphi, hasta que a finales del año 2000 me empezó a picar la curiosidad por un lenguaje nuevo y que parecía bastante interesante porque se podían construir aplicaciones para internet: Java. Pero eso también es otra historia.
Así es que cuando miro mi currículum y veo esa última frase en el apartado de experiencia que pone “1998-2000: Programador en Clipper de aplicaciones en banca electrónica”, algo dentro de mi me dice que ya ha sufrido suficientes recortes, y que no merece la pena borrar dos años de mi vida para ganar dos líneas de espacio. Así es que así se quedará, para siempre.
¿Y tú? ¿Cómo fue tu primer trabajo?
Artículos relacionados: Al principio, todo era mágico
ITIL v.3 por Ernesto Vilches
Conozco a Ernesto Vilches desde que era pequeño, aunque él me conoce a mí desde que nací, más que nada porque es mi padre. No suelo hablar de cosas personales en el blog, pero este caso es especial porque está relacionado con la tecnología. Después de bastante tiempo trabajando duro, ha acabado y publicado su primer libro. Enhorabuena papá, no todo el mundo puede presumir de haber escrito un libro.
De venta en el corte inglés: http://ebooks.elcorteingles.es/GUIA-DE-GESTION-DE-SERVICIOS-BASADA-EN-FUNDAMENTOS-DE-ITIL-V3-LibroEbook-9788492684601.html
Entendiendo como funciona el desarrollo a medida
La toma de requisitos, las funcionalidades, las pruebas de aceptación, todo son conceptos relativos y su significado depende de quién lo mire. Una estupenda guía para entender como ven cada una de las partes los encargados de crear un aplicación a medida: 
- Lo que el cliente dijo.
- Lo que entendió.
- Lo que se planeó.
- Lo que se desarrolló.
- Lo que describió el analista del negocio.
- La documentación.
- Lo que se desarrolla.
- Por lo que ha pagado el cliente.
- El soporte.
- Lo que el cliente realmente necesitaba.
Vía: Making Good Software, compartido en su Google Reader por Javier Neira
Flex y Adobe Air
Para mí, Flex es la solución ideal para que un programador (sobre todo de Java) pueda hacer un Flash sin tener que pelearse con la propia herramienta de Flash. ¿Quién no ha querido alguna vez hacer un flash para una página con alguna animación o con un formulario o con lo que sea, y le ha dado una pereza máxima ponerse a aprender como utilizar Adobe Flash CS4? Para empezar es de pago, y no es barata, y para acabar es un sistema de desarrollo al que los programadores normales no estamos acostumbrados: se trabaja con un timeline, con escenas, con capas, gráficos y sprites, pinceles, efectos: herramientas que los diseñadores usan día a día, pero que nosotros, programadores que trabajamos con un IDE, no solemos utilizar. De todas formas, Adobe Flash CS4 también permite programar usando ActionScript por supuesto, pero siempre tendrás que usar la herramienta Adobe Flash para programar este código y generar el swf de flash final.
Sin embargo, con Flex, trabajas con Flex Builder (un plugin para Eclipse, de pago), o con IntelliJ o Netbeans o con el bloc de notas. Tienes una estructura de clases y paquetes como en Java, y tienes tus ventanas y vistas como ficheros .mxml, que bien pueden recordarte a un JSP. Así que el entorno, para nosotros los programadores, es mucho más amigable desde el principio. Además, puedes generar tu fichero swf de flash y compilar tus clases y mxml desde la línea de comandos o con Ant, gracias a su SDK libre, así que incluso el uso de IDE es opcional (aunque altamente recomendado).
Para rematar, con Flex puedes, además, crear aplicaciones ricas de escritorio con Adobe Air. Estas aplicaciones son multiplataforma (corren en Linux, Mac y Windows) y su interfaz visual es muy muy buena. Un ejemplo de las posibilidades que tiene Flex (y por lo tanto Air) lo puedes ver en el Tour de Flex. Y un gran ejemplo sobre aplicación desarrollada con Adobe Air que es ampliamente utilizada es Tweetdeck, entre muchas otras.
Personalmente, estoy muy contento con los resultados de Adobe Air. Por un lado, ActionScript 3 (el lenguaje utilizado en Flash, Flex y Air) es muy sencillo de utilizar y muy rápido de aprender para un programador Java (recuerda mucho a Java y Javascript). Es orientado a objetos (herencia) y eventos de manera nativa, mezcla tipado fuerte con tipado débil, tiene reflection, puedes guardar un método en una variable y ejecutarlo cuando quieras (como en Javascript), puedes acceder a cualquier atributo de un objeto como si fuera un array o mapa (¡acceso dinámico estilo Groovy!) y muchas cosillas más que lo hacen muy interesante. Y por otro, toda la jerarquía de componentes visuales es muy completa y está muy bien pensada. Parece como si los creadores de Flex hubieran cogido todos los componentes de DOM de HTML, su api de acceso de Javascript y Swing, le hubieran mezclado todo, quitado lo malo y dejado solo lo bueno.
Mi conclusión es que Flex es una plataforma de desarrollo muy rápida con resultados muy efectivos, que nos permite crear Flash o aplicaciones de escritorio de la misma manera (y multiplataforma), con un lenguaje, Action Script, que posee una curva de aprendizaje muy suave para programadores Java (y para cualquier programador, me atrevería a decir) y sin cambiar nuestro IDE. Y además, posee una gran documentación y tutoriales ¿Qué más se puede pedir?
La megacorporación, el nuevo villano.
El nuevo villano del cine se llama megacorporación: grandes multinacionales, gigantes y poderosas, que, de una manera anónima y sin escrúpulo alguno, persiguen un beneficio económico con medios abusivos y/o dudosamente éticos.
En Moon, una gran empresa explota un yacimiento casi inagotable de Helio 3 en la cara oculta de la luna. Para ello, envía a un único operador cada tres años a una base privada en este satélite para encargarse de controlar, día a día y en solitario, la recolección del Helio 3 y enviarlo a la tierra. Durante la película se descubrirá poco a poco que la empresa contratista utiliza algunas técnicas de dudosa moralidad para llevar a cabo esta explotación minera. La película es una clara lucha que el protagonista libra con esta multinacional, un villano poderoso que se oculta tras un par de empresarios en una vídeo conferencia.
Multinacionales, unidas, jamás serán vencidas
En District 9, la MNU (no os perdáis la página Multi National United, con ofertas de trabajo como dentistas para alienígenas), es la responsable de la gestión del distrito 9, un asentamiento donde se hacinan los extraterrestres cuya nave ha quedado varada en la tierra y se encuentran atrapados en Johannesburgo. La MNU mezcla argucias legales y papeleos con la producción en masa de armamento militar para obtener sus fines, y posee un cuerpo paramilitar privado que no duda en abrir fuego contra los aliens si lo cree necesario. De nuevo, el gran villano de la película toma forma de megacorporación, una multinacional que intenta vender una imagen humana y respetuosa con los derechos civiles en el trato con los extraterrestres, pero que esconde una doble intención bastante inhumana.
Y en Avatar, una empresa energética es la responsable de obtener un mineral de grandísimo valor en el mercado que se esconde en el planeta Pandora. Para ello utilizará un increíble ejercito privado de mercenarios que tampoco dudará en usar la fuerza bruta y la alta tecnología para exterminar cualquier “amenaza” que se interponga para obtener dicho mineral. Hay un momento en que la devastación que produce la megacorporación es tal, que los propios responsables de la misma tienen que apartar la mirada de los monitores donde visionan sus operaciones.
La aversión del espectador hacia una megacorporación es siempre mayor que hacia un simple villano: la megacorporación es anónima y gigante, por lo que la sensación de impotencia al no poder luchar individualmente con ella incrementa la rabia hacia la misma, definiendo su papel de villano en la película. Por supuesto, la megacorporación comete actos reprochables rozando incluso la criminalidad (o sobrepasándola con creces) y su único móvil es el lucro, lo que irrita al espectador cuando contempla sus acciones, acostumbrado a villanos individuales cuyo móvil suele ser más humano, como la venganza, una psicosis o son, simplemente, malignos. Y lo mejor es que la sensación durante la película de que ese tipo de megacorporaciones pueden llegar a existir -o que existen-, alimenta un miedo real en el espectador, mezcla entre desamparo y debilidad, que no es capaz de crear un villano normal.
Con el nuevo ED209 las acciones de la OCP se dispararán
Y son solo tres ejemplos de tres películas recientes de este año, pero se me ocurren algunas más, como la famosa OCP (Omni Consumer Products), encargada de fabricar armamento militar (entro otras cosas) y de diseñar el nuevo sustituto de los policías, Robocop, utilizando para ello los restos del cuerpo de un agente caído en servicio y titanio a partes iguales. Otras películas explotan el concepto sin llegar a criminalizarlo, como Cypher, donde dos compañías luchan por espiarse secretos entre sí, usando técnicas poco éticas para la contratación de agentes dobles. O incluso Network, donde una gran compañía de televisión hace cuanto está en su mano para aumentar la audiencia.
Las megacorporaciones incluso han sido fuente de inspiración para crear películas pseudo-documentales, casi de culto, como Zeitgeist the movie y Zeitgeist addendum (ojo al visionarlas, no todo lo que dicen es verdad, conviene siempre contrastar la información con otras fuentes). Estas películas cuentan historias increíbles sobre conspiraciones que hacen grandes empresas mezcladas con el gobierno estadounidense, cuyo único objetivo es crear guerras y saquear los recursos naturales de los países pobres (con la excusa de combatir el terrorismo) para controlar el mundo, muy en la línea del concepto de megacorporación. Estos documentales y algunos otros (como el de Money as debt) llegan incluso a contar que el dinero y el crédito es un invento que solo sirve para someter a la población mundial a base de deuda. Aunque si quieres saber la verdad que esconden estos documentales, visita esta página donde un economista rebate, punto por punto, todas las contradicciones que cuentan sobre la creación artificial de dinero gracias al crédito. De todas formas, el montaje de estos vídeos fomenta el mismo miedo a las corporaciones que cualquiera de las anteriores películas, o incluso más, al estar basado, supuestamente, en hechos reales. Por cierto, el libro “mágico” donde explica como la reserva federal (y todos los bancos del mundo), multiplican el dinero en cada crédito lo puedes descargar aquí: Modern Money Mechanics. Bola extra: fragmento de la película “El concurstante” donde explica como crear dinero a partir del crédito.
La MNU, trabajando por mantener la seguridad en el distrito 9
Atraído por el concepto de megacorporación y buscando un poquito más en la Wikipedia, me encuentro con que este termino fue popularizado por el escritor de ciberpunk Willian Gibson, haciendo referencia un holding de grandes (mega) empresas que controlan, rozando el monopolio, múltiples mercados y cuya principal característica es que son tan poderosas que traspasan la legalidad. Poseen su propio ejercito privado y debido a su gran tamaño, tienen incluso su propio territorio soberano. Pero es que resulta que ¡las megacorporaciones existen! Por ejemplo, pese a que no posee su propio ejercito, Walt Disney es una megacorporación. Y aunque no comete ninguna ilegalidad que sepamos (puede que por la naturaleza de su negocio, la creación audiovisual de entretenimiento o porque, simplemente, son buenos), si que posee un territorio con sus propias leyes de administración y construcción: el Reedy Creek Improvement District. En este territorio, Walt Disney construye y controla sus propios edificios e instalaciones, normalmente responsabilidad del gobierno, como centrales electricas o cuerpos de bomberos; y solo permite la entrada a dicho distrito a empleados de la compañía. Es decir, una empresa que posee su propio territorio soberano.
Su propia moneda
Y su bandera
Un ejemplo histórico fue la compañía Holandesa de las Indias Orientales, una empresa con poderes cuasi-gubernamentales y con capacidad para declarar guerras, negociar tratados, acuñar su propia moneda y establecer colonias. Pero no temas porque ya no existe: fue fundada en 1602 por los países bajos y finalizó en el 1800, la época del imperialismo y la expansión internacional, donde el concepto de monopolio todavía no estaba mal visto. En esa época los países se expandían mediante colonias y delegaban su control en empresas privadas, las megacorporaciones de la época, dándoles poderes totales, como la compañía Británica de las Indias Orientales y otras tantas. La mayoría operaron durante casi dos siglos y reportaron dividendos anuales de hasta el 18%, pero acabaron en bancarrota ahogadas en deudas.
En resumen, si existen o no las megacorporaciones tal y como nos las cuentan en el cine o en los documentales, nunca lo sabremos. Las leyes anti monopolio nos protegen de gigantes informáticos como Microsoft, Google o Facebook pero nada más: no sabemos que hacen ni a quien venden nuestros datos (aquí va un vídeo conspiranoico sobre la cara oculta de Facebook). Y poco sabemos de las grandes empresas armamentísticas y energéticas (1991, los Irakies se retiran de Kwait y prenden fuego a los pozos de petroleo), seguramente por interés directo de los gobiernos que hacen uso de ellas, como la empresa de seguridad Blackwater USA, un ejercito privado al servicio de los estados unidos. Y es que, que existan tantas empresas privadas que se beneficien de los conflictos bélicos siempre da un poco de miedito: si se acabaran las guerras tendrían que cerrar, así que en el fondo no les interesa la paz ¿no? Megacorporaciones, ¿conoces alguna o alguna película sobre ellas?
Loss leader y externalidades
Algunas cosas que he aprendido hoy leyendo blogs, como que cuando una empresa puede beneficiarse de la venta de un producto o servicio, aunque pierda dinero, se llama ser un Loss Leader. Borja Prieto lo explica mejor en su blog: El Bulli como loss leader. Y también que cuando las empresas no contabilizan el coste o beneficio de una actividad, es muy difícil hacerles cambiar si no tienen un interés directo en ello. A estos costes indirectos no computados se les llama externalidades de un mercado. “El Gurú” lo cuenta muy bien en makememinimal, donde habla sobre los nuevos bienes escasos, la propiedad intelectual (o la no propiedad) y las externalidades. Muy interesantes.
Categorías
- Crónicas (6)
- Groovy (20)
- Humor (14)
- Internet (48)
- Juegos (26)
- Noticias (110)
- Programación (73)
- Software (25)
- Tutoriales (11)
- Yo, programador (39)
