2012

Columnas y artículos publicados en 2012

Programación funcional: Enfrenta a la concurrencia

TitleProgramación funcional: Enfrenta a la concurrencia
Publication TypeMagazine Article
Year of Publication2012
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number35
Pagination48-49
Date Published01/2012
Type of ArticleColumn
ISSN1870-0888
URLhttp://sg.com.mx/buzz/programar-es-un-estilo-vida
Full Text

El tema eje de el presente número de Software Gurú es el manejo de datos a muy gran escala (y disculparán que no use la frase más de moda en la industria, Big Data, habiendo otras igual de descriptivas en nuestro idioma). Al hablar de muy gran escala tenemos que entender que pueden ser juegos de datos mucho mayores de lo que acostumbramos — Estamos hablando de un aumento de por lo tres a seis órdenes de magnitud en la escala de los datos a analizar: Según las definiciones más comunes hoy en día, en el rango entre decenas de terabytes y petabytes.
Dar un salto tan grande nos presenta retos en muy diversas esferas. Para muchas de las necesidades que enfrentamos, tenemos que adecuar nuestros procesos de desarrollo, las herramientas que empleamos, el modelo con el cual almacenamos, solicitamos y procesamos la información, e incluso el hardware mismo. Enfocaré este texto a un paradigma de programación que permite enfrentar a la concurrencia de una forma más natural y menos traumática de lo que acostumbramos.
Una de las razones por las que este tema ha armado tanto alboroto en el campo del desarrollo de software es que, si bien la capacidad de cómputo a nuestro alcance ha crecido de forma francamente bestial desde casi cualquier métrica en el tiempo que nos ha tocado vivir como profesionales, nuestra formación sigue estando basada en un modelo de desarrollo muy difícil de escalar. Vamos, el problema no lo tienen las computadoras, sino nosotros los programadores: No sólo tenemos que explicar a la computadora lo que requerimos que haga, sino que además de ello tenemos que cuidar que no se tropiece –cual si fuera un ciempiés– con su propia marcha. Siempre que hablemos de muy gran escala debemos hablar, sí o sí, de un alto grado de paralelismo en nuestras aplicaciones. Y por muchos años, el paralelismo fue precisamente algo de lo que buena parte de los programadores buscaban escapar, por las complicaciones que conlleva ante una programación imperativa, necesariamente secuencial.
Las alarmas comenzaron a sonar fuertemente hacia el año 2005, en que los fabricantes de hardware tuvieron que cambiar su estrategia (y lograron, sorprendentemente, inyectarle algunos años más de vida a la ley de Moore, la cual indica que el número de transistores que componen a un chip se duplica aproximadamente cada dos años, ritmo que se ha mantenido por 40 años ya): Al migrar el desarrollo de procesadores una estrategia de multiprocesamiento (CPUs múltiples empaquetados como una sóla unidad), dejando de lado la carrera de los megahertz, aventaron la papa caliente hacia el lado de los desarrolladores: Tendríamos que adecuarnos a una realidad de concurrencia verdadera y ya no simulada.
Los sistemas multiprocesador no son, claro está, tan recientes. El gran cambio es que ahora prácticamente todas las computadoras de rango medio (incluso ya algunos teléfonos celulares) tienen esta tecnología disponible. Claro está, todo el software de infraestructura, desde los sistemas operativos, compiladores y bibliotecas tuvieron que irse adecuando gradualmente para poder administrar y ofrecer al usuario estos recursos.
Por muchos años, vivimos sabiéndolo en un mundo de falsa concurrencia: Una computadora sólo podía hacer una cosa a la vez, dado que contaba con un sólo procesador. Por la velocidad de su operación, y por el empeño que se puso en que los cambios de contexto fueran tan ágiles como fuese posible, nos daba la impresión de que varias cosas ocurrían al mismo tiempo. Esto, claro, no debe sorprender a ninguno de ustedes — El gran reto introducido por el paralelismo real es manejar correctamente escenarios mucho más complejos de condiciones de carrera que antes no se presentaban tan fácilmente. Antes del paralelismo, podíamos indicar al sistema operativo que nuestro programa estaba por entrar a una sección crítica, con lo cual éste podía decidir retirar el control a nuestro programa para entregarlo a otro si estaba cercano a finalizar su tiempo, o darle una prórroga hasta que saliera de dicha sección.
Cuando hay más de un procesador (un CPU multicore o multinúcleo alberga a varios procesadores, en ocasiones compartiendo elementos como uno de los niveles de memoria cache), la situación se complica: El sistema operativo puede, sí, mantener en ejecución a uno de los programas para reducir la probabilidad de conflictos, pero se hizo indispensable hacer la colaboración entre procesos algo explícito.
Claro, esto no fue un desarrollo repentino ni algo fundamentalmente novedoso. Los mutexes nos han acompañado por muy largos años, y la programación multihilos nos ha regalado dolores de cabeza desde hace muchos años. Sin embargo, en sistemas uniprocesador, la incidencia de condiciones de carrera era suficientemente baja como para que muchos las ignoraran.
Una de las razones por las que la concurrencia nos provoca esos dolores de cabeza es porque nos hemos acostumbrada a enfrentarnos a ella con las herramientas equivocadas. Un tornillo puede clavarse a martillazos, y no dudo que haya quien use destornilladores para meter clavos, pero tendremos mucho mayor éxito (y un tiempo de entrega mucho más aceptable) si usamos la herramienta correcta.
Los lenguajes basados en programación funcional resuelven en buena medida los problemas relacionados con la concurrencia, y pueden de manera natural desplegarse en un entorno masivamente paralelo. Sin embargo, requieren un cambio más profundo en la manera de pensar que, por ejemplo, cuando adoptamos la adopción de la programación orientada a objetos.
¿Cuál es la diferencia? Aprendimos a programar de forma imperativa, con el símil de la lista de instrucciones para una receta de cocina — Los lenguajes puramente funcionales son mucho más parecidos a una definición matemática, en que no hay una secuencia clara de resolución, sino que una definición de cómo se ve el problema una vez resuelto, y los datos se encargan de ir marcando el camino de ejecución. Los lenguajes puramente funcionales tienen una larga historia (Lisp fue creado en 1958), pero en la industria nunca han tenido la adopción de los lenguajes imperativos. Hay una tendencia en los últimos 20 años, sin embargo, de incorporar muchas de sus características en lenguajes mayormente imperativos.
La principal característica que diferencía a los lenguajes funcionales que nos hacen pensar en definiciones matemáticas es que la llamada a una función no tiene efectos secundarios — ¿Han depurado alguna vez código multihilos para darse cuenta que el problema venía de una variable que no había sido declarada como exclusiva? Con la programación funcional, este problema simplemente no se presentaría. Esto lleva a que podamos definir (en AliceML) el cálculo de la serie de Fibonacci como:

      fun fib 0 = 0
        | fib 1 = 1
        | fib n  if (n > 1) = spawn fib(n-1) + fib(n-2);
        | fib _ = raise Domain
    

