May 2009 - Posts
Llegó el nuevo producto de Microsoft, que presentan, no como un buscador, como un engine de búsqueda, sino como un motor de decisiones:
http://www.decisionengine.com
Como empresa gigante, Microsoft se puede dar el lujo de tener un gran equipo de research, y llega el momento en que todo ese conocimiento y esfuerzo se vuelca en algún producto (no siempre).
Yo todavía tengo que probar ese producto, que no está liberado al público. Como muchos productos globales, hoy se anuncian de esta manera, con un video viral, como el de arriba, que no sólo está en el sitio, sino que también está en Youtube, y lo puedo embeber en mis blogs.
A simple vista, es un producto que montado sobre ideas (no implementaciones) de web semántica, apunta a no tener tanto agentes recorriendo y obteniendo información, sino a presentarla y organizarla para que el usuario tenga una experiencia distinta.
Veremos si cumple con la expectativa. Pero es interesante ver cómo la fuente de la información es la propia web. También es interesante notar que la información de la que parte, no estaba pensada para ser consumida de esa forma. Eso es lo que imagino que va a pasar con las ideas de web semántica. Las páginas publicada sólo va a comenzar a contener información semántica, cuando este tipo de aplicaciones se popularicen. Mientras tanto, el “trabajo sucio” de obtener información de los datos de una página, quedará a cargo de las aplicaciones.
No veo que sea una “killer application” para Google. Más bien, como Wikipedia, va a brindar otra experiencia de usuario. Así como hay temas que investigamos con Google, así como habrá otros más estructurados que investigamos partiendo de Wikipedia, habrá consultas, tareas, comparaciones, donde preferiremos (o no) a Bing.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Gracias al trabajo de Federico Boerr y su equipo, tenemos una nueva versión de AjGenesis, escrita para ejecutarse desde .NET Compact Framework:
http://ajgenesiscf.codeplex.com/
Esta versión sólo usa las características soportadas por el Compact Framework. Entonces, no tenemos todas las del proyecto original. Por ejemplo, sólo usa las características de reflections soportadas por CF, una de las que queda fuera es la capacidad de crear una instancia con pasando parámetros en el constructor. Pero podemos compilar AjGenesis como .DLL, e invocarla desde un programa nuestro, usar templates, tareas y AjBasic. El código publicado por Federico contiene un programa de uso de ejemplo.
Más información sobre el proyecto original:
http://ajgenesis.codeplex.com
http://ajlopez.wordpress.com/category/ajgenesis/
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Leo hoy este fragmento en el post
Why I'm The Best Programmer In The World*
At the 1972 Turing Award lecture, Edsger Dijkstra delivered a paper titled �The Humble Programmer.� He argued that most of programming is an attempt to compensate for the strictly limited size of our skulls. The people who are best at programming are the people who realize how small their brains are. They are humble. The people who are the worst at programming are the people who refuse to accept the fact that their brains aren�t equal to the task. Their egos keep them from being great programmers. The more you learn to compensate for your small brain, the better a programmer you�ll be. The more humble you are, the faster you�ll improve.
Les recomiendo ese "paper” de E.W.Dijkstra:
EWD340.PDF
Algunos pasajes
…. in 1957, I married and Dutch marriage rites require you to state your profession and I stated that I was a programmer. But the municipal authorities of the town of Amsterdam did not accept it on the grounds that there was no such profession. And, believe it or not, but under the heading "profession" my marriage act shows the ridiculous entry "theoretical physicist"!
Era lo que estubia Dijkstra antes de convertirse en el primer programador alemán holandés.
there is yet another circumstance that had a profound influence on the programmer's attitude to his work: on the one hand, besides being unreliable, his machine was usually too slow and its memory was usually too small, i.e. he was faced with a pinching shoe, while on the other hand its usually somewhat *** order code would cater for the most unexpected constructions. And in those days many a clever programmer derived an immense intellectual satisfaction from the cunning tricks by means of which he contrived to squeeze the impossible into the constraints of his equipment.
Algo que Dijkstra ataca en el resto del paper.
In the beginning there was the EDSAC in Cambridge, England, and I think it quite impressive that right from the start the notion of a subroutine library played a central role in the design of that machine and of the way in which it should be used. It is now nearly 25 years later and the computing scene has changed dramatically, but the notion of basic software is still with us, and the notion of the closed subroutine is still one of the key concepts in programming. We should recognise the closed subroutines as one of the greatest software inventions; it has survived three generations of computers and it will survive a few more, because it caters for the implementation of one of our basic patterns of abstraction.
Nadie sabía bien que se requería de un lenguaje de programación. Lo explica Dijsktra con un caso:
The second major development on the software scene that I would like to mention is the birth of FORTRAN. At that time this was a project of great temerity and the people responsible for it deserve our great admiration. It would be absolutely unfair to blame them for shortcomings that only became apparent after a decade or so of extensive usage: groups with a successful look-ahead of ten years are quite rare! In retrospect we must rate FORTRAN as a successful coding technique, but with very few effective aids to conception, aids which are now so urgently needed that time has come to consider it out of date. The sooner we can forget that FORTRAN has ever existed, the better, for as a vehicle of thought it is no longer adequate: it wastes our brainpower, is too risky and therefore too expensive to use. FORTRAN's tragic fate has been its wide acceptance, mentally chaining thousands and thousands of programmers to our past mistakes. I pray daily that more of my fellow-programmers may find the means of freeing themselves from the curse of compatibility.
Pero había joyitas apareciendo:
The third project I would not like to leave unmentioned is LISP, a fascinating enterprise of a completely different nature. With a few very basic principles at its foundation, it has shown a remarkable stability. Besides that, LISP has been the carrier for a considerable number of in a sense our most sophisticated computer applications. LISP has jokingly been described as "the most intelligent way to misuse a computer". I think that description a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts.
La aparición de un lenguaje documentado, con conducta definida, y hasta manual, la nota con Algol (recuerdo mi paso por Algol-W):
The fourth project to be mentioned is ALGOL 60. While up to the present day FORTRAN programmers still tend to understand their programming language in terms of the specific implementation they are working with —hence the prevalence of octal and hexadecimal dumps—, while the definition of LISP is still a curious mixture of what the language means and how the mechanism works, the famous Report on the Algorithmic Language ALGOL 60 is the fruit of a genuine effort to carry abstraction a vital step further and to define a programming language in an implementation-independent way.
Pero también sufrí al PL/I, que me pareció en su tiempo que se iba de rumbo, y así lo demostró la historia:
Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit. I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language —our basic tool, mind you!— already escapes our intellectual control.
Más fragmentos:
the programmer only needs to consider intellectually manageable programs, the alternatives he is choosing between are much, much easier to cope with
as soon as we have decided to restrict ourselves to the subset of the intellectually manageable programs, we have achieved, once and for all, a drastic reduction of the solution space to be considered
Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness.
…
We all know that the only mental tool by means of which a very finite piece of reasoning can cover a myriad cases is called "abstraction"; as a result the effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer. In this connection it might be worth-while to point out that the purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.
…
the tools we are trying to use and the language or notation we are using to express or record our thoughts, are the major factors determining what we can think or express at all! The analysis of the influence that programming languages have on the thinking habits of its users, and the recognition that, by now, brainpower is by far our scarcest resource, they together give us a new collection of yardsticks for comparing the relative merits of various programming languages.
…
I could even go one step further and make an article of faith out of it, viz. that the only problems we can really solve in a satisfactory manner are those that finally admit a nicely factored solution. At first sight this view of human limitations may strike you as a rather depressing view of our predicament, but I don't feel it that way, on the contrary! The best way to learn to live with our limitations is to know them.
…
Ultima frase
We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Primer post desde nueva notebook, gracias a Martin Salias
Hacía un tiempo había perdido el rasto de este video:
una propaganda real de la empresa EDS.
¿Quién de nosotros no se reconoce de alguna forma en ese video? :-)
De vez en cuando, se toma este video como parodia en contra del desarrollo ágil. Pues bien, sería así, una parodia, si nosotros construyéramos aviones. El problema, es que lo que construimos, nadie lo conoce bien al principio, apenas durante. Ese es un gran problema en nuestra profesión. Todos los sistemas de proyectos, camino crítico y demás, nacieron en medio de productos altamente definibles. Muchos sistemas de software, aún no alcanzaron ese grado de definibilidad digamos previa. No construimos ni casas, ni aviones, ni puentes, ni misiles Polaris. Es otra cosa.
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
Paving my new notebook (thanks to @MartinSalias)
Gracias a un tweet de @maraoz, me enteré que estaba MatBaires 09, Festival Matemático, el fin de semana pasado, en el Centro Cultural Recoleta, acá en Buenos Aires. Me perdí varias conferencias (el bueno de @maraoz envió el mensaje el sábado), así que no pude asistir a ver a Gregory Chaitin, Guillermo Martinez, y a otros, como John Allen Paulos. Pueden ver el programa y los temas en:
http://www.festivalmatematica.gov.ar/home09/web/es/index.html
(recuerdo haber trabajado en los ochentas, con el intérprete Lisp que Chaitin había escrito en Fortran, en la Universidad de Buenos Aires, yo fui lo bastante nerd como para reimplementarlo en assembler de 8080…. ;-)
Una charla a la que pude asistir fue:
¿Puede una computadora aprender a componer música?
Por Pablo Rodríguez Zivic.
Al escuchar una pieza musical, uno es capaz de extraer información acerca del estilo, la métrica, y tal vez teniendo mayor conocimiento sobre teoría musical, cuestiones relacionadas con la armonía y el contrapunto. Todo músico es influenciado por otros músicos debido a diferentes razones, y esta capacidad de ser influenciado está estrechamente relacionada con la capacidad de extraer información útil para la composición a partir de escuchar lo que otros ya han hecho. Ahora, la pregunta es: ¿es posible darle a una computadora un conjunto de piezas musicales y que esta sea “influenciada” por este conjunto para componer nueva música?
(ver la actividad del domingo 10 de Mayo en http://www.festivalmatematica.gov.ar/home09/web/es/events/index/v/date/20090510.html#)
Pablo está trabajando en Popego, que yo sepa, y es compañero entonces de @santisiri y @scoffey, los que conocí personalmente ahí, entre el público. Popego está aplicando técnicas de inteligencia artificial, creo que son los de Zauber quienes las programan… Pero vayamos al tema de la conferencia.
Pablo se manejó bien, hubo bastante asistencia, y comenzó a tiempo. Excelente sonido, que fue aprovechado por Pablo para presentar el trabajo que está realizando para su tesis, comenzado hace apenas unos meses.
Primero planteó qué es una computadora, qué es aprender y qué es componer música.
A la primera pregunta, presentó que una computadora es un programa. Remontó todo al cálculo lambda (si, como gran parte de la humanidad, NO ESTAN suigiendo mis posts, lean:
Notas sobre el Cálculo Lambda
Presenting AjLambda, lambda calculus in C#
Presentando AjLambda: implementación de Cálculo Lambda en C#
)
Pablo hasta usa la misma foto de Alonzo Crurch que uso en mis charlas… :-)…. y luego comentó su equivalencia con las máquinas de Turing.
Con respecto a aprender, no me quedó tan claro hacia adonde apuntaba en su charla. Yo colecciono enlaces sobre Machine Learning en
http://delicious.com/ajlopez/machinelearning
Y despues comentó sobre qué es componer música. Y destacó que lo que uno considera música, depende de nuestro criterio humano. De ahí el desafío para un programa: que produzca no ruido, sino música.
En ese tema, recordó el trabajo de Heinrich Schenker. Pueden leer sobre su trabajo
Schenkerian analysis - Wikipedia, the free encyclopedia
Tom Pankhurst's Guide to Schenkerian Analysis - Home Page.
Schenker Analysis for Pantonal Composition
Pablo comentó que si bien Schenker describía sus ideas sobre cómo analizar música, no daba pautas claras, lo que hoy llamaríamos un algoritmo. Recordó el trabajo de Fred Lerdahl y Ray Jackendoff:
Amazon.com: A Generative Theory of Tonal Music: Fred Lerdahl, Ray Jackendoff...
Por lo que entendí, estos trabajos se basan en gramáticas generativas (yo diría a al Chomsky), para ir describiendo música. Pablo presentó una partitura analizada de esa forma.
Y luego llegaron los platos fuertes, el trabajo de Pablo en acción.
Presentó en su notebook, un programa que lee y ejecuta un archivo MIDI y luego lo modifica, agregando notas (en un instrumento elegido manualmente), especificando altura y duración, SOBRE la música original. Ejecutó tres pruebas, recuerdo una sobre Mozart, y otra sobre Gershwin. Muy bien logrado la salida del programa, que no digamos “uy que bruto, que música generada….” ;-) pero era aceptable como producción.
Para cada música, presentó un diagrama de las decisiones que tomaba el programa para elegir su próxima nota. Pero no aclaró mucho sobre cómo se formaba ese diagrama. No parecía que tuviera relación con gramáticas generativas.
Al final, hubo una animada sesión de preguntas, lo que revela el interés que había despertado en el público. Yo pregunté si podía explicar en detalle el algoritmo que había usado para su programa, pero respondió que nos dormiríamos. Ahí se reveló que gran parte de la audiencia conocía de algunos temas, y luego de algunas preguntas más, Pablo soltó la prenda: estaba usando cadenas de Markov.
Eso era algo distinto de la línea que venía explicando. Recuerdo haber leido artículos sobre generación de música usando
Alguien preguntó sobre si se podía aplicar este “approach” a literatura. Me hubiera gustado comentar ahí dos cosas: una, recordar a mi apreciado Stanislav Lem, que en uno de sus excelentes “prólogos inventados”, creo que de su libro “Vacío perfecto”, trata de supercompadoras militares, una de las cuales se dedica en algún tiempo libre a analizar la obra de Dostoievsky, descubriendo que sus escritos forman una especie de toro en varias dimensiones, a las que le falta un pedazo. Y lo completa, escribiendo una obra que falta, a la que Lem describe con detalle, y uno se convence de que es la obra que Dostoievsky debería haber escrito.
Otra: que hay trabajos sobre la generación de texto, usando gramáticas generativas. Yo recordaría mi post:
Posmopolitan
Hubo varias sugerencias sobre cómo podría seguir Pablo con su trabajo. Creo que quedó la impresión que las cadenas de Markov son un “dead end”, pero habrá que ver.
Si hasta estuvo Gregory Chaitin y todo preguntando!!! (la primera vez que lo veo en persona!!)
Yo recuerdo haber sugerido:
- Armar un sistema que emplee reglas generativas, pero que las reglas se vayan descubriendo o aprendiendo (no tener que escribir las reglas). Yo me imagino un trabajo como el de Lenat con Eurisko, se le dan al programa música, y va intentando descubrir por sí mismo reglas
- Tener en Internet un comparador de música generada, para que los seres humanos vayamos “taggeando”, “rankeando” nuestras preferidas. Una especie de popego de música generada… ;-)
Y en algún momento, haría hincapié en el tema de “aprender”. Ese es un camino difícil, pero que puede ser fructífero. Que el programa se modifique a sí mismo, a sus reglas, a sus decisiones, lo que sea, pero que el programa evolucione.
Comentaría acá algo adicional: exploraría en algún momento, el jazz. En esa música, se encuentra la tensión entre lo que el oyente espera, y lo que ejecutante decide. Si lo que el ejecutante es demasiado aleatorio, se pierde el encanto. Si es demasiado predecible, no hay gracia. O tal vez, comenzaría por Bach, y hacer que el programa haga ingeniería inversa, redescubra reglas de la fuga. Se comentó algo
Si quieren ver algo sobre cadenas de Markov en música, a visitar:
michael clemow " Blog Archive " markov chain music
CiteULike: Extracting Patterns in Music for Composition via Markov Chains
Digital Music Programming II- Markov Chains
En el medio de las preguntas, Pablo mencionó al pasar otros temas: me temo que los mencionó al pasar (uno de los pocos defectos de la charla, mencionar algo sin dar un detalle más firme sobre lo que avanzar). Supongo que eran:
CiteULike- The nested Chinese restaurant process and hierarchical
GWCR - Generalized Weighted Chinese Restaurant Monte Carlo algorithm
Dirichlet process - Wikipedia, the free encyclopedia
De nuevo, supongo que está explorando formas aplicar análisis estadístico sobre música de entrada. Recuerdo varios artículos que tengo en otro cubil, sobre la aplicación de cadenas de markov, y otros, sobre cómo se obtenían distintas reglas, según la entrada sea mucho blues, vs música más “clásica”. Hubo un tiempo en los ochentas, que Douglas Hofstadter se ocupó mucho del tema. Debo tener alguna Scientific American son eso.
No recuerdo que Pablo haya mencionado a Eugene Narmour, parece que lo mencionó en una charla que tuvo con Chaitin luego. Ver:
Eugene Narmour
Algunos enlaces que voy coleccionando sobre el tema
http://delicious.com/ajlopez/computermusic
Pablo abrió hace unos días, su blog, para los que quieran seguir su progreso:
http://lacompositora.blogspot.com/
Pueden leer ahí su avance sobre la línea Narmour.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
http://ajlopez.popego.com
Enjoying Pappo playing piano, third video at Más blues con Pappo
No algorithm for that music, yet! ;-)
Estoy leyendo un post del bueno de Eugenio Pace
Windows Azure 101 – Primitives and Application Patterns – Playing Mendeleyev
donde plantea que Azure está compuesto de elementos que se pueden combinar, como las piezas de un Lego. Escribe sobre combinar piezas simples para formar cosas más complejas, de ahí la referencia a Mendeleyev y su tabla periódica.
Coincido: lo interesante de Azure es que es un modelo en principio simple, que se puede combinar de muchas maneras, para conseguir una explotación de la famosa “cloud”, sin tener que luchar en el intento con interminables APIs.
Hay en principio, “code hosts”, lugares donde se ejecuta nuestro código:
Puede ser un sitio Web, un servicio Windows Communication Foundation, o un Worker, un trabajo que puede ejecutarse sin interacción directa con un usuario o programa. Los dos primeros entonces, son interactivos, y el Worker no. Los sitios Webs interactúan con usuarios, y los servicios conversan con otras aplicaciones. Estos tipos de code hosts, se denominan en la terminología Azure, roles. Entonces, el Worker Role, es el típico proceso en background, corriendo independientemente de que alguien o alguna aplicación lo llame directamente.
Otro bloque de construcción básica de Azure, otras piezas del Lego, son los componentes de persistencia:
Uno puede almacenar Blobs (datos binarios cualquesquiera), tablas (simples) y dejar mensajes en colas. Esas son las formas de hacer que Azure guarde algo, que pueda ser usado más allá de la ejecución actual de nuestro programa.
Entonces, podemos tener un sitio web, que ante pedidos de los usuarios, vaya leyendo y grabando datos en una tabla, como de base de datos, y en un archivo binario:
Siguiendo con la idea de Eugenio, de combinar las partes, podríamos tener un sitio de subastas, donde nuestras ofertas se graban en una tabla, las fotos se suben en blobs, y nuestros productos ofrecidos pueden ser consumidos desde otras aplicaciones, por ejemplo, con WCF:
Pero podemos complicar el tema. Podemos tener un sitio web, donde el usuario vaya dejando pedidos de generación de reportes, que esos pedidos puedan ir a una cola de persistencia, un Worker Role esté encargado de ir leyéndoles, y produciendo los archivos de reportes, por ejemplo, gráficos o PDFs, que se graban en blobs. Estos son luego consultados por el propio sistema web:
Recordemos que, independientemente del código y la lógica de nuestra aplicación, podemos reconfigurarla para que el role Worker se ejecute en más de una máquina, en la nube. Esto sirve para escalar nuestra aplicación, sin tener que recompilarla.
Bueno, espero haber transmitido el mensaje original del post de Eugenio.
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Ayer Sábado 8 de Mayo, se realizó la primera reunión de ALT.NET en Buenos Aires, en la sede de Microsoft Argentina (lindo lugar para reunirse, cómodo, cerca del centro de Buenos Aires). Yo no pude ir, estuve ocupado, principalmente con el curso de Hacer Historia.
Si quieren saber más sobre el movimiento ALT.NET
ALT.NET Argentina, ALT.NET Hispano, primera reunión en Buenos Aires
Veo que twittearon con el tag #altnetba
Leonardo Micheloni dejó fotos en:
http://mail.google.com/mail/#inbox/1212b072ea470400
Y el bueno de Luis Petek, uno de los sponsors AP Systems también dejó sus fotos:
http://www.facebook.com/home.php#/album.php?aid=2022442&id=1044461328
Bueno, a ver si alguien postea y escribe y describe lo que pasó, cómo la vivió y demás…. Recuerden lo que no está escrito no existe… y no sean canutos, compartan con otros lo que vivieron, aprendieron y demás… ;-)
Porque sino, sólo quedan las fotos, esto ya parece un fotolog de Cumbio… :-)
Me perdí las pizzas de La Continental… ;-)
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez
Enjoying Pappo playing piano, Botafogo in guitar, third video Más blues con Pappo
Desde hace unas semanas se está organizando el movimiento ALT.NET en Argentina, y eso ha lanzado también un movimiento en español. Si no conocen ALT.NET, puede ver:
¿Qué es ALT.NET?
Es un movimiento… así de sencillo, pero también de entrada hay que decir que no hay una definición totalmente oficial ni exacta, hay descripciones y principios (tal vez no leyes) que rigen cómo piensa y actúa un alt.netero. De hecho, si buscas en la Web, seguramente vas a encontrar diferencias en como lo entienden unos y otros, aunque también es necesario aclarar que las diferencias son muy pequeñas y no muy distantes.
Ahí encontraran más información sobre el tema. Leer el artículo de Dave Laribee sobre ALT.NET
Copio de ahí los principios:
Hay que creer en cosas como:
- Aprendizaje continuo
- Estar abierto a soluciones Open Source
- Desafiar el Status Quo
- Buenas prácticas de Software
- DRY (No te repitas)
- Aplicar sentido común cuando sea posible
- Reconocer que a veces Microsoft no tiene la última palabra
- La calidad de las cosas siempre se puede mejorar
- Buscar la excelencia en la creación de Software
- Se usan recursos para alegrar el ambiente de trabajo
- La tecnología siempre cambia pero el conocimiento se acumula
Ese detallado artículo en español originalmente fue un post de Jorge Gamba:
Que es ALT.NET
Hay un wiki para ALT.NET Argentina
http://altnet-argentina.pbworks.com/
y otro para ALT.NET Hispano
http://altnet-hispano.pbworks.com/
Hay dos listas de correo en Google Groups, muy activas e interesantes:
http://groups.google.com/group/altnet-argentina/
http://groups.google.com/group/altnet-hispano
Este sábado 9 de Mayo se organiza la primera reunión presencial en Buenos Aires. Pueden ver más detalle en:
http://altnet-argentina.pbworks.com/2009-05-buenos-aires
Copio de ahí:
Participantes:
Lista actualizada (y registración) en:
http://eventioz.com/events/reunion-altnet-open-space-en-buenos-aires/registrations
Temas a debatir:
Estos son los propuestos hasta ahora por los participantes. En el comienzo del evento se evaluarán y votarán los que van a tratarse.
Día / Hora / Lugar:
9 de Mayo, de 9 a 18 hs, en las salas del cuarto piso de Microsoft (Bouchard 710)
Agenda (preliminar):
- 9:00 - Registración
- 9:30 - Apertura y sesion inicial (propuesta de temas y votación)
- 10:30 - Sesiones 1
- 11:30 - Sesiones 2
- 12:30 - Almuerzo (Pizza, cortesía de los sponsors)
- 13:30 - Sesiones 3
- 14:30 - Sesiones 4
- 15:30 - Sesiones 5
- 16:30 - Cierre y Retrospectiva
No hay breaks "oficiales" porque el formato permite el movimiento libre.
Como ven, no hay temas definidos, se definen entre los participantes, usando el formato Open Space.
Gracias a los sponsors de esta reunión:
Sponsors:
También hay reuniones virtuales ALT.NET, las llamadas VAN meetings, por ahora, todos los sábados a las 3PM GMT-3 (por favor, confirmar el horario en el wiki del movimiento y en las listas de discusión). Se votan los temas que quieren tratar en:
http://altnet-hispano.pbworks.com/Votacion
Han sido muy amables, han incluido a AjGenesis como tema a votar!
Nos leemos!
Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
Enjoying Otra vez Buddy Guy y Sweet Home Chicago