jueves, 23 de diciembre de 2010
Feliz Navidad y próspero año 2011
Os deseo, con todo cariño y agradecimiento, una Feliz Navidad y un próspero, único, entrañable y especial año 2011, en el que deseo que vuestros deseos y vuestros sueños se hagan realidad.
miércoles, 22 de diciembre de 2010
Gracias, Sinde
Ayer se extinguió el intento golpista de la ley más polémica y antidemocrática de la última década, en un órdago que el gobierno creyó ganar e imponer con sus cartas marcadas. Poco le sirvió intentar camuflarla dentro de un paquete de leyes diferente. Poco le sirvió intentar presionar y negociar con el resto de partidos políticos. Poco le sirvió los argumentos dóciles intentando convencer de que no hay segundas intenciones y de trasfondo. Al final, PSOE se quedó sólo, con el sabor amargo de una derrota sin precedentes, indicador clave de una crisis de gobierno, condimentado con una tendencia de otras crisis que le han venido grandes y de las que no ha sabido estar a la altura.
La ley Sinde lleva dando bandazos desde su nacimiento (hace ya mucho tiempo), encontrando barreras allá donde va, pues es antipopular. Gracias a Wikileaks nos enteramos de que esta ley viene escrita desde EEUU, cuyo gobierno, simpatizante (o calzonazos) de la industria cinematográfica de Hollywood, ha estado presionando a nuestro gobierno, a pesar de los informes de casos infructuosos de cierres de páginas web en nuestro país. Y es que en nuestras salas de cine, más del 85% de las películas proyectadas son "made in USA", y eso no es suficiente para la infinita codicia de unos magnates anticuados. Hay que acusarnos de ser el país más pirata del mundo, cuando de siempre se ha sabido que nuestros galeones eran asaltados y hundidos por piratas de otros países. La acepción de la palabra pirata, según el diccionario de la Real Academia de la lengua Española, es la siguiente:
"Persona que, junto con otras de igual condición, se dedica al abordaje de barcos en el mar para robar.
Persona cruel y despiadada.
Persona que, bajo amenazas, obliga a la tripulación de un avión a modificar su rumbo."
Sería irónico pensar que una ama de casa, un estudiante adolescente, un señor jubilado, un autónomo, un "currito", o cualquiera de los millones de personas a los que se les acusa de piratas, vayan por la calle sembrando el pánico cruelmente, amenazando despiadadamente al resto de ciudadanos. Es calumnioso, cuanto menos. Se está faltando el respeto de millones de personas y de un país.
Nuestro gobierno ha cedido a las presiones de una industria decadente condenada a la extinción. No digo ésto sin una buena razón. Internet y la sociedad de la información están aquí desde hace casi dos décadas. Es una revolución sin precedentes en la historia, incluso mayor que la revolución industrial. Esta revolución ha calado en la sociedad, en las economías, en los negocios, en las políticas... en todo, salvo la industria de la cultura. Ha revolucionado en la forma de comunicarnos, de expresarnos, de comprar, de consultar información, de planificar nuestras vacaciones, de compartir intereses... Todo se está adaptando y evolucionando en torno a la sociedad de la información, porque es beneficioso y porque cubre las necesidades de los compromisos sociales y económicos. Cualquier empresa hoy en día tiene su página en internet, y ha adaptado su modelo de negocio a la web. Desde hace ya tiempo, los ciudadanos, antes de comprar, consultan productos y precios en internet, se informan bien sobre sus características y ventajas, y, por último compran aquello que mejor se adapta a sus necesidades personales. Sin embargo, la industria cinematográfica y de la música, no quieren evolucionar, y se aferran agónicamente al obsoleto modelo de negocio que tanto beneficio les ha dado durante tantos años antes de la revolución de la información. Es cierto que podemos comprar películas y música a través de internet, pero no aportan ningún valor añadido con respecto al formato tradicional. ¿Por qué pagar el mismo precio por una canción en formato electrónico que en formato físico (precio/canción), si la discográfica se ahorra costes de producción, logística y tienda? Si esta industria no innova, no escucha ni satisface las necesidades de los consumidores de esta época, está condenada a su extinción.
No entraré en más detalles sobre asuntos de los que ya se han discutido y sobre los que se han escrito ríos de tinta. Me concentraré en la polémica ley Sinde y lo que dicha ley ha supuesto estos días. Pero no voy a dar más datos de los que ya se conocen y que se pueden consultar en otros medios, principalmente en http://sindegate.net.
Me gustaría dar las gracias a Sinde y a su ley. No, no me estoy volviendo loco. Lo digo seriamente y con sinceridad. GRACIAS, SINDE. Pero, ¿Por qué? Por que la ley Sinde hay tenido éxito. Pero no el éxito que se esperaba. Si no el éxito de movilización de miles de ciudadanos para expresar libremente su opinión. Las barricadas ya no están en la calle, si no en la red, donde hay un movimiento más multitudinario, más social, más rápido, más interactivo, y más efectivo. Las redes sociales estaban a rebosar de proclamas y activistas. Las redes sociales se convirtieron en cacerolas hirvientes de opiniones ciudadanas.
Donde más ciudadanos se encontraron, donde más ciudadanos expresaron libremente su rechazo a esta ley, donde más ciudadanos coincidieron y lucharon, fue, sin duda alguna, Twitter.
Este medio, nacido de la idea de los SMS, se convirtió en el medio por el cual el interés sobre esta ley se multiplicó viralmente hasta límites incuantificables. Durante el lunes y el martes (anteayer y ayer), seguimos con gran interés los tweets que a cada segundo se recibían en distintos canales, tales como #leysinde o #sindegate. Hubo más canales, sin duda alguna, pero estos fueron los reyes de la batalla de los medios.
Por ello, Ángeles González-Sinde, le quiero dar las gracias por su ley, pues ha despertado el interés de ciudadanos que creíamos dormidos, y que, a pesar de la lluvia y el frío, se han manifestado a través de internet para expresar su repulsa a una ley que no es más que espasmo delirante de una agonizante industria que se muere por no evolucionar. Le quiero dar las gracias por descubrir, sin que lo previese ni quisiese, un movimiento de expresión más popular y efectivo que una manifestación o un referendum. Le quiero dar las gracias por poner de acuerdo y reafirmar las convicciones de la mayor parte de los ciudadanos de este país, de levantarles de su adormecimiento y hacerles dar un puñetazo en la mesa ante un ataque a sus derechos. Le quiero dar las gracias por hacer que millones de españoles tengan interés por informarse, por despertar del letargo de desinformación y engaño. Le quiero dar las gracias por hacer que los ciudadanos españoles sepan algo más sobre internet y sobre la propiedad intelectual, pero, sobre todo, por estimular el interés por la información y por la política (aunque sea en unas circunstancias un poco humillantes). En resumen, GRACIAS, SINDE.
Fuente: http://rhernamperez.wordpress.com/2010/12/22/gracias-sinde
La ley Sinde lleva dando bandazos desde su nacimiento (hace ya mucho tiempo), encontrando barreras allá donde va, pues es antipopular. Gracias a Wikileaks nos enteramos de que esta ley viene escrita desde EEUU, cuyo gobierno, simpatizante (o calzonazos) de la industria cinematográfica de Hollywood, ha estado presionando a nuestro gobierno, a pesar de los informes de casos infructuosos de cierres de páginas web en nuestro país. Y es que en nuestras salas de cine, más del 85% de las películas proyectadas son "made in USA", y eso no es suficiente para la infinita codicia de unos magnates anticuados. Hay que acusarnos de ser el país más pirata del mundo, cuando de siempre se ha sabido que nuestros galeones eran asaltados y hundidos por piratas de otros países. La acepción de la palabra pirata, según el diccionario de la Real Academia de la lengua Española, es la siguiente:
"Persona que, junto con otras de igual condición, se dedica al abordaje de barcos en el mar para robar.
Persona cruel y despiadada.
Persona que, bajo amenazas, obliga a la tripulación de un avión a modificar su rumbo."
Sería irónico pensar que una ama de casa, un estudiante adolescente, un señor jubilado, un autónomo, un "currito", o cualquiera de los millones de personas a los que se les acusa de piratas, vayan por la calle sembrando el pánico cruelmente, amenazando despiadadamente al resto de ciudadanos. Es calumnioso, cuanto menos. Se está faltando el respeto de millones de personas y de un país.
Nuestro gobierno ha cedido a las presiones de una industria decadente condenada a la extinción. No digo ésto sin una buena razón. Internet y la sociedad de la información están aquí desde hace casi dos décadas. Es una revolución sin precedentes en la historia, incluso mayor que la revolución industrial. Esta revolución ha calado en la sociedad, en las economías, en los negocios, en las políticas... en todo, salvo la industria de la cultura. Ha revolucionado en la forma de comunicarnos, de expresarnos, de comprar, de consultar información, de planificar nuestras vacaciones, de compartir intereses... Todo se está adaptando y evolucionando en torno a la sociedad de la información, porque es beneficioso y porque cubre las necesidades de los compromisos sociales y económicos. Cualquier empresa hoy en día tiene su página en internet, y ha adaptado su modelo de negocio a la web. Desde hace ya tiempo, los ciudadanos, antes de comprar, consultan productos y precios en internet, se informan bien sobre sus características y ventajas, y, por último compran aquello que mejor se adapta a sus necesidades personales. Sin embargo, la industria cinematográfica y de la música, no quieren evolucionar, y se aferran agónicamente al obsoleto modelo de negocio que tanto beneficio les ha dado durante tantos años antes de la revolución de la información. Es cierto que podemos comprar películas y música a través de internet, pero no aportan ningún valor añadido con respecto al formato tradicional. ¿Por qué pagar el mismo precio por una canción en formato electrónico que en formato físico (precio/canción), si la discográfica se ahorra costes de producción, logística y tienda? Si esta industria no innova, no escucha ni satisface las necesidades de los consumidores de esta época, está condenada a su extinción.
No entraré en más detalles sobre asuntos de los que ya se han discutido y sobre los que se han escrito ríos de tinta. Me concentraré en la polémica ley Sinde y lo que dicha ley ha supuesto estos días. Pero no voy a dar más datos de los que ya se conocen y que se pueden consultar en otros medios, principalmente en http://sindegate.net.
Me gustaría dar las gracias a Sinde y a su ley. No, no me estoy volviendo loco. Lo digo seriamente y con sinceridad. GRACIAS, SINDE. Pero, ¿Por qué? Por que la ley Sinde hay tenido éxito. Pero no el éxito que se esperaba. Si no el éxito de movilización de miles de ciudadanos para expresar libremente su opinión. Las barricadas ya no están en la calle, si no en la red, donde hay un movimiento más multitudinario, más social, más rápido, más interactivo, y más efectivo. Las redes sociales estaban a rebosar de proclamas y activistas. Las redes sociales se convirtieron en cacerolas hirvientes de opiniones ciudadanas.
Donde más ciudadanos se encontraron, donde más ciudadanos expresaron libremente su rechazo a esta ley, donde más ciudadanos coincidieron y lucharon, fue, sin duda alguna, Twitter.
Este medio, nacido de la idea de los SMS, se convirtió en el medio por el cual el interés sobre esta ley se multiplicó viralmente hasta límites incuantificables. Durante el lunes y el martes (anteayer y ayer), seguimos con gran interés los tweets que a cada segundo se recibían en distintos canales, tales como #leysinde o #sindegate. Hubo más canales, sin duda alguna, pero estos fueron los reyes de la batalla de los medios.
Por ello, Ángeles González-Sinde, le quiero dar las gracias por su ley, pues ha despertado el interés de ciudadanos que creíamos dormidos, y que, a pesar de la lluvia y el frío, se han manifestado a través de internet para expresar su repulsa a una ley que no es más que espasmo delirante de una agonizante industria que se muere por no evolucionar. Le quiero dar las gracias por descubrir, sin que lo previese ni quisiese, un movimiento de expresión más popular y efectivo que una manifestación o un referendum. Le quiero dar las gracias por poner de acuerdo y reafirmar las convicciones de la mayor parte de los ciudadanos de este país, de levantarles de su adormecimiento y hacerles dar un puñetazo en la mesa ante un ataque a sus derechos. Le quiero dar las gracias por hacer que millones de españoles tengan interés por informarse, por despertar del letargo de desinformación y engaño. Le quiero dar las gracias por hacer que los ciudadanos españoles sepan algo más sobre internet y sobre la propiedad intelectual, pero, sobre todo, por estimular el interés por la información y por la política (aunque sea en unas circunstancias un poco humillantes). En resumen, GRACIAS, SINDE.
Fuente: http://rhernamperez.wordpress.com/2010/12/22/gracias-sinde
lunes, 20 de diciembre de 2010
La política y las redes sociales
Introducción
En apenas cinco meses habrá elecciones municipales y autonómicas en España. Los medios de comunicación y la forma de llegar al electorado ha cambiado mucho en la última década. La era de la información ya está presente en todos los hogares, y la sociedad ha abrazado el ciberespacio como el medio por el cual relacionarse, expresar sus opiniones, hacer negocios, buscar trabajo, divertirse, comprar, reservar las vacaciones, etc. La forma de hacer política también ha cambiado, especialmente en la forma de comunicarse con los posibles votantes.Medios tradicionales
La televisión, la radio, los diarios y los folletos buzoneados, son medios masivos que llegan fácilmente a muchos ciudadanos, y que se utilizan exclusivamente para informar. Es una comunicación débil, pues únicamente hay un emisor que fuerza el envío de información a un receptor. Es un medio frío, en el que hay que ser creativo para captar la atención del receptor para que se interese por el contenido. El porcentaje de interés suele ser bajo.Las mesas informativas y los mítines son medios que no llegan a tantos ciudadanos, pero tienen la ventaja de que los ciudadanos contactados ponen cara a sus políticos, pueden (o al menos deberían) poder hablar con ellos, dar opiniones, criticar, recibir el calor de un apretón de manos, de una mirada, captar la intensidad y la pasión del mensaje hablado... es un medio directo, muy humano, y las relaciones son mucho más efectivas. El porcentaje de interés es muy superior al de los medios citados en el párrafo anterior.
Internet no ha cambiado los medios de comunicación tradicionales, si no que ha hecho de pegamento entre la frialdad informativa y la calidez del contacto humano. Es un medio mucho más masivo que el de la prensa, pues no todo el mundo compra un diario, o escucha la radio, a menos que esté realmente interesado en ello. El ciudadano puede acceder a la información sin necesidad de un medio concreto, pues en Internet, la información es replicada en multitud de medios, estén o no asociados a un partido político, o estén o no asociados a un medio de comunicación concreto. La replicación de las noticias es algo sorprendente, y que funciona a modo de marketing viral. Lo más sorprendente, no es cómo una información se extiende exponencialmente, si no la facilidad de cómo los buscadores pueden llevarnos a dicha información.
Por un lado tenemos la facilidad de accesibilidad a la información, y por otro, y quizá el aspecto más importante de Internet, es que la comunicación puede establecerse en ambos sentidos, creando una relación entre el ciudadano y el político mucho más accesible que de forma presencial. En este aspecto, las redes sociales juegan un factor determinante en dicha relación, y un político debería tenerlo muy en cuenta.
¿Qué son las redes sociales?
Una red social es una herramienta o medio, a través del cual se facilita la posibilidad de que personas con intereses similares o comunes se conozcan y se relacionen. Existen redes sociales especializadas en alguna temática, como por ejemplo Xing o LinkeIn, que unen a personas con intereses empresariales o profesionales. Hay también redes científicas, médicas, educativas, informáticas, etc.Sin embargo, la red más famosa y popular de todos los tiempos es Facebook, con más de 500 millones de usuarios en todo el mundo. La principal característica de esta red es que permite comunicar a personas en cualquier parte del mundo, sobre cualquier interés, o sobre cualquier temática, además de incluir funcionalidades muy útiles y que veremos a continuación.
Antes de proseguir, debo decir que existen más redes sociales de propósito general, como Tuenti o MySpace, e incluso una nueva red social llamada Diaspora, que está basada 100% en software libre y en estándares abiertos. Pueden gustar más o menos, pero en política hay que ser prácticos, y llegar a la mayor cantidad posible de ciudadanos. Y Facebook es el medio más popular y extendido con gran diferencia. También se podría pensar en utilizar varias redes sociales. Es buena idea, pero, como veremos a continuación, las redes sociales, para un político, son un ladrón de tiempo muy importante, que requieren de dedicación y de esfuerzo. Hay que saber dosificar el tiempo útil y productivo en hacer política, y pensar en las redes sociales únicamente como un medio por el cual informar y capturar información.
Perfil
Al iniciar la andadura en una red social, hemos de pensar primero qué perfil crear. Un perfil será lo que el resto de usuarios de la red social verán de nosotros. Recomiendo, como prioridad principal, que el perfil sea del grupo político (comité local, amigos de...), y dar la oportunidad, a través de este medio, que otros compañeros participen y utilicen la red social para el bien común. Habrá quienes tengan un perfil personal, como persona, que quieran también usar la red social para medios políticos. En este sentido, mi recomendación es dar prioridad al perfil del grupo político, y usar el personal de forma independiente. Una opinión personal, por ejemplo, debería darse (normalmente) en el perfil personal, y no en el del grupo. Por otra parte, recomiendo que si se utiliza un perfil personal, utilizarlo única y exclusivamente para fines políticos. Aunque tengamos amigos del colegio, de la Universidad, del club de mus, o en cualquier otra afición, deberíamos dejar nuestros asuntos personales y nuestras aficiones al margen. Un político es una figura pública, y como tal, tendrá fans y detractores, y las cosas personales que se publiquen pueden determinar la simpatía o la antipatía de los electores, y podrían utilizarse para cualquier actividad de desprestigio y, cómo no, para arrancarnos votos.Una vez creado el perfil, es importante configurar la información inicial, tales como los intereses, quién puede dejarnos comentarios o las notificaciones que deseamos recibir. Si usamos Facebook, hay que tomar en cuenta este último punto, pues por defecto, recibiremos notificaciones para cualquier cosa, lo que puede llevar a desesperarnos de forma improductiva e innecesaria.
Una vez creado el perfil, podemos escribir algo en nuestro muro o en nuestro estado, un mensaje corto para presentarnos y dar la bienvenida a cualquier usuario que nos visite.
Crear relaciones
El siguiente paso obligado es encontrar amigos o personas, con el fin de crear lazos y compartir información. Lo más lógico sería pensar en buscar otros grupos o personas relacionados con nuestro partido político, y, a continuación, solicitar su amistad. Este paso no es obligatorio, ni tampoco ha de hacerse una vez y en este orden. En cualquier momento podemos buscar amigos y solicitar su amistad. Esta es la forma de crear la red.Generar y consumir información en la red social
¿Y cuál va a ser nuestro uso de la red social, además de encontrar y hacer amigos? Lo más importante es informar y recibir información. Pero, vayamos por partes.El muro o el estado nos permitirá escribir mensajes cortos, los cuales son visualizados en las sesiones de nuestros amigos, e indexados por los buscadores. Estos mensajes pueden ser noticias u opiniones propias. Una práctica muy habitual, es replicar noticias de otros medios, compartiendo enlaces. Lo normal es dar el título de la noticia, y a continuación pegar la URL (dirección Web) de la noticia. Esto tiene la ventaja de suscitar interés con el titular, de no saturar de texto, y que aquel que esté realmente interesado, hará clic en el enlace para leer el resto de la noticia.
Aquello que se escriba en el muro podrá ser igualmente replicado por otros amigos, creando la comunicación viral, pues los amigos de estos amigos, a su vez podrían nuevamente replicarlo, y así, sucesivamente.
La participación
Los mensajes en el muro también permiten comentarios, por lo que entramos en la parte más interesante y útil, ya que nos permite conocer otros puntos de vista, la aceptación del contenido publicado, la crítica, etc. Esto es retroalimentación de información, y es el poder más grande que tiene la Web 2.0: LA PARTICIPACION.Imaginemos que publicamos una idea, por ejemplo, un polideportivo de tales características en tal zona. Un ciudadano podría ver la idea, y opinar al respecto. Puede dar nuevas ideas con las que no contábamos y que pueden ser interesantes, o bien puede dar información que no teníamos (por ejemplo que donde se quiere construir el deportivo era antiguamente un acuífero con pozos), o bien criticar por razones que no dimos importancia o cualaquier otra opinión.
Las redes sociales, no nos equivoquemos, no son medios para lanzar únicamente nuestros mensajes, ideas o propuestas. Las redes son medios colaborativos, y nuestra colaboración también determina el grado de que los demás participen. Podemos recibir las opiniones de nuestros amigos, recibir recomendaciones de éstos o buscar información sobre algo específico. Nosotros también somos colaboradores. Podemos interesarnos, por ejemplo, sobre algún problema común con otro municipio, o una iniciativa de otro municipio en otra provincia y en otra comunidad autónoma. Hemos de dejar comentarios, dar nuestra opinión, recomendar, replicar, votar noticias o decir, simplemente, que nos gustan. Estas acciones son actividades que también dicen de nosotros, y el resto de colaboradores de la red lo apreciarán, y responderán hacia nosotros de la misma manera. Hay que cuidar mucho este detalle y no ser egoístas, interesados únicamente en dar publicidad de nosotros sin nada a cambio. ante todo PARTICIPACION Y COLABORACION.
En el caso de que nuestro partido político sea un partido nacional, es muy importante estar presente y dedicar esfuerzos en promocionar y publicitar las ideas del partido a nivel nacional o autonómico, no solamente de nuestro municipio. Estas referencias nos favorecerán mucho, pues damos una imagen de un grupo político que se preocupa y se implica por la ciudadanía en general y a todos los niveles, no únicamente en su municipio.
Contenidos multimedia
Un aspecto bastante importante es la posibilidad de publicar contenidos multimedia. Podemos crear galerías de fotos o de vídeos, de la temática que queramos. Por ejemplo, se pueden crear secciones de fotodenuncia, de monumentos del pueblo, de nuestras actividades (mesas informativas, mítines, visitas a colegios, etc). Al igual que comenté al principio, si usamos nuestro perfil personal, recomiendo no usar fotos personales, y, aún menos, en que aparezcan menores de edad (por razones legales y de falta de privacidad). No quedaría nada bien que publiquemos una foto o un vídeo en la que salgamos con ojos chisposos, descamisado y con una copa en la mano, en mitad de una boda o de una fiesta.Aplicaciones o utilidades
Otra de las características de las redes sociales son las aplicaciones. En el caso de Facebook, podemos encontrar algunas muy interesantes, como Twitter, donde podemos actualizar los contenidos de este medio en Facebook. Hay otras, como suscripciones a noticias RSS, o incluso juegos. Como recomendación personal, hay que dar una imagen política seria, práctica e íntegra. No hay que pecar de ser infantiles, y aún menos molestar al resto de amigos con aplicaciones del tipo "galleta de la suerte", "bolazos de nieve" y similares.Grupos
Otra posibilidad que ofrecen las redes sociales, es la suscripción a grupos de usuarios con algún interés común. Sería muy interesante, por imagen y seriedad, suscribirse a grupos que puedan suponer un peso político y social. Recomendaría, por ejemplo, suscribirse a un grupo o asociación de enfermos de tal o cual enfermedad que está en nuestra localidad, alguna ONG, etc. No recomiendo grupos lúdicos, de ocio o impopulares, y, aún menos, que sean de actualidad pero que no estén en comunión con las ideas generales del partido.Mensajes
Otra funcionalidad importante a tener en cuenta es la posibilidad de dejar mensajes, a modo de correo electrónico. Este medio, aunque primitivo, es el que más se utiliza para comentar cosas directamente a alguien sin que se haga público, como el muro o el estado. Además de privacidad, brinda la posibilidad de establecer una comunicación más estrecha entre ambos.Chat
Por último, comentaré una funcionalidad que poseen las redes sociales que no hemos de escatimar. Se trata la función de chat, que permite una comunicación directa y privada entre el político y el amigo (o ciudadano, o compañero, etc.), de forma instantánea. Gracias a esta herramienta podemos responder o aclarar cuestiones en el momento, con lo que la cercanía y la presencia se hacen más palpables. El problema que tiene esta funcionalidad es (al menos en mi caso) que suele entrar en acción cuando menos lo necesitas, es decir, por ejemplo, cuando estás trabajando o cuando necesitas tu concentración en otras cuestiones más importantes. No obstante, es un medio de comunicación bastante valioso.Reflexiones finales
Hay muchos ciudadanos que no tienen tiempo para ver la televisión, para escuchar la radio, o para leer el periódico; o bien tienen un horario que les impide acudir a un mítin o a una mesa informativa. La ventaja que tiene internet es que es descentralizado, es decir, que no se necesita estar presente ni tampoco estar en un momento dado. La comunicación entre ciudadano y político se produce sin barreras geográficas ni de tiempo.Hemos de ver las redes sociales como un medio de comunicación, pero también como una herramienta de trabajo excelente, que nos da la información (gracias a los ciudadanos) que necesitamos para saber qué, cómo, cuándo y por qué hemos de hacer las cosas. Si importante es informar, más importante es escuchar y, aún más importante, interactuar.
Las redes sociales serán muy importantes en la precampaña y, sobre todo, en la campaña electoral. Serán el medio por el cual nos comunicaremos, colaboraremos y conseguiremos relaciones con ciudadanos, compañeros de partido y amigos. El uso de las redes sociales nos harán ganar o perder votos, dependiendo del uso que les demos. Es muy importante estar presentes, existir e interactuar con nuestros ciudadanos a través de estos medios, informarles, aclararles dudas, recibir críticas y agradecer su colaboración.
Pero no hemos de estar presentes únicamente en momentos de elecciones. Hemos de ser accesibles en cualquier momento, en cualquier lugar y por cualquier razón. No hemos de desconectar con la realidad política y social, porque la realidad no desconecta nunca. Por tanto, tampoco nosotros.
jueves, 16 de diciembre de 2010
La necesidad de la Administración Electrónica y la transparencia administrativa
Nota: Este artículo es un poco extenso, pero interesante y ameno, pues capta los factores clave para el éxito de la implementación de la eAdministración
INTRODUCCION
A lo largo de la historia, la vida de los ciudadanos ha estado vinculada a la Administración Pública, donde la comunicación es la clave para que el ciudadano pudiera ejercer sus derechos y que los empleados públicos pudieran ejecutar los trámites con la mayor diligencia posible. Con el tiempo, las comunicaciones y las herramientas de comunicación y de trabajo han ido evolucionando. Se ha pasado de la obligada comunicación presencial, a la correspondencia postal, al teléfono, o, como hemos vivido en las últimas décadas, la telemática.
Conscientes de esta realidad y de los beneficios que la era informática y las comunicaciones por internet ofrecen, en el año 2007, concretamente el 22 de Junio, se aprobó la Ley 11/2007, de acceso electrónico de los ciudadanos a los Servicios Públicos (http://www.boe.es/aeboe/consultas/bases_datos/doc.php?id=BOE-A-2007-12352), con la finalidad de que todo ciudadano pudiera comunicarse con la Administración Pública “de acuerdo a los principios de eficacia, jerarquía, descentralización, desconcentración y coordinación”, según reza en los derechos de nuestra Constitución, concretamente en el Artículo 103 (http://noticias.juridicas.com/base_datos/Admin/constitucion.t4.html). Esta Ley supuso adecuar la realidad de las tecnologías de la información a la Administración Pública y al ciudadano.
VENTAJAS PARA EL CIUDADANO
Para entender un poco mejor ésto, sin sofisticadas fórmulas ni leyes. el ciudadano podrá ejercer su derecho de comunicación con la Administración Pública de forma no presencial a través de las tecnologías. Hoy en día, muchos ciudadanos se deplazan lejos para trabajar y/o los horarios no son compatibles con los horarios de la Administración. Realizar cualquier trámite administrativo de forma presencial puede suponerle la pérdida de uno o varios días a cuenta de días por asuntos personales o a cuenta de sus vacaciones. Otro ejemplo lo encontramos en ciudadanos que tienen una vivienda en otro municipio en otra provincia, y necesita pagar sus impuestos, o pagar multas, etc. También están los casos de ciudadanos impedidos físicamente, ya sea por una enfermedad o una invalidez. También están los casos de ciudadanos que están fuera del país por cualquier asunto (trabajo, viaje, compromisos personales, etc). Todos ellos pueden comunicarse con su Administración desde cualquier lugar (desde casa, desde el trabajo, desde un locutorio, etc.), y a cualquier hora, a través de las tecnologías, sin colas ni esperas. Es, pues, un sistema que funciona las 24 horas del día, todos los días del año, y desde cualquier lugar y medio (hay que tener en cuenta que el trabajo de los empleados públicos está regido por un calendario laboral y un horario, por lo que la gestión de los expedientes no cuenta. Cuenta la operativa de solicitudes y consultas).
Las tecnologías aportan canales de comunicación. El canal más extendido es el ordenador personal con conexión a internet. Otro canal podría ser un teléfono móvil, la TDT o cualquier otro que facilite esta comunicación. A efectos prácticos, el mejor canal para la introducción y aportación de datos es el ordenador, pues tiene un teclado cómodo, así como la posibilidad de conectar diversos periféricos (escáneres, cámaras, etc), para capturar documentos e imágenes que se pueden adjuntar a los expedientes administrativos. El resto de canales, debido a sus características (tamaño de pantalla, periféricos de entrada de datos, etc.), son menos utilizados, pero interesantes para comunicación de información (avisos, estados, ayuda...)
El ciudadano podrá recibir notificaciones a través de su correo electrónico o en su teléfono móvil, cada vez que el expediente cambie de estado. También puede consultarlo accediendo a la ventanilla virtual (o electrónica) de su Administración. Los documentos generados y adjuntados también son accesibles de forma electrónica. Todo ello da una trazabilidad detallada y transparente sobre la gestión de sus expedientes.
El ciudadano también puede pagar tasas, multas, impuestos, etc., mediante una pasarela de pago conectada a la entidad bancaria de la Administración. Este sistema de pago es el utilizado de forma universal en tiendas online, y el banco asociado es garante de su seguridad y de cualquier tipo de incidencia o delito que pudiera ocurrir.
VENTAJAS PARA LA ADMINISTRACION
Para la Administración, la eAdministración supone numerosas ventajas (sólo por citar algunas):
- Ofrecer un servicio desatendido. No es necesario atender a cada ciudadano presencialmente, explicando paso a paso los detalles del expediente. Esto supone un ahorro considerable de tiempo que se transforma en productividad.
- Mejora la eficiencia en la gestión del expediente y aporta transparencia sobre la misma. Los expedientes van pasando directa y automáticamente a los empleados que se encargarán de gestionarlos. La bandeja de tareas, además, aporta visión de los expedientes y de su estado, evitando olvidos accidentales. Cada proceso conlleva un estado visible y trazable para la Administración y para el ciudadano.
- La documentación, al ser electrónica y centralizada en un sistema informático, es más manejable y se evitan pérdidas de documentación.
- El sistema es flexible, pudiendo asignar y delegar tareas a otros empleados públicos, o incluso añadiendo anotaciones en los procesos.
- Si un ciudadano solicita el estado de un expediente, o una copia de un expediente ya antiguo, la búsqueda es instantánea, evitando la tediosa tarea de búsqueda en un archivo físico. La información está disponible en cualquier momento, y no es necesario buscarla en lugares físicos.
- Los expedientes y sus documentos, al estar en formato electrónico y al no ocupar espacio físico, se ahorra costes en infraestructuras y en logística, o se puede aprovechar para instalaciones de otro tipo.
- La documentación en formato electrónico se puede copiar muy fácil y rápidamente.
- La documentacion en formato electrónico supone un ahorro considerable en costes de papel. El papel es susceptible de destrucción en caso de incendio o de cualquier otra catástrofe. El ahorro en papel favorece el desarollo sostenible y la ecología.
- La documentación en formato electrónico, si se utiliza algún sistema de persistencia, de alta disponibilidad o de backups, en caso de que desastre en un servidor o en un cluster, estará a salvo y seguirá funcionando.
- Las gestión administrativa, a través de plataformas de Administración Electrónica, agilizan enormemente el tiempo y el trabajo de los empleados públicos, favoreciendo la eficacia y ahorrando tiempo y costes.
- La integración con otros sistemas internos agilizan y automatizan el trabajo. Por ejemplo, el pago de un impuesto puede conectar y actualizar automáticamente el sistema contable.
UN EJEMPLO PRACTICO
La Administración Electrónica no es un mero canal de comunicación, si no también un medio de trabajo para el empleado público, y un medio de trazabilidad de expedientes para el ciudadano. Para entender mejor ésto, voy a exponer un caso práctico, paso a paso. Aunque el escenario se refiere a la Administración Local (Ayuntamiento), se puede aplicar a cualquier tipo de Administración (Hacienda, Seguridad Social, etc).
Un ciudadano solicita un trámite administrativo, por ejemplo, un certificado de empadronamiento. Accede, mediante su ordenador e internet, a la página de su Ayuntamiento, y se dirige a la ventanilla (virtual). Esto lo puede hacer cualquier día, sea festivo o no, y a cualquier hora del día, incluso de noche. Desde la ventanilla podrá acceder a la lista de trámites administrativos disponibles por la Administración (certificado de empadronamiento, solicitud de placa de vado, pago de multas, pago del IBI, pago del impuesto de vehículos, licencia de obra menor, etc). Una vez selecciona su expediente, deberá identificarse para acreditar quién es. Lo más seguro es hacerlo mediante un certificado digital (puede hacerlo en nombre propio como persona jurídica, a través de su DNI electrónico, o bien, mediante un fichero encriptado y protegido, solicitado a la Casa de Moneda y Timbre u otra Administración, previa identificación acreditada y fehaciente). El expediente solicitará una serie de datos afines al mismo (medio de comunicación, motivo de la solicitud, etc). El expediente podrá presentar una ayuda sobre cómo completar la información, así como la documentación necesaria para ser adjuntada. Si es necesario, podrá adjuntar documentos que sean necesarios para el expediente (documento escaneado, una imagen, un documento en formato PDF o DOC, etc). Una vez que el ciudadano introduce la información, la valida y envía el expediente. Si el expediente tiene una tasa, le solicitará el medio de pago del mismo (PayPal o tarjeta de crédito). Recibirá una notificación del expediente con el registro de entrada y su firma digital (una firma digital es un código único, validado con un sellado de tiempo, asociado a un certificado digital y a un documento oficial, el cual genera automáticamente el sistema con el certificado digital del ciudadano (al enviar el expediente es como si firmara el mismo al entregarlo)). El pago de la tasa se realizará mediante una pasarela de pago segura, garantizada por una entidad bancaria. El ciudadano puede proseguir con su vida normal, mientras el expediente ya está en su Administración.
En el lado de la Administración (en este caso un Ayuntamiento), cuando el empleado municipal correspondiente a dicho expediente (en este caso de Estadística) accede a su puesto de trabajo, verá una lista de tareas pendientes, entre ellas el expediente solicitado por el ciudadano, con su correspondiente registro de entrada y su firma digital. Podrá abrir el expediente, revisarlo y validar la información y documentación aportados. Si los datos no son correctos o falta algún documento, podrá solicitar al ciudadano la rectificación o la documentación pendiente. Si los datos son correctos, puede añadir nueva documentación al expediente. En el proceso de tramitación, se puede generar un documento específico del expediente, el cual será el documento que finalmente se entregará al ciudadano una vez se procese. Finalizado su trabajo, si el expediente requiere la intervención de más empleados públicos para su gestión, firmará digitalmente su proceso, pasando el expediente al siguiente proceso que se asignará a la persona correspondiente. Cuando los procesos de tramitación del expediente terminan, pasará a los procesos de firma, asociados a los responsables correspondientes (Secretario, Concejal, Alcalde...). Estos responsables tendrán un portafolio de los expedientes terminados y pendientes de firma. Tras la revisión, el responsable correspondiente puede firmar los expedientes uno a uno o por lotes. Una vez firmado por todos los responsables, el expediente finaliza, obteniendo un registro de salida, y se mandará al ciudadano mediante los medios de comunicación que ha seleccionado. Cabe decir que, en cualquier proceso, el empleado público puede denegar el expediente, indicando las razones (en nuestro ejemplo, por ejemplo, que el solicitante no está censado en el municipio). También puede solicitar en un determinado proceso el pago de alguna tasa, cuya petición se notificará al ciudadano para que se haga efectiva.
El ciudadano, por su parte, puede recibir notificaciones en su correo electrónico o en su teléfono móvil vía SMS cada vez que el expediente cambia de estado o de proceso. También puede acceder a la ventanilla virtual para consultar el estado de su expediente. Puede ver las notificaciones de cada proceso, conociendo cuándo ha pasado por dicho proceso (fecha y hora), y qué empleado público o responsable lo ha validado. También puede conocer las peticiones, por parte de la Administración, para que aporte documentación pendiente, cosa que podrá realizar y enviar de la misma forma que vimos cuando solicitaba el expediente. También puede recibir requerimientos de pago de tasas, que realizará como se explicó anteriormente. Si el expediente fue rechazado, conocerá quién lo rechazó, cuando y por qué. Si el expediente se completó, obtendrá el documento del expediente final, junto a la documentación generada y adjunta, así como las firmas digitales de los responsables y el registro de salida de dicho expediente.
ADMINISTRACION TRADICIONAL
La Administración tradicional no desaparece, si no que se complementa con la Administración Electrónica. Es lógico pensar – por ejemplo - que en estos inicios, las personas mayores, y especialmente en pueblos pequeños con poco calado tecnológico, prefieran que se lo hagan desde el Ayuntamiento. El ciudadano acudirá presencialmente, como siempre lo ha hecho, y solicitará el expediente. El empleado público accederá, desde su ordenador, a la página del Ayuntamiento y a la ventanilla, exactamente igual a como lo haría el propio ciudadano en modo online. El ordenador de la Administración tendrá conectado un lector de DNI electrónico, por lo que al solicitar la identificación, se le pedirá al ciudadano que introduzca su DNI en el lector, y, a continuación introduzca su PIN. Puede ocurrir que el ciudadano no tenga aún un DNI electrónico, o no recuerde su PIN. Esto se puede salvar adjuntando al expediente una imagen escaneada del DNI o del pasaporte del ciudadano. A partir de ahí, el empleado público solicitará los datos al ciudadano, y los irá completando en el expediente vía ordenador. El proceso sería el mismo que el que tendría el ciudadano en modo online. Una vez finalizado, se le mostrará al ciudadano el expediente antes de ser enviado, para que valide los datos que ha dado. Si es correcto, se enviará, generando la firma digital y el correspondiente registro de entrada. El documento de entrada será impreso y entregado al ciudadano, mientras que aparecerá este nuevo expediente en la bandeja de tareas del empleado correspondiente de atender el expediente.
Mediante este método no hay incongruencias en los registros de entrada de los expedientes solicitados vía online y los solicitados vía presencial.
DIFICULTADES Y PROBLEMAS PARA HACER REALIDAD LA eADMINISTRACION
Todo lo dicho anteriormente parece idílico, y así debería ser. Pero la realidad es muy diferente y no tan halagüeña. Os contaré mi experiencia.
Trabajé durante más de año y medio en el proyecto Municip@, de la Comunidad de Madrid, como Director de Provisión, como coordinador entre los equipos técnicos, soporte y comercial, poniendo en marcha el servicio para casi 130 ayuntamientos. También fui interlocutor entre los Ayuntamientos, la Comunidad de Madrid y la empresa adjudicataria del proyecto. Debo reconocer que la Comunidad de Madrid hizo aquí un esfuerzo muy grande, tanto en lo económico, como en medios, como en recursos y personas, para subvencionar a los ayuntamientos de menos de 20 mil habitantes (con alguna excepción), creando un servicio modélico y referente de Administración Electrónica.
Los problemas que encontré fueron muchos, y no tenían que ver directamente con problemas técnicos, si no más bien del día a día. Estos problemas se encontrarán en cualquier sistema de eAdministración, muchos de ellos inevitables, algunos asumibles y solventables. Por ejemplo, en ayuntamiento pequeños, además de la poca preparación informática de los empleados públicos, aún en el mejor de los casos de que puedan aprender (con mucho esfuerzo para su capacitación, aún siendo unos sistemas informáticos muy sencillos), estaba el tiempo material que necesitaban, pues eran muy pocos y tenían una gran carga de trabajo. La capacitación para adoptarlo era/es un coste muy importante. Otro, era que nuestra eAdministración estaba diseñada para integrarse con sistemas propios de la Comunidad de Madrid, y algunos ayuntamientos tenían otros sistemas, de otros proveedores, por lo que no podían integrarse, por ejemplo, para generar registros en entrada y salida, o para actualizar datos de otros sistemas de forma automática. Otro problema era la infraestructura de ordenadores que tenían (no entraban dentro de la subvención), que era antigua y había que actualizar el parque informático, cosa para la que muchos ayuntamientos no tenían presupuesto. Otro problema era que había que tener encendidos los ordenadores de algunos sistemas (como el del registro de entrada y salida, o el de estadística) las 24 horas del día, cosa que repercutía en el incremento de consumo de energía (con el consiguiente incumplimiento de la Agenda 21 y el desarrollo sostenible). Otro problema importante era la escasa infraestructura y la escasa calidad de las comunicaciones ADSL en pueblos muy retirados y pequeños, en las sierras de la Comunidad. Además de lentitud, había cortes. Además en días de mal tiempo, con tormentas (cosa frecuente), tanto la electricidad como las comunicaciones, se veían interrumpidas y en ocasiones con efecto racimo, dependiendo de si ese pueblo era nodo de distribución. La interrupción de estos servicios afectaba directamente a la disponibilidad del sistema para que pudiera ser usado por los ciudadanos.
Por último, para cerrar esta sección, diré que la ventanilla única es aún una utopía, pues ya partimos de que hay diversos sistemas de eAdministración no estandarizados, y que no comparten muchas (a veces ninguna) funcionalidades, incluso entre Administraciones del mismo nivel. No digo nada entre Administraciones distintas.
¿COMO ABORDAR LA eADMINISTRACION?
El principal problema que veo es el ocultismo comercial de los productos. Cada fabricante de software mira por su exclusividad, vendiendo productos muy buenos, pero cerrados herméticamente, tanto a nivel de licencias, de código, a nivel de formación, de soporte, de mantenimiento o de mejora. No se abren a otros productos. No se estandarizan. No se integran. Quieren tener la exclusividad de todo.
Por ello, el primer punto para llegar a una eAdministración real, coherente, de sentido común y para todos los ciudadanos y empresas que quieran colaborar, es que sea software libre, cuyo código y especificaciones estén a disposición de todos, que puedan estudiarse, y que todos puedan participar para mejorar y evolucionar el producto. No hablo de quimeras. Hablo de una realidad necesaria.
Un producto bajo software libre, creado por una empresa, tendrá el conocimiento más especializado sobre el mismo, por lo que la mayor parte de los contratos de soporte y mantenimiento los tiene casi asegurados. Creando una comunidad en torno a dicho producto, permite que otros entusiastas, sin ánimo de lucro, colaboren en hacer evolucionar y mejorar el producto, sin costes ni nóminas. Eso repercute en el enriquecimiento del producto y de la propia empresa, que ve cómo el producto es mejor y más adoptado por más Administraciones (lo que se traduce en más contratos y más negocio). La participación de desarrolladores altruistas, además, permiten crear documentación, crear foros, resolver dudas, explicar casos, crear parches, etc. Al ser abierto, otros productos podrían crear integraciones con este producto y viceversa. Se resolvería el problema de las incompatibilidades, y se comenzaría a caminar hacia una verdadera integración entre distintas Administraciones, alcanzando, poco a poco, la realidad de la ventanilla única.
Indpendientemente de los beneficios que supondría que los productos de eAdministración fueran libres y abiertos, para la Administración supondría un ahorro de costes inmenso, además de reforzar la confianza en un producto que es transparente y que no oculta puertas traseras, spyware y similares. También daría libertad para que si un día la relación con el proveedor de servicio se rompe, otro proveedor pueda seguir prestando el servicio con el mismo producto. Otra ventaja sería que, si en el caso de que el fabricante quebrara o se disolviera por cualquier razón, la comunidad podría continuar desarrollando y manteniendo el producto.
Por último, daré unos consejos más técnicos y estratégicos sobre mi visión de una eAdministración real.
- Desarrollado bajo estándares probados y populares de código abierto, con una gran comunidad por detrás.
- Las tecnologías y los lenguajes de programación utilizados deberían estar en el TOP 15 mundial, a fin de asegurar el no uso de tecnologías místicas, y que puedan ser abordadas por casi cualquier desarrollador con costes aceptables.
- No usar excesivos frameworks a modo de capas de cebolla. Se deberían analizar realmente las necesidades y el rendimiento, simplificando al máximo su arquitectura, evitando el consumo innecesario de recursos, lo que se traduce en tiempos de respuesta mejores, menos tráfico, más ahorro de energía y más ahorro de recursos físicos (memoria y disco).
- Uso de tecnologías estándar de comunicaciones, como SOAP o REST, bajo conexiones seguras estándar, como OpenSSL
- Uso de bases de datos realmente escalables, tanto horizontal como verticalmente, así como también que tengan un altísima disponibilidad. Ante estas necesidades, bases de datos de tipo NoSQL serían una buena opción. En el caso de los documentos, por su estructura, MongoDB, RavenDB o CouchDB serían idóneas. Si el tipo de expedientes es más estadístico u organizado, Cassandra sería una buena opción. Es una recomendación personal.
- Sólo recomendaría la computación en nube en el caso de que las infraestructuras sean de la Administración, no de un proveedor externo, como una empresa, ya que si no, se pierde el control de los datos, aunque se firmen contratos LOPD. Sería bueno, por ejemplo, para la reducción de costes en caso de mancomunidades entre varios Ayuntamientos, o en el caso de que una Administración de jerarquía superior, financie y de el servicio a las Administraciones de jerarquía inferior, de la cual dependen.
- La dotación y la mejora de infraestructuras (líneas telefónicas, ADSL, electricidad, etc) es un punto clave para que tenga éxito. Hasta entonces, una opción podría ser compartir el servicio en una mancomunidad de municipios, alojándolos en aquel con mayores garantías de disponibilidad (en el caso de las Administraciones Locales).
- Esfuerzo inicial de formación y capacitación para los empleados públicos. Un portal de conocimiento sería interesante para alimentar documentación, experiencias, FAQs, etc.
- Dotación de ordenadores básicos necesarios para las distintas Administraciones. Este sería un esfuerzo económico muy importante, pero si no se invierte en este sentido, muchas Administraciones no lo adoptarían.
- Conseguir acuerdos con entidades de las cuales dependen servicios externos, tales como pasarelas de pago, firma electrónica, sellado de tiempo, etc., para conseguir descuentos y subvenciones en los costes.
- Enfocado a uso en diferentes plataformas, no únicamente en Windows. El uso de herramientas Office para el ciudadano o para el empleado público, debería comprender Microsoft Office, LibreOffice, OpenOffice, AbiWord, etc.
- Enfocado a diferentes navegadores: Internet Explorer, Firefox, Chrome, Safari, Opera, etc.
- Uso de interfaces ricas de usuario estándar, sin necesidad de plugins. La tecnología Flash puede ser muy buena, pero no es una tecnología nativa del navegador, y no todos los navegadores cuentan con un plugin de Flash.
- Interfaces pensadas para la accesibilidad de personas con minusvalías.
- Buscar siempre la forma más sencilla, corta e interactiva posible en la experiencia de usuario, tanto para el ciudadano como para el empleado público.
- Dirigido (las funcionalidades que se puedan de forma eficiente), a todos los canales tecnológicos posibles: ordenadores, tablets, teléfonos móviles 2G y 3G, TDT, Call Center, eTV, etc.
INTRODUCCION
A lo largo de la historia, la vida de los ciudadanos ha estado vinculada a la Administración Pública, donde la comunicación es la clave para que el ciudadano pudiera ejercer sus derechos y que los empleados públicos pudieran ejecutar los trámites con la mayor diligencia posible. Con el tiempo, las comunicaciones y las herramientas de comunicación y de trabajo han ido evolucionando. Se ha pasado de la obligada comunicación presencial, a la correspondencia postal, al teléfono, o, como hemos vivido en las últimas décadas, la telemática.
Conscientes de esta realidad y de los beneficios que la era informática y las comunicaciones por internet ofrecen, en el año 2007, concretamente el 22 de Junio, se aprobó la Ley 11/2007, de acceso electrónico de los ciudadanos a los Servicios Públicos (http://www.boe.es/aeboe/consultas/bases_datos/doc.php?id=BOE-A-2007-12352), con la finalidad de que todo ciudadano pudiera comunicarse con la Administración Pública “de acuerdo a los principios de eficacia, jerarquía, descentralización, desconcentración y coordinación”, según reza en los derechos de nuestra Constitución, concretamente en el Artículo 103 (http://noticias.juridicas.com/base_datos/Admin/constitucion.t4.html). Esta Ley supuso adecuar la realidad de las tecnologías de la información a la Administración Pública y al ciudadano.
VENTAJAS PARA EL CIUDADANO
Para entender un poco mejor ésto, sin sofisticadas fórmulas ni leyes. el ciudadano podrá ejercer su derecho de comunicación con la Administración Pública de forma no presencial a través de las tecnologías. Hoy en día, muchos ciudadanos se deplazan lejos para trabajar y/o los horarios no son compatibles con los horarios de la Administración. Realizar cualquier trámite administrativo de forma presencial puede suponerle la pérdida de uno o varios días a cuenta de días por asuntos personales o a cuenta de sus vacaciones. Otro ejemplo lo encontramos en ciudadanos que tienen una vivienda en otro municipio en otra provincia, y necesita pagar sus impuestos, o pagar multas, etc. También están los casos de ciudadanos impedidos físicamente, ya sea por una enfermedad o una invalidez. También están los casos de ciudadanos que están fuera del país por cualquier asunto (trabajo, viaje, compromisos personales, etc). Todos ellos pueden comunicarse con su Administración desde cualquier lugar (desde casa, desde el trabajo, desde un locutorio, etc.), y a cualquier hora, a través de las tecnologías, sin colas ni esperas. Es, pues, un sistema que funciona las 24 horas del día, todos los días del año, y desde cualquier lugar y medio (hay que tener en cuenta que el trabajo de los empleados públicos está regido por un calendario laboral y un horario, por lo que la gestión de los expedientes no cuenta. Cuenta la operativa de solicitudes y consultas).
Las tecnologías aportan canales de comunicación. El canal más extendido es el ordenador personal con conexión a internet. Otro canal podría ser un teléfono móvil, la TDT o cualquier otro que facilite esta comunicación. A efectos prácticos, el mejor canal para la introducción y aportación de datos es el ordenador, pues tiene un teclado cómodo, así como la posibilidad de conectar diversos periféricos (escáneres, cámaras, etc), para capturar documentos e imágenes que se pueden adjuntar a los expedientes administrativos. El resto de canales, debido a sus características (tamaño de pantalla, periféricos de entrada de datos, etc.), son menos utilizados, pero interesantes para comunicación de información (avisos, estados, ayuda...)
El ciudadano podrá recibir notificaciones a través de su correo electrónico o en su teléfono móvil, cada vez que el expediente cambie de estado. También puede consultarlo accediendo a la ventanilla virtual (o electrónica) de su Administración. Los documentos generados y adjuntados también son accesibles de forma electrónica. Todo ello da una trazabilidad detallada y transparente sobre la gestión de sus expedientes.
El ciudadano también puede pagar tasas, multas, impuestos, etc., mediante una pasarela de pago conectada a la entidad bancaria de la Administración. Este sistema de pago es el utilizado de forma universal en tiendas online, y el banco asociado es garante de su seguridad y de cualquier tipo de incidencia o delito que pudiera ocurrir.
VENTAJAS PARA LA ADMINISTRACION
Para la Administración, la eAdministración supone numerosas ventajas (sólo por citar algunas):
- Ofrecer un servicio desatendido. No es necesario atender a cada ciudadano presencialmente, explicando paso a paso los detalles del expediente. Esto supone un ahorro considerable de tiempo que se transforma en productividad.
- Mejora la eficiencia en la gestión del expediente y aporta transparencia sobre la misma. Los expedientes van pasando directa y automáticamente a los empleados que se encargarán de gestionarlos. La bandeja de tareas, además, aporta visión de los expedientes y de su estado, evitando olvidos accidentales. Cada proceso conlleva un estado visible y trazable para la Administración y para el ciudadano.
- La documentación, al ser electrónica y centralizada en un sistema informático, es más manejable y se evitan pérdidas de documentación.
- El sistema es flexible, pudiendo asignar y delegar tareas a otros empleados públicos, o incluso añadiendo anotaciones en los procesos.
- Si un ciudadano solicita el estado de un expediente, o una copia de un expediente ya antiguo, la búsqueda es instantánea, evitando la tediosa tarea de búsqueda en un archivo físico. La información está disponible en cualquier momento, y no es necesario buscarla en lugares físicos.
- Los expedientes y sus documentos, al estar en formato electrónico y al no ocupar espacio físico, se ahorra costes en infraestructuras y en logística, o se puede aprovechar para instalaciones de otro tipo.
- La documentación en formato electrónico se puede copiar muy fácil y rápidamente.
- La documentacion en formato electrónico supone un ahorro considerable en costes de papel. El papel es susceptible de destrucción en caso de incendio o de cualquier otra catástrofe. El ahorro en papel favorece el desarollo sostenible y la ecología.
- La documentación en formato electrónico, si se utiliza algún sistema de persistencia, de alta disponibilidad o de backups, en caso de que desastre en un servidor o en un cluster, estará a salvo y seguirá funcionando.
- Las gestión administrativa, a través de plataformas de Administración Electrónica, agilizan enormemente el tiempo y el trabajo de los empleados públicos, favoreciendo la eficacia y ahorrando tiempo y costes.
- La integración con otros sistemas internos agilizan y automatizan el trabajo. Por ejemplo, el pago de un impuesto puede conectar y actualizar automáticamente el sistema contable.
UN EJEMPLO PRACTICO
La Administración Electrónica no es un mero canal de comunicación, si no también un medio de trabajo para el empleado público, y un medio de trazabilidad de expedientes para el ciudadano. Para entender mejor ésto, voy a exponer un caso práctico, paso a paso. Aunque el escenario se refiere a la Administración Local (Ayuntamiento), se puede aplicar a cualquier tipo de Administración (Hacienda, Seguridad Social, etc).
Un ciudadano solicita un trámite administrativo, por ejemplo, un certificado de empadronamiento. Accede, mediante su ordenador e internet, a la página de su Ayuntamiento, y se dirige a la ventanilla (virtual). Esto lo puede hacer cualquier día, sea festivo o no, y a cualquier hora del día, incluso de noche. Desde la ventanilla podrá acceder a la lista de trámites administrativos disponibles por la Administración (certificado de empadronamiento, solicitud de placa de vado, pago de multas, pago del IBI, pago del impuesto de vehículos, licencia de obra menor, etc). Una vez selecciona su expediente, deberá identificarse para acreditar quién es. Lo más seguro es hacerlo mediante un certificado digital (puede hacerlo en nombre propio como persona jurídica, a través de su DNI electrónico, o bien, mediante un fichero encriptado y protegido, solicitado a la Casa de Moneda y Timbre u otra Administración, previa identificación acreditada y fehaciente). El expediente solicitará una serie de datos afines al mismo (medio de comunicación, motivo de la solicitud, etc). El expediente podrá presentar una ayuda sobre cómo completar la información, así como la documentación necesaria para ser adjuntada. Si es necesario, podrá adjuntar documentos que sean necesarios para el expediente (documento escaneado, una imagen, un documento en formato PDF o DOC, etc). Una vez que el ciudadano introduce la información, la valida y envía el expediente. Si el expediente tiene una tasa, le solicitará el medio de pago del mismo (PayPal o tarjeta de crédito). Recibirá una notificación del expediente con el registro de entrada y su firma digital (una firma digital es un código único, validado con un sellado de tiempo, asociado a un certificado digital y a un documento oficial, el cual genera automáticamente el sistema con el certificado digital del ciudadano (al enviar el expediente es como si firmara el mismo al entregarlo)). El pago de la tasa se realizará mediante una pasarela de pago segura, garantizada por una entidad bancaria. El ciudadano puede proseguir con su vida normal, mientras el expediente ya está en su Administración.
En el lado de la Administración (en este caso un Ayuntamiento), cuando el empleado municipal correspondiente a dicho expediente (en este caso de Estadística) accede a su puesto de trabajo, verá una lista de tareas pendientes, entre ellas el expediente solicitado por el ciudadano, con su correspondiente registro de entrada y su firma digital. Podrá abrir el expediente, revisarlo y validar la información y documentación aportados. Si los datos no son correctos o falta algún documento, podrá solicitar al ciudadano la rectificación o la documentación pendiente. Si los datos son correctos, puede añadir nueva documentación al expediente. En el proceso de tramitación, se puede generar un documento específico del expediente, el cual será el documento que finalmente se entregará al ciudadano una vez se procese. Finalizado su trabajo, si el expediente requiere la intervención de más empleados públicos para su gestión, firmará digitalmente su proceso, pasando el expediente al siguiente proceso que se asignará a la persona correspondiente. Cuando los procesos de tramitación del expediente terminan, pasará a los procesos de firma, asociados a los responsables correspondientes (Secretario, Concejal, Alcalde...). Estos responsables tendrán un portafolio de los expedientes terminados y pendientes de firma. Tras la revisión, el responsable correspondiente puede firmar los expedientes uno a uno o por lotes. Una vez firmado por todos los responsables, el expediente finaliza, obteniendo un registro de salida, y se mandará al ciudadano mediante los medios de comunicación que ha seleccionado. Cabe decir que, en cualquier proceso, el empleado público puede denegar el expediente, indicando las razones (en nuestro ejemplo, por ejemplo, que el solicitante no está censado en el municipio). También puede solicitar en un determinado proceso el pago de alguna tasa, cuya petición se notificará al ciudadano para que se haga efectiva.
El ciudadano, por su parte, puede recibir notificaciones en su correo electrónico o en su teléfono móvil vía SMS cada vez que el expediente cambia de estado o de proceso. También puede acceder a la ventanilla virtual para consultar el estado de su expediente. Puede ver las notificaciones de cada proceso, conociendo cuándo ha pasado por dicho proceso (fecha y hora), y qué empleado público o responsable lo ha validado. También puede conocer las peticiones, por parte de la Administración, para que aporte documentación pendiente, cosa que podrá realizar y enviar de la misma forma que vimos cuando solicitaba el expediente. También puede recibir requerimientos de pago de tasas, que realizará como se explicó anteriormente. Si el expediente fue rechazado, conocerá quién lo rechazó, cuando y por qué. Si el expediente se completó, obtendrá el documento del expediente final, junto a la documentación generada y adjunta, así como las firmas digitales de los responsables y el registro de salida de dicho expediente.
ADMINISTRACION TRADICIONAL
La Administración tradicional no desaparece, si no que se complementa con la Administración Electrónica. Es lógico pensar – por ejemplo - que en estos inicios, las personas mayores, y especialmente en pueblos pequeños con poco calado tecnológico, prefieran que se lo hagan desde el Ayuntamiento. El ciudadano acudirá presencialmente, como siempre lo ha hecho, y solicitará el expediente. El empleado público accederá, desde su ordenador, a la página del Ayuntamiento y a la ventanilla, exactamente igual a como lo haría el propio ciudadano en modo online. El ordenador de la Administración tendrá conectado un lector de DNI electrónico, por lo que al solicitar la identificación, se le pedirá al ciudadano que introduzca su DNI en el lector, y, a continuación introduzca su PIN. Puede ocurrir que el ciudadano no tenga aún un DNI electrónico, o no recuerde su PIN. Esto se puede salvar adjuntando al expediente una imagen escaneada del DNI o del pasaporte del ciudadano. A partir de ahí, el empleado público solicitará los datos al ciudadano, y los irá completando en el expediente vía ordenador. El proceso sería el mismo que el que tendría el ciudadano en modo online. Una vez finalizado, se le mostrará al ciudadano el expediente antes de ser enviado, para que valide los datos que ha dado. Si es correcto, se enviará, generando la firma digital y el correspondiente registro de entrada. El documento de entrada será impreso y entregado al ciudadano, mientras que aparecerá este nuevo expediente en la bandeja de tareas del empleado correspondiente de atender el expediente.
Mediante este método no hay incongruencias en los registros de entrada de los expedientes solicitados vía online y los solicitados vía presencial.
DIFICULTADES Y PROBLEMAS PARA HACER REALIDAD LA eADMINISTRACION
Todo lo dicho anteriormente parece idílico, y así debería ser. Pero la realidad es muy diferente y no tan halagüeña. Os contaré mi experiencia.
Trabajé durante más de año y medio en el proyecto Municip@, de la Comunidad de Madrid, como Director de Provisión, como coordinador entre los equipos técnicos, soporte y comercial, poniendo en marcha el servicio para casi 130 ayuntamientos. También fui interlocutor entre los Ayuntamientos, la Comunidad de Madrid y la empresa adjudicataria del proyecto. Debo reconocer que la Comunidad de Madrid hizo aquí un esfuerzo muy grande, tanto en lo económico, como en medios, como en recursos y personas, para subvencionar a los ayuntamientos de menos de 20 mil habitantes (con alguna excepción), creando un servicio modélico y referente de Administración Electrónica.
Los problemas que encontré fueron muchos, y no tenían que ver directamente con problemas técnicos, si no más bien del día a día. Estos problemas se encontrarán en cualquier sistema de eAdministración, muchos de ellos inevitables, algunos asumibles y solventables. Por ejemplo, en ayuntamiento pequeños, además de la poca preparación informática de los empleados públicos, aún en el mejor de los casos de que puedan aprender (con mucho esfuerzo para su capacitación, aún siendo unos sistemas informáticos muy sencillos), estaba el tiempo material que necesitaban, pues eran muy pocos y tenían una gran carga de trabajo. La capacitación para adoptarlo era/es un coste muy importante. Otro, era que nuestra eAdministración estaba diseñada para integrarse con sistemas propios de la Comunidad de Madrid, y algunos ayuntamientos tenían otros sistemas, de otros proveedores, por lo que no podían integrarse, por ejemplo, para generar registros en entrada y salida, o para actualizar datos de otros sistemas de forma automática. Otro problema era la infraestructura de ordenadores que tenían (no entraban dentro de la subvención), que era antigua y había que actualizar el parque informático, cosa para la que muchos ayuntamientos no tenían presupuesto. Otro problema era que había que tener encendidos los ordenadores de algunos sistemas (como el del registro de entrada y salida, o el de estadística) las 24 horas del día, cosa que repercutía en el incremento de consumo de energía (con el consiguiente incumplimiento de la Agenda 21 y el desarrollo sostenible). Otro problema importante era la escasa infraestructura y la escasa calidad de las comunicaciones ADSL en pueblos muy retirados y pequeños, en las sierras de la Comunidad. Además de lentitud, había cortes. Además en días de mal tiempo, con tormentas (cosa frecuente), tanto la electricidad como las comunicaciones, se veían interrumpidas y en ocasiones con efecto racimo, dependiendo de si ese pueblo era nodo de distribución. La interrupción de estos servicios afectaba directamente a la disponibilidad del sistema para que pudiera ser usado por los ciudadanos.
Por último, para cerrar esta sección, diré que la ventanilla única es aún una utopía, pues ya partimos de que hay diversos sistemas de eAdministración no estandarizados, y que no comparten muchas (a veces ninguna) funcionalidades, incluso entre Administraciones del mismo nivel. No digo nada entre Administraciones distintas.
¿COMO ABORDAR LA eADMINISTRACION?
El principal problema que veo es el ocultismo comercial de los productos. Cada fabricante de software mira por su exclusividad, vendiendo productos muy buenos, pero cerrados herméticamente, tanto a nivel de licencias, de código, a nivel de formación, de soporte, de mantenimiento o de mejora. No se abren a otros productos. No se estandarizan. No se integran. Quieren tener la exclusividad de todo.
Por ello, el primer punto para llegar a una eAdministración real, coherente, de sentido común y para todos los ciudadanos y empresas que quieran colaborar, es que sea software libre, cuyo código y especificaciones estén a disposición de todos, que puedan estudiarse, y que todos puedan participar para mejorar y evolucionar el producto. No hablo de quimeras. Hablo de una realidad necesaria.
Un producto bajo software libre, creado por una empresa, tendrá el conocimiento más especializado sobre el mismo, por lo que la mayor parte de los contratos de soporte y mantenimiento los tiene casi asegurados. Creando una comunidad en torno a dicho producto, permite que otros entusiastas, sin ánimo de lucro, colaboren en hacer evolucionar y mejorar el producto, sin costes ni nóminas. Eso repercute en el enriquecimiento del producto y de la propia empresa, que ve cómo el producto es mejor y más adoptado por más Administraciones (lo que se traduce en más contratos y más negocio). La participación de desarrolladores altruistas, además, permiten crear documentación, crear foros, resolver dudas, explicar casos, crear parches, etc. Al ser abierto, otros productos podrían crear integraciones con este producto y viceversa. Se resolvería el problema de las incompatibilidades, y se comenzaría a caminar hacia una verdadera integración entre distintas Administraciones, alcanzando, poco a poco, la realidad de la ventanilla única.
Indpendientemente de los beneficios que supondría que los productos de eAdministración fueran libres y abiertos, para la Administración supondría un ahorro de costes inmenso, además de reforzar la confianza en un producto que es transparente y que no oculta puertas traseras, spyware y similares. También daría libertad para que si un día la relación con el proveedor de servicio se rompe, otro proveedor pueda seguir prestando el servicio con el mismo producto. Otra ventaja sería que, si en el caso de que el fabricante quebrara o se disolviera por cualquier razón, la comunidad podría continuar desarrollando y manteniendo el producto.
Por último, daré unos consejos más técnicos y estratégicos sobre mi visión de una eAdministración real.
- Desarrollado bajo estándares probados y populares de código abierto, con una gran comunidad por detrás.
- Las tecnologías y los lenguajes de programación utilizados deberían estar en el TOP 15 mundial, a fin de asegurar el no uso de tecnologías místicas, y que puedan ser abordadas por casi cualquier desarrollador con costes aceptables.
- No usar excesivos frameworks a modo de capas de cebolla. Se deberían analizar realmente las necesidades y el rendimiento, simplificando al máximo su arquitectura, evitando el consumo innecesario de recursos, lo que se traduce en tiempos de respuesta mejores, menos tráfico, más ahorro de energía y más ahorro de recursos físicos (memoria y disco).
- Uso de tecnologías estándar de comunicaciones, como SOAP o REST, bajo conexiones seguras estándar, como OpenSSL
- Uso de bases de datos realmente escalables, tanto horizontal como verticalmente, así como también que tengan un altísima disponibilidad. Ante estas necesidades, bases de datos de tipo NoSQL serían una buena opción. En el caso de los documentos, por su estructura, MongoDB, RavenDB o CouchDB serían idóneas. Si el tipo de expedientes es más estadístico u organizado, Cassandra sería una buena opción. Es una recomendación personal.
- Sólo recomendaría la computación en nube en el caso de que las infraestructuras sean de la Administración, no de un proveedor externo, como una empresa, ya que si no, se pierde el control de los datos, aunque se firmen contratos LOPD. Sería bueno, por ejemplo, para la reducción de costes en caso de mancomunidades entre varios Ayuntamientos, o en el caso de que una Administración de jerarquía superior, financie y de el servicio a las Administraciones de jerarquía inferior, de la cual dependen.
- La dotación y la mejora de infraestructuras (líneas telefónicas, ADSL, electricidad, etc) es un punto clave para que tenga éxito. Hasta entonces, una opción podría ser compartir el servicio en una mancomunidad de municipios, alojándolos en aquel con mayores garantías de disponibilidad (en el caso de las Administraciones Locales).
- Esfuerzo inicial de formación y capacitación para los empleados públicos. Un portal de conocimiento sería interesante para alimentar documentación, experiencias, FAQs, etc.
- Dotación de ordenadores básicos necesarios para las distintas Administraciones. Este sería un esfuerzo económico muy importante, pero si no se invierte en este sentido, muchas Administraciones no lo adoptarían.
- Conseguir acuerdos con entidades de las cuales dependen servicios externos, tales como pasarelas de pago, firma electrónica, sellado de tiempo, etc., para conseguir descuentos y subvenciones en los costes.
- Enfocado a uso en diferentes plataformas, no únicamente en Windows. El uso de herramientas Office para el ciudadano o para el empleado público, debería comprender Microsoft Office, LibreOffice, OpenOffice, AbiWord, etc.
- Enfocado a diferentes navegadores: Internet Explorer, Firefox, Chrome, Safari, Opera, etc.
- Uso de interfaces ricas de usuario estándar, sin necesidad de plugins. La tecnología Flash puede ser muy buena, pero no es una tecnología nativa del navegador, y no todos los navegadores cuentan con un plugin de Flash.
- Interfaces pensadas para la accesibilidad de personas con minusvalías.
- Buscar siempre la forma más sencilla, corta e interactiva posible en la experiencia de usuario, tanto para el ciudadano como para el empleado público.
- Dirigido (las funcionalidades que se puedan de forma eficiente), a todos los canales tecnológicos posibles: ordenadores, tablets, teléfonos móviles 2G y 3G, TDT, Call Center, eTV, etc.
miércoles, 15 de diciembre de 2010
La frase
La computación en nube es peor que la estupidez, ya que es una pérdida del control de los datos.
Richard Stallman
Richard Stallman
miércoles, 1 de diciembre de 2010
martes, 30 de noviembre de 2010
De huevos, gallinas y propietarios con miopía
Me gustaría compartir con vosotros, una parábola muy bien redactada y enfocada por Michel Henric-Coll, creador de Fractal Teams. (Fuente: http://blog.fractalteams.com/?p=299) ¿A alguno le resulta familiar?
Érase una vez una granja que poseía 50 gallinas. Eran gallinas ponedoras que ponían una media regular de cuatro huevos al día, lo que permitiera que el feliz granjero vendiera en el mercado a diario 200 huevos.
Pero el propietario de la granja quería sacar más beneficios, así que emprendió una cruzada contra el encargado para que consiguiera mayor productividad de las gallinas.
Eran una gallinas bastante felices. Hasta escuchaban música por los altavoces repartidos en la granja. Pero debido a la presión que el propietario aplicaba al granjero para rebajar costes, este vendió el equipo de música y canceló la suscripción a Spotify. Ansioso, en lugar de visitar a las gallinas una vez al día, empezó a visitarlas cada dos horas y a recoger el huevo que habían puesto ya. Pero todo este movimiento perturbaba a las gallinas y como consecuencia del estrés, bajaron su producción en un 25%.
Fueron sólo 150 huevos los que pudieron venderse en el mercado. El propietario se puso furioso exigiendo mayor rendimiento con amenazas de despido. Entonces el granjero apretujado cogió una gallina, la mató y la puso en venta en el mercado junto a los 150 huevos del día. Como una gallina valía como 50 huevos, el propietario estuvo relativamente satisfecho con los ingresos. Una gallina menos representaba un ahorro en comida para animales y esto era muy bueno. Sin embargo, al día siguiente, sólo habían 146 huevos. Preocupado, el granjero mató a otra gallina y así sucesivamente durante 10 días. Al cabo de este plazo, le quedaban 40 gallinas que pusieron 120 huevos. Había conseguir mantener ingresos cercanos al precio de venta de una producción de 200 huevos matando gallinas.
¡Qué demonios! El propietario exigía su rendimiento, así que recortó el presupuesto para granos, mató a otra gallina y fue a venderla junto con los 120 huevos del día. Pero los ingresos totales correspondían a una producción de 170 huevos, nada más. El día siguiente era un martes, las 39 gallinas sólo habían puesto 117 así que aumentó la presión sobre ella, molestándolas cada hora y causando aún más estrés.
El viernes tuvo que matar a dos gallinas. Recogió 100 huevos que las supervivientes habían puesto, bajando el promedio habitual. Con todo, ingresó el equivalente a 200 €, como en los buenos tiempos.
Al finalizar del mes, le quedaba una sola gallina que puso dos huevos. Se hizo una tortilla que degustó con un vaso de tinto y un mendrugo de pan, preparó el petate y se fue por los caminos sin mirar atrás.
Pero el propietario de la granja quería sacar más beneficios, así que emprendió una cruzada contra el encargado para que consiguiera mayor productividad de las gallinas.
Eran una gallinas bastante felices. Hasta escuchaban música por los altavoces repartidos en la granja. Pero debido a la presión que el propietario aplicaba al granjero para rebajar costes, este vendió el equipo de música y canceló la suscripción a Spotify. Ansioso, en lugar de visitar a las gallinas una vez al día, empezó a visitarlas cada dos horas y a recoger el huevo que habían puesto ya. Pero todo este movimiento perturbaba a las gallinas y como consecuencia del estrés, bajaron su producción en un 25%.
Fueron sólo 150 huevos los que pudieron venderse en el mercado. El propietario se puso furioso exigiendo mayor rendimiento con amenazas de despido. Entonces el granjero apretujado cogió una gallina, la mató y la puso en venta en el mercado junto a los 150 huevos del día. Como una gallina valía como 50 huevos, el propietario estuvo relativamente satisfecho con los ingresos. Una gallina menos representaba un ahorro en comida para animales y esto era muy bueno. Sin embargo, al día siguiente, sólo habían 146 huevos. Preocupado, el granjero mató a otra gallina y así sucesivamente durante 10 días. Al cabo de este plazo, le quedaban 40 gallinas que pusieron 120 huevos. Había conseguir mantener ingresos cercanos al precio de venta de una producción de 200 huevos matando gallinas.
¡Qué demonios! El propietario exigía su rendimiento, así que recortó el presupuesto para granos, mató a otra gallina y fue a venderla junto con los 120 huevos del día. Pero los ingresos totales correspondían a una producción de 170 huevos, nada más. El día siguiente era un martes, las 39 gallinas sólo habían puesto 117 así que aumentó la presión sobre ella, molestándolas cada hora y causando aún más estrés.
El viernes tuvo que matar a dos gallinas. Recogió 100 huevos que las supervivientes habían puesto, bajando el promedio habitual. Con todo, ingresó el equivalente a 200 €, como en los buenos tiempos.
Al finalizar del mes, le quedaba una sola gallina que puso dos huevos. Se hizo una tortilla que degustó con un vaso de tinto y un mendrugo de pan, preparó el petate y se fue por los caminos sin mirar atrás.
lunes, 29 de noviembre de 2010
MondonGO: Herramienta ODM para MongoDB y PHP
Las virtudes de MongoDB como base de datos son cada vez más apreciadas por las empresas, ofreciendo servicios Web, Web 2.0 y cloud computing, además de productos basados en las mismas tecnologías o en tecnologías tradicionales. Por otra parte, aparecen herramientas que facilitan la administración de MongoDB, backups, el desarrollo de aplicaciones con MongoDB, etc. En esta ocasión me place presentar una herramienta creada en España, llamada MondonGO, y que seguro será muy apreciada por los desarrolladores de PHP.
MondonGO es un ODM (Object Data Mapper, o un Mapeador de Objetos de Datos), lo que permite mapear la estructura de los documentos de MongoDB automáticamente a objetos en PHP, simplificando enormemente los desarrollos, ya que el acceso, la seguridad y las tareas del mapeo son realizadas automáticamente, optimizando la sencillez y la productividad a la hora de desarrollar aplicaciones PHP usando MongoDB
MondonGO es un desarrollo de código abierto, que se puede descargar libremente desde GitHub.
Enlace a MondonGO: http://mondongo.es
MondonGO es un ODM (Object Data Mapper, o un Mapeador de Objetos de Datos), lo que permite mapear la estructura de los documentos de MongoDB automáticamente a objetos en PHP, simplificando enormemente los desarrollos, ya que el acceso, la seguridad y las tareas del mapeo son realizadas automáticamente, optimizando la sencillez y la productividad a la hora de desarrollar aplicaciones PHP usando MongoDB
Mondongo, un ODM para PHP y MongoDB
View more presentations from pablodip.
MondonGO es un desarrollo de código abierto, que se puede descargar libremente desde GitHub.
Enlace a MondonGO: http://mondongo.es
MongoDB: Cómo trabaja una consulta en un entorno fragmentado
Un servidor pequeño. Queremos más capacidad. ¿Qué hacer? Tradicionalmente, podríamos escalar verticalmente con una caja más grande.
Con la fragmentación, en su lugar, escalamos horizontalmente para conseguir la misma huella computacional/almacenamiento/memoria desde servidores pequeños.
He aquí la comparación gráfica de escalabilidad vertical y horizontal:
Una colección fragmentada de MongoDB tiene una clave de fragmento. La colección es particionada en un orden preservando esta clave. En este ejemplo a es nuestra clave de fragmento:
{a:..., b:..., c:... } a es declarado clave de fragmento para la colección
Los metadatos son mantenidos en trozos, los cuales están representados por rangos de claves de fragmentos. Cada trozo es asignado a un fragmento en particular.
Cuando un trozo se hace demasiado grande, MongoDB automáticamente lo divide, y el balanceador más tarde migrará los trozos cuando sea necesario.
El proceso
A veces, un rango de consulta puede abarcar más de un fragmento, pero muy pocos en total. Esto es razonablemente eficiente.
Las consultas que no involucran las claves de fragmentos serán enviadas a todos los fragmentos como una operación "esparcir/reunir". Esto a veces es correcto. Aquí, tanto en nuestra máquina tradicional como en los fragmentos, haremos una exploracion de tabla igualmente (aproximadamente) costosa en ambas.
De nuevo, una consulta con una clave de fragmento resulta en una operación esparcir/reunir. Sin embargo, en cada fragmento, podemos usar el índice
El término a involucra la clave de fragmento y permite a los procesos
Cuando se especifica una ordenación, los fragmentos relevantes ordenan localmente, y los procesos
Cuando se usa la replicación (típicamente un conjunto de réplica), simplemente tenemos más de un nodo por fragmento.
Abajo, las flechas indican replicación en entornos tradicionales contra fragmentados.
Fuente original: http://www.mongodb.org/download/attachments/2097354/how+queries+work+with+sharding.pdf
Con la fragmentación, en su lugar, escalamos horizontalmente para conseguir la misma huella computacional/almacenamiento/memoria desde servidores pequeños.
He aquí la comparación gráfica de escalabilidad vertical y horizontal:
{a:..., b:..., c:... } a es declarado clave de fragmento para la colección
Los metadatos son mantenidos en trozos, los cuales están representados por rangos de claves de fragmentos. Cada trozo es asignado a un fragmento en particular.
| Rango | Fragmento |
| a en [∞, 2000] | 2 |
| a en [2000, 2100] | 8 |
| a en [2100, 2500] | 3 |
| ... | ... |
| a en [88700, ∞] | 0 |
Cuando un trozo se hace demasiado grande, MongoDB automáticamente lo divide, y el balanceador más tarde migrará los trozos cuando sea necesario.
find({a:{$gt:333,$lt:400})El proceso
mongos enruta una consulta a los fragmentos adecuados. Para la consulta anterior, todos los datos posiblemente relevantes están en el fragmento 2, así que la consulta es enviada solamente a aquel nodo, y allí procesada.
{b:1} para hacer la operación eficiente para dicho fragmento. Tenemos un coste elevado sobre la configuración vertical para el esfuerzo de las comunicaciones desde los procesos mongos para cada fragmento - no demasiado si el número de fragmentos es pequeño (10), pero digamos que muy sustancial en un sistema de 1000 fragmentos.
mongos enrutar inteligentemente la consulta al fragmento 2. Una vez que la consulta alcanza el fragmento 2, el índice {b:1} puede ser usada para procesar eficientemente la consulta.
mongos funde los resultados. Así, el uso de recursos de los procesos mongos no es terriblemente alto.
Abajo, las flechas indican replicación en entornos tradicionales contra fragmentados.
Fuente original: http://www.mongodb.org/download/attachments/2097354/how+queries+work+with+sharding.pdf
Primeros pasos con Python y MongoDB
Una de las mejores características de MongoDB es la multitud de drivers existentes para casi cualquier lenguaje de programación (ver Sección Drivers). Para los que amamos Python, tenemos un driver llamado pymongo, y que está soportado por 10gen, la empresa creadora de MongoDB. El site oficial de este driver lo encontramos en: http://api.mongodb.org/python/1.8.1%2B/index.html
Utilizar Python junto a MongoDB es muy sencillo, pues su sintaxis es muy similar a la de la consola
Instalación
La instalación de pymongo es sencilla. En Linux, procederemos a ejecutar el siguiente comando:
O bien, descargamos el código fuente y lo instalamos desde la consola de Python:
Abrir conexión
La conexión se realiza de la siguiente manera:
Usar base de datos
Para obtener un objeto que referencia a la base de datos:
Usar una colección
Para obtener la colección con la que trabajar:
Documentos
Los documentos se mapean en Python como un diccionario:
Algunos tipos de datos especiales requieren de alguna librería específica, como
Insertar documentos
Para insertar un documento:
Recuperar un documento
Para recuperar un único documento simple (el primero):
Recuperar varios documentos
Para recuperar todos los documentos de una colección:
Para recuperar todos los documentos (noticias, en este caso) de un autor concreto:
Contar documentos
Para contar todos los documentos de una colección:
Para contar todos los documentos de un autor concreto:
Consultas de rango
Recupera un determinado rango de documentos, delimitados por condiciones. En este caso, recupera aquellas noticias anteriores a una determinada fecha. El resultado se ordenará por autor:
Indexación
Para indexar la colección "noticias", por fecha (de la más reciente a la más antigua) y por autor (en orden alfabético):
Utilizar Python junto a MongoDB es muy sencillo, pues su sintaxis es muy similar a la de la consola
mongo.Instalación
La instalación de pymongo es sencilla. En Linux, procederemos a ejecutar el siguiente comando:
$ easy_install pymongoO bien, descargamos el código fuente y lo instalamos desde la consola de Python:
$ git clone git://github.com/mongodb/mongo-python-driver.git pymongo
$ cd pymongo/
$ python setup.py installAbrir conexión
La conexión se realiza de la siguiente manera:
>>> from pymongo import Connection
>>> conn = Connection() # Conexion local por defecto
>>> conn = Connection('miServidor', 30500) # Conexion remota a puerto 30500Usar base de datos
Para obtener un objeto que referencia a la base de datos:
>>> db = conn.miBBDD # metodo 1
>>> db = conn['miBBDD'] # metodo 2Usar una colección
Para obtener la colección con la que trabajar:
>>> coll = db.miColeccion # metodo 1
>>> coll = db['miColeccion'] # metodo 2Documentos
Los documentos se mapean en Python como un diccionario:
>>> noticia = {"autor": "Rafael Hernamperez",
... "cuerpo": "Python y MongoDB",
... "etiquetas": ["Tutorial","Python","MongoDB"]}Algunos tipos de datos especiales requieren de alguna librería específica, como
datetime:>>> import datetime
>>> noticia = {"autor": "Rafael Hernamperez",
... "cuerpo": "Python y MongoDB",
... "etiquetas": ["Tutorial","Python","MongoDB"],
... "fecha": datetime.datetime.utcnow()}Insertar documentos
Para insertar un documento:
>>> coll = db.noticias # Coleccion "noticias"
>>> coll.insert(noticia)Recuperar un documento
Para recuperar un único documento simple (el primero):
>>> coll.find_one({"autor": "Rafael Hernamperez"})Recuperar varios documentos
Para recuperar todos los documentos de una colección:
>>> for noticia in coll.find():
... print noticiaPara recuperar todos los documentos (noticias, en este caso) de un autor concreto:
>>> for noticia in coll.find({"autor": "Rafael Hernamperez"})
... print noticiaContar documentos
Para contar todos los documentos de una colección:
>>> coll.count()Para contar todos los documentos de un autor concreto:
>>> coll.find({"autor": "Rafael Hernamperez"}).count()Consultas de rango
Recupera un determinado rango de documentos, delimitados por condiciones. En este caso, recupera aquellas noticias anteriores a una determinada fecha. El resultado se ordenará por autor:
>>> fecha = datetime.datetime(2010, 9, 28, 0, 0) # 2010/09/38 00:00h
... for noticia in coll.find({"fecha": {"$lt":fecha}}).sort(autor):
... print noticiaIndexación
Para indexar la colección "noticias", por fecha (de la más reciente a la más antigua) y por autor (en orden alfabético):
>>> from pymongo import ASCENDING, DESCENDING
>>> coll.create_index([("fecha", DESCENDING), ("autor", ASCENDING)])
MongoDB: Indexación
En MongoDB, la indexación permite optimizar el rendimiento de las consultas, de forma muy similar a la de una base de datos relacional. Los índices se aplican a claves (campos) de nuestros documentos, ordenando sus valores para que la búsqueda sea más eficiente, y manteniendo dicha ordenación de forma constante. Tiene mucho sentido si las consultas sobre la clave es muy frecuente, especialmente si sobre la búsqueda se aplican filtros (mayor que, menor que, etc.), o si la consulta es lenta. También tiene sentido si en las consultas se muestra en un orden determinado.
A pesar de las ventajas del uso de índices, hay que tener en cuenta que los índices toman espacio y ralentizan las escrituras.
El siguiente ejemplo, muestra cómo ordenar una colección por la clave
El valor
Si la clave del índice corresponde a un documento embebido, se ha de indicar la ruta del mismo:
Los índices únicos indican que los valores de la clave no pueden repetirse:
Los índices toman un tiempo para realizar su cometido. Si la colección posee muchos datos, este tiempo ralentizaría el resto de operaciones de la base de datos. Para evitar este tiempo de demora, se puede indicar que el índice se realice en background o como operación en segundo plano:
Si se desea conocer los índices que posee una colección determinada:
Para eliminar un índice de una colección:
Más información: Os recomiendo ver la presentación de Mike Dirolf, de la cual se ha extraído gran parte de la información mostrada aquí:
A pesar de las ventajas del uso de índices, hay que tener en cuenta que los índices toman espacio y ralentizan las escrituras.
El siguiente ejemplo, muestra cómo ordenar una colección por la clave
nombre:db.articulos.ensureIndex({"nombre":1})El valor
1 indica que la ordenación será en orden ascendente (de menor a mayor valor, o alfabéticamente, de la A a la Z). Para indicar que el orden sea descendente, se indicaría el valor -1. El siguiente ejemplo crea un índice compuesto, ordenando por nombre y por db.articulos.ensureIndex({"nombre":1, "fecha":-1})Si la clave del índice corresponde a un documento embebido, se ha de indicar la ruta del mismo:
db.articulos.ensureIndex({"comentarios.autor":1})Los índices únicos indican que los valores de la clave no pueden repetirse:
db.articulos.ensureIndex({"titulo":1}, {unique:true})Los índices toman un tiempo para realizar su cometido. Si la colección posee muchos datos, este tiempo ralentizaría el resto de operaciones de la base de datos. Para evitar este tiempo de demora, se puede indicar que el índice se realice en background o como operación en segundo plano:
db.articulos.ensureIndex({"nombre":1, "fecha":-1}, {background: true})Si se desea conocer los índices que posee una colección determinada:
db.articulos.getIndexes()Para eliminar un índice de una colección:
db.articulos.dropIndex({"nombre":1})Más información: Os recomiendo ver la presentación de Mike Dirolf, de la cual se ha extraído gran parte de la información mostrada aquí:
Indexing
View more presentations from Mike Dirolf.
MongoDB: Python y MapReduce
El presente post está inspirado en el artículo "MapReduce with MongoDB and Python", de Marcel Caraciolo, y en el cual veremos cómo implementar la función Map-Reduce mediante Python y MongoDB, donde podremos apreciar su potencial en grandes conjuntos de datos en computación distribuída.
Como ejemplo sencillo e ilustrativo, contaremos la frecuencia de palabras a través de varios documentos. En primer lugar, veremos cómo funciona map-reduce,utilizando una lista de sentencias simples. Para ello, tenemos el siguiente diagrama, en donde las palabras son divididas y agrupadas por la función map, y después reducidas independientemente (agregación) por la función reduce. Nuestra consulta puede estar distribuída en cuatro ordenadores, por lo que su procesamiento es mucho más rápido en tiempo de ejecución. El ejemplo, además, muestra un árbol balanceado, pero podría estar no balanceado o incluso tener alguna redundancia.
Antes de comenzar a desarrollar las funciones map y reduce debes saber que:
1) El motor MapReduce puede invocar funciones reduce de forma iterativa, por lo que éstas deben ser idempotentes:
for all k,vals : reduce( k, [reduce(k,vals)] ) == reduce(k,vals)
1) Actualmente, el retorno de valores de una función reduce no puede ser un array (ha de ser un objeto o un número)
3) Si necesitas realizar una operación una única vez, utiliza la funión finalize.
Para implementar el código debes utilizar el framework Pymongo, el cual tiene soporte para Map/Reduce. Como ejemplo, el discurso de Obama en 2009 tiene muchas palabras repetidas, como puede apreciarse en la siguiente nube de etiquetas, cuyo tamaño de fuente indica la frecuencia de cada palabra:
MongoDB permite a los clientes enviar las implementaciones JavaScript de map y reduce, las cuales se evaluarán y ejecutarán en el servidor. La función map sería la siguiente (
MongoDB llamará a la función map por cada documento en la colección que está consultando, y apuntará al documento donde tendrá acceso una clave como
La función reduce ha de reducir una lista de un tipo dado a un valor simple del mismo tipo; debe transsitivo para que no tenga problemas sobre cómo están agrupados los elementos mapeados.
A continuación, el código del cliente Pymongo que pasa las funciones map/reduce al servidor:
Como ejemplo sencillo e ilustrativo, contaremos la frecuencia de palabras a través de varios documentos. En primer lugar, veremos cómo funciona map-reduce,utilizando una lista de sentencias simples. Para ello, tenemos el siguiente diagrama, en donde las palabras son divididas y agrupadas por la función map, y después reducidas independientemente (agregación) por la función reduce. Nuestra consulta puede estar distribuída en cuatro ordenadores, por lo que su procesamiento es mucho más rápido en tiempo de ejecución. El ejemplo, además, muestra un árbol balanceado, pero podría estar no balanceado o incluso tener alguna redundancia.
1) El motor MapReduce puede invocar funciones reduce de forma iterativa, por lo que éstas deben ser idempotentes:
for all k,vals : reduce( k, [reduce(k,vals)] ) == reduce(k,vals)
1) Actualmente, el retorno de valores de una función reduce no puede ser un array (ha de ser un objeto o un número)
3) Si necesitas realizar una operación una única vez, utiliza la funión finalize.
Para implementar el código debes utilizar el framework Pymongo, el cual tiene soporte para Map/Reduce. Como ejemplo, el discurso de Obama en 2009 tiene muchas palabras repetidas, como puede apreciarse en la siguiente nube de etiquetas, cuyo tamaño de fuente indica la frecuencia de cada palabra:
wordMap.js):function wordMap() { |
MongoDB llamará a la función map por cada documento en la colección que está consultando, y apuntará al documento donde tendrá acceso una clave como
text mediante this.text. Esta función no retorna una lista, si no que llama a una función emit que espera ser definida. Los parámetros de esta función (clave, valor), serán agrupados con otros resultados intermedios de otras evaluaciones map que tengan la misma clave (clave, [valor1, valor2]) y pasada a la función reduce (wordReduce.jsfunction wordReduce(key, values) { |
La función reduce ha de reducir una lista de un tipo dado a un valor simple del mismo tipo; debe transsitivo para que no tenga problemas sobre cómo están agrupados los elementos mapeados.
A continuación, el código del cliente Pymongo que pasa las funciones map/reduce al servidor:
MongoDB: Un ejemplo de MapReduce
Conceptos de MapReduce
MapReduce es una característica importante comprendida por MongoDB. Este framework fue creado por Google para dar solución a la computación paralela sobre grandes colecciones de datos en sistemas distribuídos. El concepto se basa en dos funciones, map y reduce, que se aplican sobre datos estructurados en formato de pares clave-valor.
La función map (mapeo) toma uno de estos pares en un dominio de datos, y retorna una lista de pares en un dominio diferente. Se aplica en paralelo por cada elemento de la entrada de datos, produciendo la lista de pares por cada llamada, juntando todos los pares con la misma clave de todas las listas y los agrupa, creando un grupo por cada clave.
La función reduce (reducción) se aplica paralelamente a cada grupo, generando una colección de valores para cada dominio, produciendo un valor (o varios) en cada llamada.
Básicamente, MapReduce transforma una lista de pares clave-valor en una lista de valores.
Un ejemplo
Para comprender cómo funciona MapReduce, vamos a ver un ejemplo práctico. Para ello, voy a utilizar uno ya hecho por Kristina Chodorow, una de las principales creadoras de MongoDB.
Imaginemos que tenemos una colección
La clave
La función
La función
Lo primero que hace es comprobar si existe una clave llamada
La función
Para ejecutar ésto, invocaremos al comando
Los parámetros facilitados son:
-
-
-
-
Finalmente, consultamos la colección
Fuentes consultadas
Concepto de MapReduce en Wikipedia: http://es.wikipedia.org/wiki/MapReduce
Artículo "Contar etiquetas", por Kristina Chodorow: http://cookbook.mongodb.org/patterns/count_tags/
MapReduce es una característica importante comprendida por MongoDB. Este framework fue creado por Google para dar solución a la computación paralela sobre grandes colecciones de datos en sistemas distribuídos. El concepto se basa en dos funciones, map y reduce, que se aplican sobre datos estructurados en formato de pares clave-valor.
La función map (mapeo) toma uno de estos pares en un dominio de datos, y retorna una lista de pares en un dominio diferente. Se aplica en paralelo por cada elemento de la entrada de datos, produciendo la lista de pares por cada llamada, juntando todos los pares con la misma clave de todas las listas y los agrupa, creando un grupo por cada clave.
La función reduce (reducción) se aplica paralelamente a cada grupo, generando una colección de valores para cada dominio, produciendo un valor (o varios) en cada llamada.
Básicamente, MapReduce transforma una lista de pares clave-valor en una lista de valores.
Un ejemplo
Para comprender cómo funciona MapReduce, vamos a ver un ejemplo práctico. Para ello, voy a utilizar uno ya hecho por Kristina Chodorow, una de las principales creadoras de MongoDB.
Imaginemos que tenemos una colección
posts, que almacena los artículos de nuestro blog. Un documento en esta colección podría tener esta estructura:
tags es un array de etiquetas, que permiten categorizar cada artículo. Y sobre esta clave vamos a basar el ejemplo de MapReduce, como por ejemplo, conocer las etiquetas más populares, dando un resultado como éste:
map emitirá cada etiqueta (tag), y la contará en la función reduce. La función
map es la siguiente:
tags, para evitar errores. A continuación realiza un bucle sobre esta clave (por cada elemento del array), emitiendo su nombre y un contador de 1.La función
reduce inicializa un contador a 0 y le añade cada elemento del array current. Al final retorna el contador final:
mapreduce:
-
mapreduce: Se facilita la colección sobre la que extraer los datos (posts).-
map: Nombre de la función que realizará el mapeo.-
reduce: Nombre de la función que realizará la reducción.-
out: Colección donde se pondrá el resultado.Finalmente, consultamos la colección
tags para mostrar los resultados:
Fuentes consultadas
Concepto de MapReduce en Wikipedia: http://es.wikipedia.org/wiki/MapReduce
Artículo "Contar etiquetas", por Kristina Chodorow: http://cookbook.mongodb.org/patterns/count_tags/
Comparativa MongoDB con otras Bases de datos NoSQL
He encontrado en myNoSQL algunas tablas comparativas de MongoDB con respecto a otras bases de datos NoSQL, creadas por Alex Popescu.
Bases de datos orientadas a documento
La primera tabla compara tres bases de datos orientadas a documento: MongoDB, CouchDB y RavenDB (echo en falta una columna para OrientDB).
Lenguajes de programación
La siguiente tabla muestra el uso de lenguajes de programación en varias bases de datos NoSQL. Yo hubiera añadido también Perl, C/C++, Erlang ó Go, que son lenguajes populares que también comprende MongoDB (entre otros muchos).
Fuentes
http://nosql.mypopescu.com/post/1016366403/nosql-guide-for-beginners
http://nosql.mypopescu.com/post/978742866/document-databases-compared-couchdb-mongodb-ravendb
Bases de datos orientadas a documento
La primera tabla compara tres bases de datos orientadas a documento: MongoDB, CouchDB y RavenDB (echo en falta una columna para OrientDB).
| MongoDB | CouchDB | RavenDB | |
| Documentos | |||
| Formato | BSON | JSON | JSON |
| Metadata | No | Sistema | Sistema + personalizado |
| Versionado | No | Sí | Plugin incluído |
| Adjuntos | GridFS | Sí | Sí |
| Map/Reduce | JavaScript + otros | JavaScript | LINQ |
| Carga masiva | mongoimport | Sí | Sí |
| Consulta Adhoc | Sí | No | No |
| Almacenamiento | |||
| Fragmentación | Sí | Sí | Sí |
| Durabilidad | Servidor simple v1.8 | Diseño "crash-only" | Escritura previa trazabilidad y aislamiento de instantáneas para garantizar recuperación vía ESE |
| Transacciones | No | No | Sí |
| Concurrencia | Actualización in-place | MVCC (Multi-Version Concurrency Control) | Concurrencia optimista |
| Consistencia | Maestro fuerte / Esclavo eventual | Nodo fuerte / Cluster eventual | Eventual |
| Replicación | Maestro-Maestro con funciones de resolución personalizadas | Maestro-Esclavo | Plugin incluído |
| Interfaz | |||
| Protocolo | Personalizado sobre TCP/IP | HTTP/REST | HTTP/REST |
| .NET API | Proyectos de terceros | Proyectos de terceros | Incluído |
| Otros | |||
| Triggers | No | Validación de actualización, Seguridad | Sí |
| Seguridad | Básica | Básica | Ninguna |
| Escrito en | C++ | Erlang | C# |
Lenguajes de programación
La siguiente tabla muestra el uso de lenguajes de programación en varias bases de datos NoSQL. Yo hubiera añadido también Perl, C/C++, Erlang ó Go, que son lenguajes populares que también comprende MongoDB (entre otros muchos).
| BBDD | Modo durabilidad | java | ruby | python | php | .net | http | |
| documento | mongodb | basado en réplica | x | x | x | x | x | x |
| couchdb | nodo simple | x | x | x | x | x | x | |
| ravendb | nodo simple | - | - | - | - | x | x | |
| clave-valor | redis | en memoria, serializado en disco | x | x | x | x | x | - |
| riak | basado en réplica | x | x | x | x | x | x | |
| tabular | cassandra | basado en réplica | x | x | x | x | x | - |
| grafo | neo4j | nodo simple | x | x | x | x | - | x |
| sones | nodo simple | - | - | - | - | x | x |
Fuentes
http://nosql.mypopescu.com/post/1016366403/nosql-guide-for-beginners
http://nosql.mypopescu.com/post/978742866/document-databases-compared-couchdb-mongodb-ravendb
MongoDB: Ejemplo de configuración de fragmentación
Este post es una traducción del artículo original "Return to the Mongo Mailbag", de Kristina Chodorow.
En la lista de correo
"Tengo 4 servidores y quiero dos frgamentos. ¿Cómo lo configuro?"
Mucha gente está preguntando sobre cómo configurar conjuntos de réplica y fragmentación, por lo que que aquí se explicará en detalle.
The Architecture
Prerequisitos. Si no estás familiarizado con los conjuntos de réplica, echa un vistazo a mi post en mi blog. El resto de este post no tendrá mucho sentido a menos que tú sepas qué es un árbitro. Además, deberías conocer los conceptos de la fragmentación.
Cada fragmento debería ser un conjunto de réplica, por lo que necesitaremos dos conjuntos de réplica (los llamaremos "foo" y "bar"). Queremos que nuestro cluster sea correcto si una de las máquinas se cae o se separa de la manada (partición de red), así que extenderemos fuera cada conjunto entre las máquinas disponibles. Los conjuntos de réplica están codificadas por color y las máquinas son nombradas imaginativamente server1-4.
Cada conjunto de replica tiene dos hosts y un árbitro. De esta manera, si un servidor se cae, ninguna funcionalidad se pierde (y ahí no estarán dos maestros en un servidor simple).
Para configurar ésto, ejecuta:
server1
server2
server3
server4
Los árbitros tienen un tamaño de oplog de 1. Por defecto, el tamaño de oplog es un ~5% de tu disco duro, pero los árbitros no necesitan mantener ningún dato, por lo que esto es un gran desperdicio de espacio.
Poner juntos los conjuntos de réplica
Ahora arrancaremos los dos conjuntos de réplica. Arrancar la consola
Ahora tenemos dos conjuntos de réplica en ejecución. Creemos ahora un cluster.
Configurar la fragmentación
Una vez intentemos configurar un sistema sin puntos simples de fallo, usaremos tres servidores de configuración. Podemos tener tantos procesos
server2
server3
server4
Ahora añadiremos nuestros conjuntos de réplica al cluster. Concta los
Como puedes ver, terminarás con un fragmento "foo" y un fragmento "bar". (si estás usando una versión antigua de MongoDB, tus fragmentos tendrán nombres como “shard0000″ o “shard0001″)
Ahora puedes conectar a
En la lista de correo
mongodb-user de la semana pasada, alguien preguntó (básicamente):"Tengo 4 servidores y quiero dos frgamentos. ¿Cómo lo configuro?"
Mucha gente está preguntando sobre cómo configurar conjuntos de réplica y fragmentación, por lo que que aquí se explicará en detalle.
The Architecture
Prerequisitos. Si no estás familiarizado con los conjuntos de réplica, echa un vistazo a mi post en mi blog. El resto de este post no tendrá mucho sentido a menos que tú sepas qué es un árbitro. Además, deberías conocer los conceptos de la fragmentación.
Cada fragmento debería ser un conjunto de réplica, por lo que necesitaremos dos conjuntos de réplica (los llamaremos "foo" y "bar"). Queremos que nuestro cluster sea correcto si una de las máquinas se cae o se separa de la manada (partición de red), así que extenderemos fuera cada conjunto entre las máquinas disponibles. Los conjuntos de réplica están codificadas por color y las máquinas son nombradas imaginativamente server1-4.
Cada conjunto de replica tiene dos hosts y un árbitro. De esta manera, si un servidor se cae, ninguna funcionalidad se pierde (y ahí no estarán dos maestros en un servidor simple).
Para configurar ésto, ejecuta:
server1
$ mkdir -p ~/dbs/foo ~/dbs/bar
$ ./mongod --dbpath ~/dbs/foo --replSet foo
$ ./mongod --dbpath ~/dbs/bar --port 27019 --replSet bar --oplogSize 1server2
$ mkdir -p ~/dbs/foo
$ ./mongod --dbpath ~/dbs/foo --replSet fooserver3
$ mkdir -p ~/dbs/foo ~/dbs/bar
$ ./mongod --dbpath ~/dbs/foo --port 27019 --replSet foo --oplogSize 1
$ ./mongod --dbpath ~/dbs/bar --replSet barserver4
$ mkdir -p ~/dbs/bar
$ ./mongod --dbpath ~/dbs/bar --replSet barLos árbitros tienen un tamaño de oplog de 1. Por defecto, el tamaño de oplog es un ~5% de tu disco duro, pero los árbitros no necesitan mantener ningún dato, por lo que esto es un gran desperdicio de espacio.
Poner juntos los conjuntos de réplica
Ahora arrancaremos los dos conjuntos de réplica. Arrancar la consola
mongo y escribir:> db = connect("server1:27017/admin")
connecting to: server1:27017
admin
> rs.initiate({"_id" : "foo", "members" : [
... {"_id" : 0, "host" : "server1:27017"},
... {"_id" : 1, "host" : "server2:27017"},
... {"_id" : 2, "host" : "server3:27019", arbiterOnly : true}]})
{
"info" : "Config now saved locally. Should come online in about a minute.",
"ok" : 1
}
> db = connect("server3:27017/admin")
connecting to: server3:27017
admin
> rs.initiate({"_id" : "bar", "members" : [
... {"_id" : 0, "host" : "server3:27017"},
... {"_id" : 1, "host" : "server4:27017"},
... {"_id" : 2, "host" : "server1:27019", arbiterOnly : true}]})
{
"info" : "Config now saved locally. Should come online in about a minute.",
"ok" : 1
}Ahora tenemos dos conjuntos de réplica en ejecución. Creemos ahora un cluster.
Configurar la fragmentación
Una vez intentemos configurar un sistema sin puntos simples de fallo, usaremos tres servidores de configuración. Podemos tener tantos procesos
mongos como queramos (se recomienda uno en cada appserver), pero empezaremos con uno.server2
$ mkdir ~/dbs/config
$ ./mongod --dbpath ~/dbs/config --port 20000server3
$ mkdir ~/dbs/config
$ ./mongod --dbpath ~/dbs/config --port 20000server4
$ mkdir ~/dbs/config
$ ./mongod --dbpath ~/dbs/config --port 20000
$ ./mongos --configdb server2:20000,server3:20000,server4:20000 --port 30000Ahora añadiremos nuestros conjuntos de réplica al cluster. Concta los
mongos y ejecuta el comando addshard:> mongos = connect("server4:30000/admin")
connecting to: server4:30000
admin
> mongos.runCommand({addshard : "foo/server1:27017"})
{ "shardAdded" : "foo", "ok" : 1 }
> mongos.runCommand({addshard : "bar/server3:27017"})
{ "shardAdded" : "bar", "ok" : 1 }Como puedes ver, terminarás con un fragmento "foo" y un fragmento "bar". (si estás usando una versión antigua de MongoDB, tus fragmentos tendrán nombres como “shard0000″ o “shard0001″)
Ahora puedes conectar a
“server4:30000″ en tu aplicación y utilizarlo con un simple y “normal” mongod. Si quieres añadir más procesos mongos, simplemente arráncalos con los mismos parámetros configdb utilizados anteriormente.
MongoDB: Conjuntos de réplica. Parte 3
Este post asume que sabes qué son los conjuntos de réplica y algo de la sintáxis básica.
En la parte 1, configuramos un conjunto de réplica desde cero, pero la vida real es más desordenado: puedes querer migrar servidores de desarrollo a producción, añadir nuevos esclavos, priorizar servidores, cambiar cosas en el momento (on the fly)... y ésto es lo que este post cubre.
Antes de empezar…
A los conjuntos de réplica no les gusta localhost. Son serviciales para secundarlos... más o menos, bastante... pero a menudo provoca discrepancias. Puedes evitar estas discrepancias usando en su lugar el nombre del servidor (hostname). En Linux, puedes buscar tu nombre de servidor ejecutando el comando:
De aquí en adelante, usaremos mi nombre de servidor en lugar de localhost.
Arrancar con datos
Esto es más o menos que arrancar sin datos, escepto que deberías hacer una copia de seguridad de tus datos antes de arrancar (deberías siempre hacer un backup siempre de tus datos antes de hacer travesuras con tu servidor de configuración).
Si en el pre-conjunto-réplica, arrancaste tu servidor con algo como:
...conviértelo en el primer miembro de tu conjunto de réplica, por lo que has de parar y arrancar de nuevo con la opción –replset:
Ahora, inicializa el conjunto con el único servidor:
Agregar esclavos
Deberías arrancar MongoDB siempre con esclavos, así que agreguemos alguno.
Arranca tu servidor con las opciones usuales, así como también como –replSet. Así, por ejemplo, podríamos hacer:
Ahora, agregamos este esclavo al conjunto de réplica. Asegurarse de que db está conectado a wooster:27017 (el servidor primario) y arrancar:
Repetir como sea necesario para agregar más esclavos.
Agregar un árbitro
Esto es muy similar a agregar un esclavo. Cuando arranques el árbitro, deberías darle la opción –oplogSize 1. De esta manera el árbitro no desperdiciará espacio.
Ahora agregarlo al conjunto. Puedes especificar que este servidor es un árbitro pasando en un objeto un campo arbiterOnly a rs.add:
Degradar un primario
Supongamos que nuestra compañía tiene disponibles los siguientes servidores:
1. Super máquina Gazillion dollar
2. Instancia EC2
3. iMac que encontramos en la calle
A través de un accidente del destino, el iMac se convierte en primario. Podemos forzarle a que se convierta en esclavo ejecutando el comando:
Ahora el iMac será un esclavo.
Establecer prioridades
Podemos indicar que el iMac nunca sea un maestro (queremos usarlo sólo como backup). Puedes forzar ésto estableciendo su prioridad a cero. La más alta prioridad de un servidor es la que hará que se convierta en maestro si el actual maestro falla. Las únicas opciones son 0 (no puede ser maestro) o 1 (puede ser maestro), pero en el futuro serás capaz de tener una buena graduación de prioridades..
Así, cambiaremos la prioridad del iMac a 0. Para cambiar la configuración, conectemos al maestro y editemos su configuración:
Ahora, tenemos que hacer dos cosas: 1) establecer la prioridad del iMac a 0, y 2) actualizar la versión de la configuración. El nuevo número de versión es siempre el anterior más uno
Finalmente, decimos al conjunto de réplica que tenemos una nueva configuración.
Todos los cambios de configuración deben ocurrir en el maestro. Éstos se propagarán de éste a los esclavos. Ahora puedes "matar" cualquier servidor y el iMac nunca se convertirá en maestro.
Esta configuración es un poco melindrosa para hacer desde la consola. En el futuro, la gente probablemente utilice una GUI para configurar sus conjuntos y trastear con la configuración del servidor.
Artículo original: http://www.snailinaturtleneck.com/blog/2010/08/03/part-3-replica-sets-in-the-wild/
En la parte 1, configuramos un conjunto de réplica desde cero, pero la vida real es más desordenado: puedes querer migrar servidores de desarrollo a producción, añadir nuevos esclavos, priorizar servidores, cambiar cosas en el momento (on the fly)... y ésto es lo que este post cubre.
Antes de empezar…
A los conjuntos de réplica no les gusta localhost. Son serviciales para secundarlos... más o menos, bastante... pero a menudo provoca discrepancias. Puedes evitar estas discrepancias usando en su lugar el nombre del servidor (hostname). En Linux, puedes buscar tu nombre de servidor ejecutando el comando:
$ hostname
woosterDe aquí en adelante, usaremos mi nombre de servidor en lugar de localhost.
Arrancar con datos
Esto es más o menos que arrancar sin datos, escepto que deberías hacer una copia de seguridad de tus datos antes de arrancar (deberías siempre hacer un backup siempre de tus datos antes de hacer travesuras con tu servidor de configuración).
Si en el pre-conjunto-réplica, arrancaste tu servidor con algo como:
$ ./mongod...conviértelo en el primer miembro de tu conjunto de réplica, por lo que has de parar y arrancar de nuevo con la opción –replset:
$ ./mongod --replSet unicomplex/wooster:27017Ahora, inicializa el conjunto con el único servidor:
> rs.initiate()
{
"info" : "Config now saved locally. Should come online in about a minute.",
"ok" : 1
}Agregar esclavos
Deberías arrancar MongoDB siempre con esclavos, así que agreguemos alguno.
Arranca tu servidor con las opciones usuales, así como también como –replSet. Así, por ejemplo, podríamos hacer:
$ ./mongod --dbpath ~/dbs/slave1 --port 27018 --replSet unicomplex/wooster:27017Ahora, agregamos este esclavo al conjunto de réplica. Asegurarse de que db está conectado a wooster:27017 (el servidor primario) y arrancar:
> rs.add("wooster:27018")
{"ok" : 1}Repetir como sea necesario para agregar más esclavos.
Agregar un árbitro
Esto es muy similar a agregar un esclavo. Cuando arranques el árbitro, deberías darle la opción –oplogSize 1. De esta manera el árbitro no desperdiciará espacio.
$ ./mongod --dbpath ~/dbs/arbiter --port 27019 --replSet unicomplex/wooster:27017 --oplogSize 1Ahora agregarlo al conjunto. Puedes especificar que este servidor es un árbitro pasando en un objeto un campo arbiterOnly a rs.add:
> rs.add({"host" : "wooster:27019", "arbiterOnly" : true})
{"ok" : 1}Degradar un primario
Supongamos que nuestra compañía tiene disponibles los siguientes servidores:
1. Super máquina Gazillion dollar
2. Instancia EC2
3. iMac que encontramos en la calle
A través de un accidente del destino, el iMac se convierte en primario. Podemos forzarle a que se convierta en esclavo ejecutando el comando:
> imac = connect("imac.example.com/admin")
connecting to: imac.example.com/admin
admin
> imac.runCommand({"replSetStepDown" : 1})
{"ok" : 1}Ahora el iMac será un esclavo.
Establecer prioridades
Podemos indicar que el iMac nunca sea un maestro (queremos usarlo sólo como backup). Puedes forzar ésto estableciendo su prioridad a cero. La más alta prioridad de un servidor es la que hará que se convierta en maestro si el actual maestro falla. Las únicas opciones son 0 (no puede ser maestro) o 1 (puede ser maestro), pero en el futuro serás capaz de tener una buena graduación de prioridades..
Así, cambiaremos la prioridad del iMac a 0. Para cambiar la configuración, conectemos al maestro y editemos su configuración:
> config = rs.conf()
{
"_id" : "unicomplex",
"version" : 1,
"members" : [
{
"_id" : 0,
"host" : "prod.example.com:27017"
},
{
"_id" : 1,
"host" : "ec2.example.com:27017"
},
{
"_id" : 2,
"host" : "imac.example.com:27017"
}
]
}Ahora, tenemos que hacer dos cosas: 1) establecer la prioridad del iMac a 0, y 2) actualizar la versión de la configuración. El nuevo número de versión es siempre el anterior más uno
> config.members[2].priority = 0
0
> config.version += 1
2Finalmente, decimos al conjunto de réplica que tenemos una nueva configuración.
> use admin
switched to db admin
> db.runCommand({"replSetReconfig" : config})
{"ok" : 1}Todos los cambios de configuración deben ocurrir en el maestro. Éstos se propagarán de éste a los esclavos. Ahora puedes "matar" cualquier servidor y el iMac nunca se convertirá en maestro.
Esta configuración es un poco melindrosa para hacer desde la consola. En el futuro, la gente probablemente utilice una GUI para configurar sus conjuntos y trastear con la configuración del servidor.
Artículo original: http://www.snailinaturtleneck.com/blog/2010/08/03/part-3-replica-sets-in-the-wild/
Suscribirse a:
Entradas (Atom)