A diferencia de una definición imperativa, la función es definida dependiendo de la entrada recibida, y la última línea nos muestra el comportamiento en caso de no estar contemplado por ninguna de las condiciones. Y el puro hecho de indicar la palabra «spawn» indica al intérprete que realice este cálculo en un hilo independiente (que podría ser enviado a otro procesador, o incluso a otro nodo, para su cálculo).
Otra de las propiedades de estos lenguajes, las funciones de órden superior (funciones que toman como argumentos a otras funciones). Por ejemplo, en Haskell:

      squareList = map (^2) list
    

Al darle una lista de números a la función squareList, nos entrega otra lista, con el cuadrado de cada uno de los elementos de la lista original. Y, obviamente, esto se puede generalizar a cualquier transformación que se aplicar iterativamente a cada uno de los elementos de la lista.
Hay varios tipos de funciones de órden superior, pero en líneas generales, pueden generalizarse al mapeo (repetir la misma función sobre los elementos de una lista, entregando otra lista como resultado) y la reducción (obtener un resultado único por aplicar la función en cuestión a todos los elementos de la lista). Y es, de hecho, basándose en juegos de mapeo/reducción que se ejecutan la mayor parte de las tareas intensivas en datos en Google.
Podemos encontrar frecuentemente otros dos patrones en estos lenguajes, aunque por simplicidad no los incluyo en estos ejemplos: Por un lado, al no tener efectos secundarios, tenemos la garantía de que toda llamada a una función con los mismos argumentos tendrá los mismos resultados, por lo que un cálculo ya realizado no tiene que recalcularse, y podemos guardar los resultados de las funciones (especialmente en casos altamente recursivos, como éste). En segundo, la evaluación postergada: Podemos indicar al intérprete que guarde un apuntador a un resultado, pero que no lo calcule hasta que éste sea requerido para una operación inmediata (por ejemplo, para desplegar un resultado, o para asignarlo a un cálculo no postergable).
Una de las grandes desventajas que enfrentó la programación funcional es que los lenguajes funcionales puros crecieron dentro de la burbuja académica, resultando imprácticos para su aplicación en la industria del desarrollo. Esto ha cambiado fuertemente. Hoy en día podemos ver lenguajes que gozan de gran popularidad y han adoptado muchas construcciones derivadas de la programación funcional, como Python, Ruby o Perl. Hay lenguajes funcionales que operan sobre las máquinas virtuales de Java (Clojure) y .NET (F#). Por otro lado, lenguajes como Erlang, OCaml y Scheme se mantienen más claramente adheridos a los principios funcionales, pero con bibliotecas estándar y construcciones más completas para el desarrollo de aplicaciones.
El manejo de cantidades masivas de datos están llevando a un pico de interés en la programación funcional. No dejen pasar a esta interesante manera de ver al mundo - Puede costar algo de trabajo ajustar nuestra mente para pensar en términos de este paradigma, pero los resultados seguramente valdrán la pena.

AttachmentSize
As printed in the magazine (page 1)990.48 KB
As printed in the magazine (page 2)982.7 KB

Los juegos: Clave para el desarrollo del cómputo

TitleLos juegos: Clave para el desarrollo del cómputo
Publication TypeMagazine Article
Year of Publication2012
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number36
Pagination50-51
Date Published05/2012
Type of ArticleColumn
ISSN1870-0888
Full Text

En el principio era el tiro parabólico

El desarrollo de juegos está relacionado con el desarrollo del cómputo prácticamente desde sus inicios. A pesar de que durante décadas las computadoras estaban al alcance únicamente de algunas grandes (y muy serias) instituciones militares y académicas, ya desde la década de 1940 hubo acercamientos lúdicos a diversos temas con fines de investigación: En 1947, Thomas T. Goldsmith Jr. y Estle Ray Mann diseñaron un primitivo sistema (controlado por una computadora de únicamente ocho bulbos) que mostraba en una pantalla tipo televisión la trayectoria descrita por misiles, cuyos parámetros dependían de la posición de varias perillas. Este "juego" no implementaba lógica alguna de detección de colisiones: El usuario colocaba una plantilla con su objetivo sobre la pantalla. Y podríamos imaginar las hipotéticas discusiones de los niños acerca de si dió en el blanco o se pasó apenitas (hipotéticas, claro, porque el sistema, si bien fue patentado con tal fin, nunca llegó al mercado).
Este primer juego era prácticamente un desarrollo natural, si tomamos en cuenta que las primeras computadoras electrónicas funcionales fueron creadas durante la segunda guerra mundial precisamente para hacer cálculos de trayectorias balísticas. Pero no deja de llamar la atención que uno de los juegos que más se asocia con el éxito de las aplicaciones en plataformas móviles, Angry Birds de la compañía finlandesa Rovio Mobile (comercializado en 2009 — ¡60 años más tarde!) sigue siendo básicamente un juego de tiro parabólico, aderezado con elementos gráficos y humorísticos, y con un sinfin de nuevos niveles y actualizaciones.

¡Y en Cambridge se juega así!

Pocos años más tarde, en 1952, Alexander S. Douglas escribió una versión gráfica del juego del gato (muy atinadamente llamada OXO) como proyecto para su tesis doctoral de interacción hombre-máquina en la Universidad de Cambridge, en una época en que no existían aún los dispositivos de entrada y salida (teclados y pantallas) que hoy damos tan por sentado, modo de interacción que apenas comienza a sentir presión de cambio tras cerca de 50 años.
Para 1959 aparecieron los primeros juegos gráficos en el MIT: Otra implementación del gato y el ratón en el laberinto. Estos juegos eran controlados por una pluma lumínica, con una forma de interacción, aunque salvando las distancias que más de 40 años ponen en el medio, muy similar a la táctil, que se ha puesto de moda en dispositivos móviles.

Jaque al rey: Persiguiendo la inteligencia artificial

Otro de los grandes hitos del desarrollo del cómputo que fueron marcados a través de los juegos es una gran subrama de la inteligencia artificial que llevó al diseño de incontables algoritmos de exploración de árboles de decisión con demasiados estados posibles para una búsqueda exhaustiva: A diferencia del gato, donde hay un máximo de 26,830 juegos posibles, la explosión combinatoria de posibilidades en el ajedrez, y la importancia de seguir una estrategia con un horizonte a varios movimientos. Si bien ya ha quedado demostrado que jugar ajedrez no demuestra inteligencia, buscar cómo enfrentarse a un oponente humano con cierto grado de éxito sí marcó grandes hitos en el desarrollo de esta importante disciplina.
En 1950, Claude Shannon publicó el artículo "Programming a Computer for Playing Chess" en la revista "Philosophical magazine". En 1951, Dietrich Prinz presentó un programa capaz de encontrar si era posible llegar a un mate en dos jugadas (un gran logro, dados los límites de la memoria a esas alturas). Para 1958, Alex Bernstein programó un jugador de ajedrez capaz de llevar a cabo un partido completo, aunque bastante fácil de vencer.
Y desde ahí, continuó el perfeccionamiento de los jugadores automatizados de ajedrez, hasta que en 1997 IBM alcanzó el hito de derrotar al campeón mundial en esa época, Gary Kasparov, con su computadora Deep Blue. Y cabe mencionar que, si bien el motor que animó a la exploración y desarrollo de técnicas
automatizadas para jugar ajedrez como parte del avance de la inteligencia artificial, esto no significa que Deep Blue sea más inteligente que Kasparov o, de hecho, que sea calificable de inteligente: El hito que se logró es optimizar un algoritmo de búsqueda específico a un problema dentro de un campo con un espacio de posibilidades que puede considerarse efectivamente infinito.
Si les interesa leer específicamente acerca del desarrollo del ajedrez como disciplina computacional, les sugiero visitar http://chessprogramming.wikispaces.com/.
Para cerrar este apartado: Otra razón que da especial importancia al ajedrez dentro del listado que estoy presentando es que, de entre los juegos primigenios, éste es el primero en el que la computadora asume un rol activo: No se limita a presentar el tablero, llevar el estado del juego o asegurarse de que los jugadores efectúen movidas legales, sino que es el primer intento que se hace de sobrepasar competitivamente al humano, colocándolo en el lugar del contrincante.

Gráficas, redes... ¡A matar marcianitos!

En la década de 1960, las computadoras proliferaron en las universidades, y cada vez más, ya no eran sólo los profesores quienes podían utilizarlas, sino que los alumnos comenzaron a tener acceso y, obviamente, llegó un gran influjo de nuevas ideas. Para 1961, los alumnos del MIT Martin Graetz, Steve Russell y Wayne Witanen crearon el primer juego con uno de los temas más recurrentes de esta categoría: La guerra en el espacio, precisamente con el juego «Spacewar!» — Y en este caso, a diferencia de los mencionados anteriormente, lo hicieron puramente por diversión, para aprender a programar la unidad gráfica vectorial de la computadora DEC PDP-1 recién adquirida por su universidad.
Spacewar! era un juego hecho para dos jugadores que se enfrentaban en un duelo espacial, con interacción en tiempo real, aunque necesariamente frente a la misma consola. Este juego llegó a ser tan popular que se convirtió en uno de los programas empleados como demostración por el personal de DEC.
Paralelamente, eran cada vez más comunes los sistemas de tiempo compartido, donde varios usuarios podían sentarse cada uno frente a su propia terminal y usar la misma computadora. Estas computadoras además ofrecían normalmente la capacidad de comunicarse entre sesiones. No tardaron en aparecer los primeros juegos multijugador, en los que cada uno de los participantes asumía un rol distinto. En 1971 fueron desarrollados juegos como Star Trek o Baseball, en que los participantes tenían que actuar como equpios.
Los primeros juegos de acción multijugador con perspectiva 3D en primera persona (First-person Shooters) llegaron en 1974: Spasim (Space Simulator), en los sistemas PLATO de la Universidad de Illinois, y Maze War, en el centro AMES de Investigación de NASA en California.
Y hacia mediados de los 1970, ya con Internet floreciendo entre las principales universidades de Estados Unidos, comenzaron a aparecer varios MUDs, mundos en línea de aventuras interactivas, verdaderamente multijugador, presentando prácticamente todos los elementos que esperaríamos hoy de los juegos en plataformas de interacción social — Cierto, acorde a la tecnología disponible, pero con niveles de interacción social muy cercanos a los que conocemos hoy.

El BBS: Las redes para el resto de nosotros

Ya en los 1980, tras la explosión de la revolución de las computadoras personales, pero mucho antes de la masificación del acceso a Internet, grupos de aficionados de todo el mundo comenzaron a conectarse entre sí con los medios que la tecnología ofrecía: Comenzaron a aparecer Sistemas de Boletín Electrónico (Bulletin Board Systems o BBSes), computadoras personales de entusiastas conectadas a una línea telefónica, programadas para recibir llamadas de quien quisiera pasar un rato por ahí, para platicar en los foros, intercambiar archivos — O participar de los juegos multijugador, aunque en este caso, dado que las conexiones eran telefónicas, casi todos eran con una interacción basada en turnos.
No puedo dejar de mencionar a los BBSes dado que, hacia principios de los 1990, fui operador de uno de los aproximadamente 20 BBSes que hubo en la Ciudad de México por aquellos días. Llegamos a tener comunidades vibrantes, de aproximadamente mil usuarios, que poco a poco fuimos migrando a Internet. Algunos de los juegos BBSeros, como el TradeWars 2002, reaparecieron años más tarde en Internet, aunque manteniendo en su formato original basado en texto en una terminal de 80×25 caracteres.
Como en tantos otros casos, en el campo de los juegos por computadora el verdadero desarrollo e inovación se dio cuando no había aún referentes, en las primeras décadas. Y aunque el mundo de los juegos parece compeltamente distinto hoy de lo que era hace 5, 10 o 20 años, la principal diferencia es el uso de gráficos y sonido, o la capacidad de almacenamiento (y por tanto, de interacción) a disposición del usuario, no las ideas principales.
Hemos, a últimos años, visto muy interesantes cambios en la forma de interacción, con los controles basados en acelerómetros (Nintendo Wii) o en reconocimiento de imágenes (Kinect). Queda mucho por explorar, por inventar. Y dado cómo han ido de la mano el avance del cómputo y de los juegos, espero que los lectores de esta revista inyecten nueva vida y nuevas ideas en este campo. Estas ideas indudablemente terminarán alcanzando a nuestra disciplina completa.

AttachmentSize
Versión impresa — Primera página1.17 MB
Versión impresa — Segunda página1.23 MB

Voto Electrónico, 2012

TitleVoto Electrónico, 2012
Publication TypeMagazine Article
Year of Publication2012
AuthorsWolf G
MagazineSoftware Gurú
Issue Number37
Pagination44,45
Date Published08/2012
ISSN1870-0888
URLhttp://sg.com.mx/revista/voto-electr%C3%B3nico-2012
Full Text

¿Más acerca de votaciones? Sí, escucho el clamor de todos nuestros lectores, después de un proceso electoral más, de haber nuevamente soportado meses de saturación de candidatos en los medios. Sin embargo, este es el momento justo para analizar una importante parte del proceso electoral en la cual los desarrolladores de software, expertos en seguridad y administradores de sistemas podemos ejercer influencia sobre el rumbo que sigue el país — Y darnos el lujo de ignorar nuestro rol de profesionales hablaría muy mal de cada uno de nosotros. Es por esta razón que presento esta actualización de estado y reflexión acerca de lo que puede esperarle a nuestro país de avanzar las propuestas de adopción del voto electrónico.
Los lectores asiduos de Software Gurú podrán recordar que abordamos ya este tema en el número 27 (febrero del 2010)1. Desde entonces, tuve oportunidad de participar en algunas publicaciones2 en las que expliqué los puntos básicos acerca de por qué toda implementación que pueda hacerse de voto electrónico, sin importar las mejores intenciones o incluso la pericia técnica del equipo que entregue una solución, no hay manera de que ésta resulte más confiable y garantice mejor cuidado de los derechos del votante que una revisión hecha por humanos de votos emitidos en papel.

1 Urnas electrónicas

Cuando nos hablan del voto electrónico, casi siempre pensamos directamente en las urnas electrónicas, estaciones de propósito específico diseñadas y configuradas para recibir directamente cada uno de los votos de los electores. Sus proponentes argumentan a su favor principalmente por tres razones: Reducción de costos, tiempo de entrega de resultados y mayor confiabilidad en el proceso. Estos tres puntos, como lo explico en los artículos citados anteriormente, se vienen abajo incluso ante una revisión somera del tema.
En México, el tema de las urnas electrónicas no nos resulta nuevo. Los primeros intentos fueron pilotos limitados en el Distrito Federal, en el año de 2003, y en Coahuila, en 2005, para las elecciones locales. En ambos casos, las urnas fueron desarrolladas en casa, y aplicadas a muy pequeña escala.
Para Coahuila, en 2008 la experiencia se repitió en 11 municipios. Las urnas se emplearon en 10 de ellos, pero en San Buenaventura, los partidos PAN, PANAL y PT impidieron su implementación dado que, argumentaron podría resultar fraudulenta3.
Una muy extraña característica del voto en Coahuila es que, para ”asegurar” que todos los votos correspondieran con la voluntad ciudadana, los votantes tenían que emitirlo por vía electrónica y firmar el comprobante emitido por la urna, depositándolo en una segunda urna para el eventual caso de un recuento. Esto, obviamente, viola al principio de la secrecía del voto, y permite el control corporativo o la compra del voto.
En el Distrito Federal, tras años de aparente silencio, el Instituto Electoral local (IEDF) intentó implementar urnas electrónicas de
manufactura industrial. Tras haber firmado contrato con la empresa Pounce Consulting para la adquisición de 1000 urnas electrónicas, a mediados de abril tomó la decisión de rescindirlo4 por demoras injustificables en la entrega de los equipos, así como por 28 fallas como:

…Ensamblados incompletos, chapas trabadas, ranuras abiertas en el depósito de votos, micas transparentes, bases derrapantes, puertos extraíbles sin protección, compartimiento del cable sin tapa y carga lenta de la batería.

En este caso, lo destacable es que, si bien grupos de académicos de la UNAM y el IPN localizaron estas 28 fallas, lo que verdaderamente detuvo a la implementación de la urna electrónica fue la demora en la entrega de los equipos. Eso se traduce en que, muy probablemente, el IEDF continuará intentando implementar urnas electrónicas — Y nosotros como sociedad tenemos que mantenernos atentos.
Por último, veamos el caso de Jalisco: El Instituto Electoral y de Participación Ciudadana (IEPC) aprobó que para la votación local se empleen urnas electrónicas en los distritos 1 y 17 y en el municipio
de Gómez Farías, para un 11% del padrón total. Tras una licitación muy cuestionada5, la empresa ganadora fue también Pounce Consulting. En este caso, al igual que en el DF, la empresa demoró la entrega de las urnas en casi seis semanas, apenas entregando a tiempo cuando ya se analizaba la cancelación del contrato.
Previo a la elección, se realizaron cinco simulacros para presentar la urna a la población, y para ir corrigiendo los problemas que presentaran — Al que más seguimiento se le dió fue al que afectaba la secrecía del voto (podía verse el testigo impreso de los votantes anteriores). Las variaciones eléctricas han llegado causaron, al menos en una ocasión, impresión descontrolada de votos, y en los simulacros se han reportado urnas pre-cargadas6.
El modelo de urna empleado en Jalisco incluye no sólo el acopio de la votación, sino que la transmisión de los resultados por vía de telefonía celular a las cabeceras distritales. Esto, si bien está protegido por criptografía, abre nuevas vías de ataque: No sólo cada una de las urnas se conecta a la red celular (aunque sea sólo por breves instantes al cerrarse la votación), sino que los equipos centrales deben estar a la escucha. Esto permite no sólo un ataque que comprometa el sentido de los votos emitidos, sino que abre la puerta para ataques negación de servicio.
Un problema reportado en cerca del 20% de las urnas fue, precisamente, la falta de cobertura celular. El distrito 1 de Jalisco cubre la parte norte del estado, una zona de profundas barrancas y de una gran cantidad de poblados de muy difícil acceso — Y que no tienen cobertura de telefonía celular. El planteamiento de realizar las votaciones con urnas que contemplan la transmisión de datos por esta vía no sólo revela una profunda desconexión respecto a la población objetivo a cubrir, sino que –al presentar distintas vías para que se lleve a cabo el acopio de la información– abre un vector más para el ataque, ya no tanto técnico sino que a través de la ingeniería social.
Un punto alarmante de la implementación en Jalisco es el traslado de la figura legal de lo que constituye un voto. Si bien las urnas empleadas emiten testigos para asegurar la posibilidad de un recuento (cabe mencionar, no es universalmente aceptado que esto sea garantía suficiente), el documento de validez legal no es el papel testigo sino que el estado interno de la memoria de la urna electrónica. En caso de presentarse un recuento, citando al consejero electoral Carlos Martínez Maguey, ”existe la posibilidad de que […] se puedan contar los testigos de voto, no es vinculante el resultado del testigo de voto, pero siempre nos dará el mismo resultado que la base de datos”. Los votos están en la memoria, y el papel únicamente da fé de ello. Esto es, en Jalisco se ha legalizado la desmaterialización del voto. Y si bien el proceso electoral mexicano –como siempre– todavía da para muchas impugnaciones, hay reportes de inconsistencias7 entre el números de votantes del IFE y del IEPC en la misma casilla.

2 Voto no presencial

México es un país fuertemente expulsor de migrantes, principalmente a los Estados Unidos, pero a muy diversos puntos del mundo. Parte importante de los migrantes mexicanos, además, están en una situación de precariedad legal que les hace imposible registrarse como residentes legales o desplazarse libremente en su país de residencia, por lo cual el modelo que requiere registrarse y desplazarse hasta una embajada o consulado no aplican. Se han planteado dos modalidades para realizar el voto no presencial: El voto en línea y el voto postal.
Antes de analizar estas alternativas, es muy importante explicitar a lo que renunciamos con ambas: Perdemos la garantía de que el votante sea verdaderamente quien dice ser. En caso del voto postal, es bastante probable que el votante correcto reciba el paquete con las boletas en la dirección indicada, pero mantiene la necesidad de registrar una dirección postal permanente, lo cual rompe con el planteamiento de origen.
En el caso del voto electrónico, la perspectiva es peor aún, porque si bien el potencial elector podía registrarse presentando los datos de su credencial electoral, las instrucciones y contraseña le son enviadas por correo electrónico. La confiabilidad y la confidencialidad de los proveedores de servicios de correo electrónico, especialmente de los gratuitos (que son por mucho los más frecuentemente utilizados) no garantizan que sea genuinamente el votante quien los revisa, especialmente en el caso de la población con menor dominio de la tecnología. Lo que es más: En un escenario como el ampliamente impugnado en las elecciones recién ocurridas, la compra de votos se vuelve trivial: Basta con que el votante entregue su contraseña en los días previos al operador electoral, y que éste verifique el poder votar por su propio partido, para la entrega de los recursos económicos.
En una plática informal con personal del IEDF, me indicaron estar al tanto de esta realidad, pero –dada la cantidad de población registrada– era un riesgo aceptable: Para este año, hubo 10,786 empadronados — Únicamente el 0.13% del padrón, pese a la grandísima campaña en medios. De ellos, apenas 4192 optaron por hacerlo en línea.

3 Conclusiones

Si bien he definido mi postura al respecto desde hace tiempo ya, he buscado honestamente expertos en seguridad en cómputo independientes (no asociados con empresas vendedoras de sistemas del rubro) dispuestos a argumentar a favor del voto electrónico, y honestamente no he encontrado a ninguno. Sin embargo, el voto electrónico tiene un atractivo desde un punto de vista político — y hay un gran negocio en ofrecer soluciones basadas en él. Nosotros, como profesionales del ramo, más que buscar la oportunidad de negocio espero sepamos responder con los argumentos que hacen del voto electrónico un verdadero peligro para la democracia.
Los vendedores de urnas tienden a argumentar que ha habido elecciones exitosas con voto electrónico, y justifican los fracasos indicando que fueron fallos puntuales de implementación. Sin embargo, nuestro punto es que es precisamente imposible hacer una implementación tan segura y confiable como lo que plantean reemplazar.
En una prueba piloto, o incluso en una primera implementación, es muy poco probable que se presente un ataque. En ambos casos, estaríamos hablando de implementaciones muy controladas, en que prácticamente si se registra una falla es por un error más que por un ataque.
Desde hace algunos meses hemos estado alimentando al Observatorio del Voto Electrónico8. Invito a los interesados a emplearlo como fuente de información, y de unirse a nuestro trabajo de análisis y difusión.

Pies de página:

1 http://sg.com.mx/content/view/919
2 http://seminario.edusol.info/seco3/pdf/seco3_apend3.pdf
3 http://www.eluniversal.com.mx/notas/631827.html
4 http://www.eluniversal.com.mx/ciudad/111073.html
5 http://votodigital.wordpress.com/2011/11/11/notas-de-una-escandalosa-licitacion-que-arriesga-el-voto-electronico/
6 http://www.lajornadajalisco.com.mx/2012/05/15/todavia-es-viable-aplicar-el-voto-electronico-en-el-estado-figueroa/
7 http://www.informador.com.mx/jalisco/2012/388153/6/el-iepc-desmiente-irregularidades-en-votacion-electronica-de-distrito-1.htm
8 http://evoto.iiec.unam.mx/

AttachmentSize
PDF94.64 KB

México, el voto electrónico y el 2012

TitleMéxico, el voto electrónico y el 2012
Publication TypeMagazine Article
Year of Publication2012
AuthorsWolf G
Refereed DesignationNon-Refereed
Magazine.Seguridad: Cultura de prevención para TI
Issue Number14
Pagination27-30
Date Published08/2012
URLhttp://revista.seguridad.unam.mx/numero-14/m%C3%A9xico-el-voto-electr%C3%B3nico-y-el-2012
Full Text

México es un país que, a lo largo de su historia, ha sufrido fraudes y otros malos manejos electorales, por medio de diferentes esquemas. Los mexicanos frecuentemente nos sentimos autoridades mundiales en este tema; la constante respecto a nuestras autoridades electorales ha sido más de duda y cuestionamiento que de confianza. Hubo un breve periodo, los últimos años de la década de los 1990 y los primeros de los 2000, en que parecía que se consolidaba una institución sólida y confiable, pero las dudas –fundadas o no– que surgieron tras la elección del 2006 devolvieron a las autoridades electorales a los niveles desconfianza tradicional que han sostenido a lo largo de buena parte de nuestra historia como nación independiente.
Y un reclamo muchas veces escuchado es que, dado que es imposible confiar en los individuos, corruptibles por naturaleza, la responsabilidad del escrutinio de los votos debería recaer en un sistema computarizado, siempre limpio, eficiente y honesto.

Índice

1 ¿Qué hace una urna electrónica?

Las urnas electrónicas se han propuesto desde hace mucho tiempo ya, y muchos países (o jurisdicciones menores) las han adoptado.
En el corazón de todas las propuestas de voto electrónico está la urna electrónica. Esta es básicamente una computadora, con una interfaz usuario limitada para sólo permitir un conjunto específico de operaciones, construida dentro de una caja o maletín que dificulten el acceso a cualquiera de sus componentes fuera del expresamente autorizado, y encargado de recibir cada uno de los votos, convirtiéndolos en información almacenada de forma electrónica. Por medio de un procedimiento previamente diseñado, las autoridades electorales pueden indicarle que deje de recibir votos, y entregue los totales que cada una de las opciones recibió.
Las primeras urnas electrónicas que cumplen con esta definición, las llamadas DRE voting machines (Direct-Recording Electronic, máquinas de voto electrónico de grabación directa) fueron puestas en práctica ampliamente hacia 1996, y al día de hoy, la totalidad de votantes de países tan grandes como la India y Brasil, y amplios segmentos de otros países como los Estados Unidos, votan de esta manera.

2 La confianza y los aguafiestas

No perdamos de vista que si una cosa caracteriza al gremio de los desarrolladores de software es la cantidad de errores (tanto accidentales como, lo que es mucho más peligroso, inducidos) que pueden aparecer en un programa. El mero hecho de que exista un área de especialización tan importante como la seguridad informática lo hace patente: La complejidad hasta de los sistemas más sencillos hace imposible asegurar con toda certeza que una computadora haga lo que que debe hacer.
Para ilustrarlo: Pocas computadoras en el mundo corren hoy sin antivirus. Estos programas se hicieron necesarios dadas las grandes deficiencias de diseño que tuvo el sistema operativo más popular del mundo ante la realidad de estar hoy permanentemente conectados a una red hostil. Y hasta corriendo los sistemas más seguros, es necesario estar al tanto de todas las actualizaciones y notas de seguridad si queremos confiar en que nuestra computadora responde únicamente a nuestras órdenes, y lo hace de forma confiable.
Incluso ante el mismo programador, como proféticamente lo demostró en 1984 Ken Thompson al aceptar el premio Turing (reconocido en nuestro campo como el premio Nóbel de la Ciencia de la Computación) con el artículo /Reflexiones acerca de la confianza en la confianza/1 , un programador siempre confía ciegamente en un conjunto de programas sobre de los cuales construye (compilador, ligador, sistema operativo), y por tanto, un atacante determinado sólo tiene que bajar lo suficiente para plantar un troyano.

3 Desconfiando del DRE… Y de lo demás

Expertos en seguridad informática no tardaron en señalar diversos expertos diversas fallas elementales en el voto DRE; el principal, el de la confiabilidad. Si los votos únicamente son grabados en la memoria electrónica, ¿cómo puede asegurarse que reflejen fielmente el sentido del voto de cada individuo? O puesto de otro modo, ¿cómo podría asegurarse un recuento de los votos en caso de ser nacesario?
La respuesta no se hizo esperar: A cada voto emitido, sería impreso un comprobante o testigo del voto, mismo que serviría para contar los votos manualmente en caso de impugnación. Este esquema es conocido como VVPAT (Voter-verified paper audit trail, Rastro auditable en papel verificado por el votante).
Esto, si bien ha sido aceptado por numerosos sistemas electorales en el mundo, sigue sin ser suficiente. Como sugiere Federico Heinz2, hay varios esquemas que podrían reventar una elección con este planteamiento. Por ejemplo, si las personas interesadas en sabotear una urna, tras votar, reclaman ante la mesa de autoridades indicando que la urna registró un voto contrario a lo que le solicitaron, podrían llevar a que se anulen todos los sufragios emitidos por dicha urna, dado que son potencialmente ilegítimos.
Por otro lado, podría presentarse nuevamente el escenario que se dió en la ciudad de Nueva York en 20103: Al calentarse las urnas electrónicas, emitían votos aleatorios por error. Se estima que esto puede haber invalidado hasta el 30% de los votos efectivos de algunas
mesas.

4 La futilidad de los simulacros

Este 2012, el principal proyecto de implementación de voto electrónico en México será en las elecciones locales del Estado de Jalisco. Uno de los muchos puntos preocupantes de este ejercicio es que, como pruebas previas a la instalación de más de mil urnas electrónicas en dos distritos electorales y un municipio, las únicas pruebas de confiabilidad disponible para ser analizada públicamente son cinco simulacros.
¿Qué puede comprobarse en un simulacro? Que, en el mejor de los mundos posibles y sin ninguna intencionalidad maligna, las urnas funcionen como dicen funcionar. En caso de haber algún componente malicioso en las urnas, es del total interés de quien lo haya sembrado que no cause ningún comportamiento inusual (para no perder su agente encubierto sin obtener la ventaja que le llevó a introducirlo en primer lugar). Un simulacro busca demostrar que, bajo condiciones controladas, la elección no colapsa. Y lo peor del caso es que en este caso, 3 de los 4 simulacros que habían ocurrido hasta la fecha en que este documento fue escrito registraron fallos diversos que hacían –ya a menos de dos meses del proceso electoral– replantearse si se emplearían o no4. En el Distrito Federal, la implementación de urnas electrónicas licitadas a la misma empresa que las provee en Jalisco fue rescindida, en parte, por habérsele encontrado 28 fallas5.
¿Un simulacro exitoso aseguraría que no habrá fallas el día de la elección? ¡De ninguna manera!

5 Conclusión

Por restricciones de espacio, en este texto apenas me ha sido posible arañar algunos de los puntos más notorios del voto electrónico, y de por qué, comprendiendo puntos básicos de seguridad en cómputo y estando conscientes de la gran importancia que tiene el voto dentro de un sistema democrático representativo como el que aspiramos tener en nuestro país, resulta imposible confiar en que las urna electrónica resuelva nuestros problemas de confianza — Muy por el contrario.
Se ha hablado de emplear al voto electrónico para resolver otros problemas, como el del costo o la agilidad de la transmisión de resultados. Estos puntos pueden desmenuzarse y descartarse con todavía mayor facilidad que el aquí presentado.
Si este breve artículo resultó de su interés, les invito a leer el artículo publicado a fines del 20116 , así como el abundante material que al respecto ha generado la Fundación Vía Libre (Argentina)7, destacando el libro Voto electrónico: los riesgos de una ilusión, publicado en 20098.

Pies de página:

1 Reflections on Trusting Trust, Ken Thompson, Communications of the ACM, Vol. 27, No. 8, August 1984, pp. 761-763
2 Urnas electrónicas: con imprimir el voto no alcanza, Federico Heinz, Fundación Vía Libre, septiembre de 2010; http://www.vialibre.org.ar/2010/09/12/urnas-electronicas-con-imprimir-el-voto-no-alcanza/
3 Machine Casts Phantom Votes in the Bronx, Invalidating Real Ones: Report, The Empire, mayo de 2012; http://www.wnyc.org/blogs/empire/2012/may/09/reports-find-machine-errors-led-uncounted-votes-2010/
4 Pide diputada que IEPC esté listo a llevar a cabo elección tradicional, Zaira Ramírez, El Informador, 8 de mayo de 2012;
http://www.informador.com.mx/primera/2012/374801/6/pide-diputada-que-iepc-este-listo-a-llevar-a-cabo-eleccion-tradicional.htm
5 Urnas electrónicas tienen 28 fallas: IEDF, Jonathan Villanueva, El Universal, 13 de abril del 2012; http://www.eluniversal.com.mx/ciudad/111073.html
6 Voto electrónico: ¿Quién tiene realmente la decisión?, Construcción Colaborativa del Conocimiento (IIEc-UNAM), Gunnar Wolf, 2011; http://seminario.edusol.info/seco3/pdf/seco3_apend3.pdf
7 Fundación Vía Libre — Voto electrónico http://www.votoelectronico.org.ar/
8Voto electrónico: los riesgos de una ilusión, Fundación Via Libre, 2009; http://www.vialibre.org.ar/wp-content/uploads/2009/03/evoto.pdf

AttachmentSize
Revista .Seguridad - México, el voto electrónico y el 2012 - 2012-09-05.pdf249.44 KB

Programación en la escuela: ¿Para qué?

TitleProgramación en la escuela: ¿Para qué?
Publication TypeMagazine Article
Year of Publication2012
AuthorsWolf G
Refereed DesignationNon-Refereed
MagazineSoftware Gurú
Issue Number38
Pagination50-51
Date Published11/2012
ISSN1870-0888
URLhttp://sg.com.mx/revista/38/programaci%C3%B3n-la-escuela-%C2%BFpara-qu%C3%A9
Full Text

En el número de agosto del 2012 de Software Gurú, Ignacio Cabral Perdomo presentó un interesante artículo titulado «Enseñando a niños a programar: ¿Imposible o una oportunidad?». La respuesta me parece clarísima: Claro que se puede. Esto viene siendo demostrado, con gran
éxito, desde los 1960s, empleando el lenguaje BASIC diseñado por Kemeny y Kurtz, y muy particularmente con el lenguaje Logo, conocido principalmente gracias al trabajo de uno de sus autores, Seymour Papert. El origen del planteamiento de estas tempranas experiencias, sin embargo, me parece radicalmente diferente del planteamiento de Ignacio — Y los argumentos, tanto hace 40 o 50 años como ahora, más convincentes.
El énfasis que presentan las conclusiones de Ignacio apuntan al mercado del desarrollo de cómputo. Cito,

Es muy clara la necesidad de más profesionistas en el área de la Computación y las Tecnologías de Información, en especial en los departamentos de desarrollo de software de diferentes corporaciones pero, desgraciadamente, el interés de los alumnos por carreras de este tipo está reduciéndose de una forma alarmante. Una posible solución es el inculcar desde temprana edad el pensamiento lógico y algorítmico en los niños siguiendo el itinerario de aprendizaje que propongo.

Si bien el artículo refiere que la enseñanza de programación a partir de nivel primaria «ayuda a los chicos a formar ese pensamiento lógico y algorítmico que tanto necesitan», no profundiza en este aspecto, que considero fundamental. ¿Por qué los chicos pueden necesitar un pensamiento lógico y algorítmico?

1 Los hijos de Logo

Soy parte de una minoría afortunada — Y pido disculpas anticipadas si el presente artículo se ve como un viaje a mi anecdotario personal.
Aprendí computación cuando el acceso al equipo de cómputo era extremadamente poco común — Mi primer experiencia fue en la minicomputadora Foonly que había en el IIMAS (UNAM) en 1983, a los 7 años, escribiendo LaTeX con el editor Emacs. Cabe mencionar que el presente artículo, casi 30 años más tarde, lo estoy escribiendo con las mismas herramientas. Tuve acceso a la Foonly gracias a que mi padre trabajaba como investigador en dicho Instituto, y a que tuvo la paciencia de enseñar a su ávido niño ese lenguaje cargado de símbolos y comandos.
Pero creo que mi experiencia con la Foonly se habría mantenido como meramente incidental de no ser porque, uno o dos años más tarde, me inscribieron en IDESE, una de las primeras escuelas de verano dedicadas al cómputo en México. IDESE era una apuesta pedagógica muy interesante; por tres semanas, alternábamos dos horas frente a la computadora con dos horas más con juegos de mesa. Si bien no recuerdo los detalles de la interacción, esta alternancia ilustra claramente cómo veían nuestros instructores su tarea: Llevar a los niños a
emplear sus habilidades cognitivas de una manera más completa.
IDESE derivó de la versión de Logo desarrollado por el MIT para la Apple ][, traduciendo todos sus comandos y mensajes al español. Sólo otra vez, también en los 1980, vi un esfuerzo similar: El hecho por la BBC al traducir el lenguaje BASIC de su BBC Micro para crear el EBASIC. Esto permitía enseñar a los niños a programar la computadora sin preocuparse al mismo tiempo de aprender otro idioma — El caso del EBASIC me resulta notorio porque, con un comando, se podía ver el código escrito en EBASIC en BASIC "normal". Para 1985, me tocó formar parte del taller de computación que se impartía en mi escuela a partir de 4° de primaria. A partir de 1986, estuve inscrito para varios cursos de los Centros Galileo. Tuve la suerte de haber pasado por escuelas muy buenas y muy motivantes, con lo cual a esas tempranas alturas ya estaba decidida mi vocación.
El gran acierto de Logo que lo hizo tan importante como lenguaje educativo fue eliminar las capas de abstracción que debía tener en mente un niño: Si bien el lenguaje permite un desarrollo complejo y formal de programación funcional1, el niño podía ver la concreción de sus programas graficándolos a través de una tortuga, originalmente un robot conectado a la computadora, posteriormente reemplazado por una tortuga en pantalla cuando la tecnología lo permitió. Permitir que el niño viera directa e inmediatamente sus resultados, hace 45 años, resultó un cambio fundamental y un gran motivador.
Cuando Logo fue planteado, así como cuando yo lo aprendí2, no existía el planteamiento de formar a los niños en programación por la gran demanda que dichas habilidades tendrían en la sociedad. La enseñanza de programación era vista como una forma de enseñar pensamento abstracto y algorítmico.
¿Y para qué enseñar pensamiento abstracto y algorítmico si no para formar profesionales que comprendan más fácil los paradigmas de cómputo? Bueno… Citando a un buen amigo, de lo que se trata no es de aprender más que a programar, aprender lo que significa programar. Dicho de otro modo, ¿Para qué se enseñan matemáticas, filosofía, historia o biología? Para formar personas más completas, no sólo en su cultura, sino que en la manera de estructurar el pensamento. Habilidades que indudablemente impactan en su crecimiento como adultos. Y sin poder extrapolar más allá de la experiencia personal, no puede pasarme desapercibido la gran proporción de colegas que me he encontrado de aproximadamente mi edad que pasaron por experiencias formativas similares.

2 La OLPC

Ninguna herramienta dura para siempre, sin embargo, y ni siquiera el gran Logo se salva de la obsolescencia que las nuevas tecnologías van causando. Hoy en día, sería iluso pensar que mover una "tortuga" por la pantalla pudiera impresionar a un niño. Afortunadamente, no han sido pocos los estudios en este campo que se han realizado — El artículo de Ignacio presentó cuatro entornos de programación orientados a la enseñanza en diferentes edades — Scratch, Alice, Greenfoot y BlueJ. Me sorprendió que no presentara a uno de los trabajos más comentados de los últimos años, que tiene un impacto muy medible: El proyecto OLPC (One Laptop Per Child, una computadora por niño)3 , iniciado –al igual que Logo– en el MIT y con el decidido apoyo de Seymour Papert, entre otras muchas personalidades.
La OLPC no es cualquier computadora: Fue planteada como el vehículo sobre del cual correría Sugar4. Yo no tengo experiencia de primera mano con el entorno, por lo cual prefiero dirigir a quienes estén interesados en una descripción más completa al artículo que publicó Werner Westermann5 dentro del libro «Construcción Colaborativa del Conocimiento»6.
En resumen, Sugar es un entorno dirigido a facilitar un aprendizaje construccionista, en que cada alumno debe ir explorando y construyendo su camino por medio de la experiencia personal, lo cual lleva a una mayor apropiación del contenido que cuando éste es dictado. A partir de una interfaz sencilla y una orientación más a actividades que a aplicaciones, y empleando a fondo la colaboración entre todos los alumnos, la computadora se vuelve un actor, un facilitador de la transmisión del conocimiento. Y una característica fundamental de Sugar es que el alumno no sólo puede utilizar las actividades, sino que puede (y está bienvenido a) modificarlas. Las actividades están escritas en Python, un lenguaje de sintaxis limpia y conceptualmente fácil de adoptar.
OLPC fue planteado como un proyecto necesariamente a gran escala: Está planteado para que una computadora sea entregada a cada niño en edad escolar en los países receptores. El proyecto busca además resolver problemáticas específicas de los países menos favorecidos; con ciertas modificaciones al planteamiento inicial, actualmente hay despliegues de OLPC en once países de escasos recursos7.
Y siguiendo con el tono personal que he mantenido en esta ocasión, relato lo que me contó Manuel Kauffman, un desarrollador argentino de Sugar, en una visita que hizo a una escuela en Uruguay: Un niño, de 11 o 12 años, le explicó que prefería editar en texto los iconos de las actividades que iba creando o modificando directamente en un editor de texto, en SVG8 porque le quedaban más limpios que utilizando un editor gráfico.
Este ejemplo habla como pocas cosas de apropiación de la herramienta y de la apreciación estética de la representación en código de un objeto. Hay programadores de larga carrera profesional que son incapaces de desarrollar estas habilidades.

3 Conclusiones

Enseñar a programar a un niño va mucho más allá de transmitirle una habilidad para su futuro profesional. La enseñanza básica no puede basarse sólamente en la transmisión de competencias medibles en el mercado.
Hay, sin embargo, puntos importantes a considerar. Si bien algunos tuvimos la gran suerte de aprender de la forma y en el momento correcto, es una materia con la que muchos se enfrentan con dificultad — El desarrollo de las capacidades de abstracción necesarias para esta materia se produce de forma muy desigual, y la frustración que esta materia puede causar en algunos alumnos puede ser muy grande. Cabe mencionar, claro, que esto mismo se presenta en varias otras materias que forman ya parte de la currícula básica.
Por otro lado, otro punto importante a considerar es la formación de los docentes. Para incorporar una materia a la currícula básica, es necesario contar con un cuerpo docente suficientemente amplio y capacitado, no sólo con las habilidades técnicas sino que pedagógicas. Esto, claro, debe presentarse como un proceso gradual, pero nada indica que sea de fácil resolución.

Pies de página:

1 Logo ha sido descrito como "Lisp, pero sin los paréntesis"
2 Con casi 20 años de distancia — ¡Una verdadera eternidad en el avance de la popularización del cómputo!
3 http://one.laptop.org/
4 http://sugarlabs.org/
5 http://seminario.edusol.info/seco3/pdf/seco3_apend2.pdf
6 http://seminario.edusol.info/seco3/
7 http://one.laptop.org/stories
8 Un lenguaje basado en XML para representar gráficos vectoriales

AttachmentSize
Programacion_en_la_escuela.pdf68.58 KB