Archive for the 'Uncategorized' Category

Transacciones Offchain en Ethereum/RSK

Tuesday, June 27th, 2017

Anterior Post

Cada contrato en Ethereum/RSK tiene asociado un almacenamiento, el llamado “storage”. Este almacenamiento tiene celdas con contenido, accesibles por dirección numérica de celda  (32 bytes de dirección). El contenido de cada celda en Ethereum es la representación en bytes de un número de 32 bytes (en RSK, se ha conseguido modificar esto para que cada celda pueda albergar una cantidad arbitraria de bytes, a decisión del programador; hoy esta característica está solo disponible para contratos precompilados). Entonces, el almacenamiento de un contrato onchain (público en la blockchain, deducible desde la blockchain por cada nodo interesado de la red), es algo como:

(direcciones y contenidos simplificados). Cada dirección no usada tiene un valor asumido (cero en Ethereum, donde todos los contenidos son números enteros). Cuando el contrato se ejecute OFFCHAIN (fuera de la blockchain, como describí en el anterior post), el estado del almacenamiento se mantiene en la memoria del nodo ejecutante del contrato, y NO SE COMPARTE con el resto de la red. El estado offchain sólo es conocido por el nodo designado para ejecutar el contrato offchain. Este estado puede ser alterado enviando transacciones offchain al contrato, y haciendo calls offchain a ese contrato en ese nodo.

Un contrato offchain tiene código especial (escrito por el programador) que anuncia la confirmación (commit) del contrato. Esta operación es un nuevo opcode de la Ethereum Virtual Machine, se podría invocar desde código solidity también. Si la operación de commit es invocada entonces el contrato y el sistema EMITE una transacción ONCHAIN, a ser repartida, minada, validada y publicada por el resto de la red. La llamo la transacción delta. Es una transacción que cuando se ejecuta ALTERA el estado público, ONCHAIN, del contrato, para reflejar el nuevo estado OFFCHAIN. Para eso le basta tener información de los valores alterados NO TODA LA HISTORIA de las transacciones offchain que se ejecutaron:

Hay detalles a decidir, por ejemplo, el costo de esas transacciones y quién paga ese costo (mi primera respuesta: paga el que envió la transacción offchain que provocó la ejecución del commit).

La transacción delta comienza a tener sentido si su tamaño y costo es MENOR que el costo probable de ejecutar todas las transacciones OFFCHAIN enviadas como si fuera ONCHAIN. Podría ser así, por ejemplo, en los contratos que mantienen saldos de token por cuenta: las transferencias podría ser cientos, y afectar a POCOS saldos, y entones, alterar en poco el storage resultante.

Aunque estas ideas podrían ser algo difíciles de implementar en una red ya en ejecución como Ethereum, en RSK tenemos una implementación nueva, pero todavía en prueba, que podría aceptar fácilmente este tipo de nueva conducta soportada. Y estaría alineado con el propósito de RSK de llevar toda esta infraestructura a una escala que permita cientos o miles de transacciones por segundo, a bajo costo. El gran desafío es dar herramientas de desarrollo a gente que no está bancarizada o que no puede afrontar grandes costos de operaciones.

Próximos temas a tratar: la transaferencia de valor (ether) en las transacciones offchain, y cómo se transfiere ese valor en la delta transaction.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Propuesta Alternativa para el Contrato Remasc en Ethereum/RSK

Monday, June 26th, 2017

Desde el lanzamiento de la testnet pública de RSK, el código fuente ha sido publicado. Y ahora, puedo escribir sobre algunos detalles de la actual implementatión.

La plataforma Ethereum soporta el concepto de contratas precompilados: contratos que se implementan directamente en el código de cada nodo implementando, claro que respetando compatibilidad entre lenguajes de implementación. En el caso de RSK, se agregaron dos contratos precompilados: el contrato Bridge, y el contrato Remasc. En este post, quiero proponer una implementación alternativa al contrato Remasc (todavía sin una propuesta concreta en código, no hay una descripción oficial de la conducta esperada del contrato Remasc).

¿Qué es el contrato Remasc? Por lo que sé (recuerden, todavía no hay una descripción publicada del mismo, sólo el código), es un contrato que asigna premios a los mineros, examinando la actividad reciente de la blockchain en proceso. Para calcular y asignar esos premios, tiene estado relacionado con a los bloques pasados de la blockchain, no le basta con la información del bloque actual en proceso. Este estado está  en esta clase. Además, hay  una transacción especial Remasc AGREGADA a CADA bloque minado, al final de la lista de transacciones del bloque (no hay bloque válido SIN esa transacción Remasc). Así, que al final del proceso del bloque, esa transacción especial es ejecutada.

Pero, de acuerdo al Ethereum Yellow Paper, hay un paso especial en el proceso de un bloque:

11. Block Finalisation
The process of finalising a block involves four stages:
(1) Validate (or, if mining, determine) ommers;
(2) validate (or, if mining, determine) transactions;
(3) apply rewards;
(4) verify (or, if mining, compute a valid) state and nonce.

Entonces, mi primer propuesta consiste en eliminar ese transacción “agregada compulsivamente” en cada bloque, y usar el paso de finalización de un bloque para calcular y asignar los premios a los mineros. De esta manera, podemos eliminar el cálculo del nonce de la cuenta remasc, el armado y firmado de esa transacción, la inclusión de esta transacción para que el bloque sea considerado válido, la serialización de esos datos, el almacenamiento del transaction receipt…. bien, todos esos recursos pueden liberarse, veo que usar una transacción explícita puede simplificarse.  Para mí, tener un proceso de premiado implícito al final de un bloque es un modo más simple de hacer las cosas. Y ya saben mi preferencia: simplicity pays 🙂

La otra propuesta, a ser evaluada y explorada, es simplificar el uso del almacenamiento. El cálculo del próximo estado podría ser ejecutado con la información YA disponible en la blockchain en proceso, ya esa información está disponible. Así, el uso actual de almacenamiento (storage) en la implementación, es más un hack por performance, que algo estrictamente necesario (punto a revisar, porque al no tener una descripción de las responsabilidades del contrato, desconozco lo que tiene para hacer). El cálculo del próximo estado puede ser ejecutado apelando a la información de la blockchain. Si es necesario acceder a ese estado rápidamente, el contrato puede apelar a un cache en memoria. Si fuera necesario algún dato que NO se pueda obtener de la blockchain, ahi sí: eso va al storage, así todos los nodos pueden a partir de ahí calcular el nuevo estado. El storage en Ethereum es costoso, y RSK no es la excepción: en la implementación actual, luego de haber procesado 100000 en mi máquina con un nodo local conectado a la testnet, el espacio en disco ocupado por el contrato Remasc da cuenta de UN TERCIO del espacio total.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Multi-Blockchains en Ethereum/RSK

Monday, June 19th, 2017

La implementación de una blockchain incluye la creación, distribución y manejo de bloques como éste:

Un bloque, en Bitcoin, Ethereum o RSK tiene:

  • Un hash único en el sistema
  • Un bloque padre, identificado por un hash
  • Un número de bloque (que es uno más que el número de bloque del padre)
  • Una lista de transacciones

En el caso de Ethereum y RSK, una transacción tiene:

  • Una cuenta enviadora
  • Una cuenta receptora
  • Un valor a transferir
  • Datos adicionales (usados si la cuenta receptora es un contrato inteligente)

Una lista de bloques válidos encadenados forma lo que se llama una blockchain:

En Ethereum/RSK, un bloque también tiene:

  • Bloques tíos (“uncles”)
  • Dificultad asociada al bloque (la dificulta de la prueba de trabajo (“proof of work”) más la suma de las dificultades de los tíos)

De esta forma, la presencia de bloques tíos contribuye a la dificultad del bloque. Y este número suma a la dificultad TOTAL de la blockchain a la que este bloque se agrega. Varios nodos en la red, llamados mineros, generan bloques en la blockchain. Si hay varias alternativas, el algoritmo de consenso distribuido elige la blockchain con mayor dificiltad total:

(en Bitcoin, la blockchain más larga siempre gana; en Ethereum/RSK una blockchain más corta puede ganar a otra más larga si tiene mayor dificultad acumulada total).

Un problema es mantener el estado de todas las cuentas y contratos en el sistema. Cada transacción tiene entonces algo adicional:

  • El hash del estado del mundo

Un  hash que referencia al estado del sistema DESPUES de la ejecución de la transacción. Ese hash es verificado en cada nodo de la red que procesa el bloque y la transacción; de esa manera todos los nodos de la red termina coincidiendo en el resultado del estado del mundo controlando el hash resultante en cada paso. Un estado del mundo se almacena en un trie, una estructura de árbol donde cada nodo tiene un hash asociado dependiendo del contenido de ese nodo. Ver mi trabajo anterior sobre tries en Building a Blockchain (5) Building a Blockchain (12)

El bloque mismo también tiene un hash de estado, representado el estado del mundo LUEGO de la ejecución del bloque. Puede ser DIFERENTE que el estado del mundo luego de la ULTIMA transacción del bloque, porque se admite que al final del bloque se realicen operaciones que alteren el estado, por ejemplo, la asignación de premios a los mineros. Este hash de estado de bloque también es controlado por todos los nodos de la red, para mantener el consenso y validar el bloque.

Un problema es el armado de un bloque, que puede ser un cuello de botella cuando se intenta procesar muchas transacciones (por ejemplo, cientos o miles de transacciones por segundo). Este es el principal caso de uso que inspira esta serie de posts. Sería interesante tener MUCHAS blockchains:

Entonces, una blockchain podría estar dedicada a las transacciones de un contrato/token muy popular, mientras que otra blockchain puede estar dedicada a las transacciones de una nación o región. Sólo de vez en cuando habrá transferencias entre blockchains. Este esquema de cosas no se limita a sólo dos blockchains, se podría manejar muchas más, y tener nodos dedicados a procesar sólo una o dos blockchains. Entonces, en cada nodo se requieren menos recursos para mantener el estado, y el estado global está distribuido en los nodos que atienden a DISTINTAS blockchains. Describo blockchains con esquemas iguales, no Bitcoin vs Ethereum, sino todas Ethereum o todas RSK.

En los próximos posts, describirér los cambios necesarios en Ethereum/RSK para manejar múltiples blockchains en la red.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Alineando las Sillas en la Cubierta del Titanic

Saturday, April 15th, 2017

Desde la aparición de la agilidad aplicada a equipos de desarrollo de software, hemos estado avanzando en nuestra profesión. En mi experiencia, veo que la calidad de lo producido ha mejorado, en general. Por lo menos, cuando veo los proyectos en los que he participado en este siglo, comparados con anteriores, noto esa mejora general. Y también en la satisfacción personal de cada miembro del equipo, en el manejo de los tiempos, los esfuerzos, y demás. Y veo lo mismo en decenas de proyectos en los que no participé pero he visto crecer de cerca.

Pero a veces, veo tomar decisiones que no son las más ágiles, o no están alineadas con lo que el contexto del proyecto pide. Una tendencia, no muy frecuente por suerte, es poner énfasis en alguna métrica o herramienta en lugar de lo que es importante para el proyecto.

Por ejemplo, he visto “sprints”, iteraciones, dedicadas a “incrementar el porcentaje de code coverage a 80%”. Por más que repaso las circunstancias de los casos que conozco, no logro ver que sea realmente lo importante. Es más, tomar ese tipo de trabajo es perder una oportunidad de mejora real en el equipo. El trabajar “a posteriori” en el incremento del code coverage, es poner el carro delante del caballo. Lo que buscamos en un sistema que estamos armando es que funcione como esperamos. Y eso se logra mejor si escribimos los tests de la conducta esperada, de cada caso de uso que queremos cumplir (uso “caso de uso” en un sentido amplio, desde la conducta esperada en una simple clase, hasta el resultado esperado luego de una serie de pasos de negocio). Cuando uno sigue ese “approach”, el “code coverage” nos da automáticamente cumplido como métrica, casi seguro mayor que el 80%, o que el 90%. Eso es lo que tiene que ser la medición del “code coverage”: una métrica que de evidencia de que estamos siguiendo el buen camino, antes que un objetivo en sí mismo. Trabajar a “posteriori” para incrementar esta métrica NO ASEGURA que estemos escribiendo un buen sistema. Ver ejemplo mencionado en el post El Programador Profesional (1) , donde aún con un gran “code coverage”, lo entregado se rompía luego de dos clicks en el browser, en cuatro continentes.

Otra versión parecida de errar en el blanco, es adoptar prácticas porque parecen las “mejores prácticas” o poner procesos obligatorios en el desarrollo, como obligación de manejarse con “branch por feature”, y “code review”, para mantener “la calidad del código”. Las veces que vi que se llegara a esa situación, son pocas, por suerte. Pero igual de vez en cuando aparecen, y veo que es de nuevo atacar un problema con procesos y herramientas, adoptar prácticas que tienen sentido en otro contexto, sin aprovechar atacar las causas raíces y obtener una mejora en el equipo.

Por ejemplo, “branch por feature”, podría adoptarse, pero en casos particulares. Si se necesita adoptar en un caso, es seguramente porque no estamos trabajando en forma incremental, simplemente mejorando el “branch” de desarrollo, trabajando juntos, esforzándonos por no romper algo (por ejemplo, usando TDD (Test-Driven Development) me facilita mucho el saber automáticamente si la conducta esperada no se cumple). Y dificulta la integración, tenemos que trabajar más casi siempre al final de la iteración para tener algo entregable. Y vi que promueve el trabajo en silos, donde cada cual trabajar en un “branch”, en lugar de trabajar todos juntos en una tarea. Cuando la adopción de “branch por feature” se hace obligatoria, es como que se naturalizan esos “bad smell” de equipo, y no podemos activamente trabajar en la mejora. He visto DECENAS de proyectos de equipos ágiles donde no se usa “branch por feature” y todo funciona de forma armoniosa. Esto me lleva a pensar que “branch por feature” es algo más útil cuando el proyecto es de código abierto. En un equipo ágil, donde hay una reunión diaria, donde hay comunicación (aun remota), donde el sistema se va armando de tal forma de saber cuando algo no funciona o cuando introducimos un bug sin quererlo, donde el sistema no se ha dejado llevar por la complejidad accidental y puede entonces ser desarrollado incrementalmente, cuando veo que se da este contexto, veo que no es tan necesario el “branch por feature”.

En cuanto a “pull request con code review” obligatorio, de nuevo: veo que es un síntoma de no atacar otra causa raíz. Por ejemplo, no lo vi tan necesario cuando hay trabajo de a pares. O cuando hay confianza en los miembros del equipo, y se sabe que cualquier cosa que uno agregue puede ser revisada en cualquier momento, porque estamos armando un sistema evolutivo, sin complejidad accidental, que admite cambios como todo lo ágil promueve. Cualquier cosa que parezca mejorable, se puede mejorar en cualquier momento. Por supuesto, cada uno debe hacer el mejor esfuerzo desde el principio.

En definitiva: adoptar herramientas y procesos de esta forma, es como alinear las sillas en la cubierta del Titanic: estamos haciendo algo que parece bueno, en vez de hacer lo correcto, lo que la situación amerita. Y nos naturaliza los problemas, sin atacar las causas raíces.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com

 

Resoluciones del Nuevo Mes: Abril 2016

Sunday, April 10th, 2016

Un nuevo mes comienza, ya vamos adentrándonos en el año, y es tiempo de escribir las nuevas resoluciones mensuales. Y tiempo de revisar las del mes pasado:

– Mejorar AjGenesisNode-Express [pendiente]
– Trabajar en CrysJS [completo] ver repo
– Trabajar en CrysSharp [pendiente]
– Mejorar mis ejemplos de SimpleGA [pendiente
– Trabajar en SharpGo [pendiente]
– Trabajar en EthSharp [completo] ver repo

También trabajé en:

– Mejorar SimpleForth en JavaScript [completo] ver repo
– Comenzar WangTiles en C# [completo] ver repo
– Publicar una nueva versión de SimpleArgs [completo] ver repo
– Comenzar BlockchainSharp en C# [completo] ver repo
– Mejorar los ejemplos de SimpleDT [completo] ver repo
– Mover AjGo a GitHub [completo] ver repo
– Mejorar RuScript [completo] ver repo
– Agregar Code Coverate a ethereumjs rlp [complete] ver repo
– Dar una nueva charla sobre Machine Learning en JavaScript [completo] ver repo ver charla

Mis nuevas resoluciones:

– Mejorar WangTiles
– Mejorar BlockchainSharp
– Comenzar Blockchain en JavaScript
– Trabajar en EthSharp
– Mejorar SimpleGA
– Mejorar AjGenesisNode-Express
– Trabajar on CrysJS
– Trabajar en CrysSharp

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

AjFabriq en NodeJs (Parte 1) Introducción

Friday, August 26th, 2011

Siguiente Post

Hace unos años ya descubrí el proyecto Fabriq (gracias @asehmi!):

Remember Fabriq
Recordando Fabriq
FABRIQ has gone public!
Arvindra Shemi Fabriq Articles
Clemens Vasters Fabriq Articles

Los puntos principales:

FABRIQ is an infrastructure for constructing networks of nodes processing and relaying messages. These nodes are hosted in machines running into a serviced application.

You can have multiple machines running the same or different applications. The “network” is the application, “node” is a collection of “actions”, and each action process a message. More doc:

These nodes can be hosted in any distribution on several machines according to a defined configuration, so there may be machines running a single node or several nodes, this association are made by specifying the host-name or machine identification associated with each node in the network.

Each of these machines is running a serviced application responsible for starting and stopping its Host and Nodes which are the application main components. The host is responsible for handling the configuration, loading and unloading nodes and receives the messages and delivers them to the appropriate Node.

El pasado fin de semana (algo el domingo, algo el lunes, que fue feriado por aquí en mi país, Argentina) comencé a escribir un proyecto Javascript (para seguir practicando) que corre sobre NodeJs, basado en las ideas de Fabriq:

A Distributed Application Framework for NodeJs https://github.com/ajlopez/AjFabriqJs

La implementación es simple y ocupa un solo archivo de código, con cuatro “clases” Javascript.

Quiero ejecutar varios servidores NodeJs que alberguen aplicaciones AjFabriq, enviando mensajes a través de la red:

El Fabriq original tenía aplicación, nodos, configuración de cómo se distribuía esas aplicaciones y nodos de proceso en la read. Simplifiqué para quedarme con lo esencial y ahora tengo un Processor simple que acepta mensajes. Puede producir 0, 1 o más mensajes:

Los mensajes no tienen un esquema fijo y son objetos JSON que contienen su propia información de ruteo (cual aplicación va a recibir este mensaje, etc..):

Un Processor podría manejar todos los mensajes que contegan nome/valor application: “webcrawler” en su objeto JSON. Otros Processors son compuestos (composites de Processors): tienen otros procesos. Entonce, el Processor de web crawler podría tener un Processor especializado en atender los mensajes que contenga clave valor node:”downloader” en su objeto JSON. ¿Se ve la idea? Lo nuevo con respecto al Fabriq original es que las claves/valor y la profundidad del árbol de Processors LO DECIDE el programador. Pueden tener “applications”, “nodes”, o lo que quiera.

Un servidor host (que ejecuta NodeJs) puede tener varios Processors definidos. Cuando un mensaje es recibido un método simple local examina el árbol de Processors albergados y lo envía al adecuado. Podría ser procesado localmente o podría ser enviado a un servidor remoto. La red de servidores es dinámica: un nuevo servidor puede ser levantado y se puede unir a la red y comenzar ahí mismo a colaborar en el proceso de mensajes.

Hay temas pendientes para futuros posts: detalles de implementación, mostrar la más simple aplicación (corriendo local y distribuida), cómo uso net sockets (sockets planos), y mi fracaso al intentar usar Socket.IO (que maneja solito la serialización JSON y el protocolo de comunicación). Trabajo en progreso: hacer que AjFabriq esté más alineado con NodeJs usando EventEmitter en algunos puntos del proceso; un mejor reparto de la información de qué aplicaciones están en cada servidor; una implementación más robusta; renombrar lo que llamé Socket a Channel, una palabra que describe mejor la intención.

My previous work on distributed application samples:

AjMessages (en inglés)
AjMessages (en español)
AjAgents (en inglés)
AjAgents (en español)

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

¿Qué es Cloud Computing? (borrador)

Thursday, August 20th, 2009

Hay bastante revuelo sobre los conceptos y aplicaciones de Cloud Computing, con ofertas de prácticamente todos los grandes jugadores del software. En estos días encontré este video, corto, que sirve para que podamos transmitir, no tanto el tema técnico, sino la proposición de valor que ofrece la nube. Podemos verlo como una extensión de tercerizaciones que ya se venían haciendo (como el hosting del sitio de una compañía), pero a mayor escala (a tener en cuenta: es un video comercial de SalesForce.com):

[View:http://www.youtube.com/watch?v=ae_DKNwK_ms]

Hay muchos temas técnicos a discutir, y muy interesantes. Pero vayamos viendo cómo puede influir en nuestros desarrollos y proyectos, todo esto de la nube.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

Robo de notebook

Friday, April 17th, 2009

Gente, el martes pasado me robaron la notebook, en Buenos Aires. Fue un descuido de mi parte. Desde siempre, me cuidé de no dejarla expuesta, pero esta vez, por una distracción, me pasó.

Estando en Aroma Ambiental de Florida, casi Santa Fé, en el primer piso. Me senté en una mesa, a mirar por la ventana, a leer, dejé el bolso con la notebook, en el piso, apoyado del lado externo de la mesa, en vez, de como acostumbre, dejarla del lado de la pared. Había poca gente. Cuando a la hora, me voy a levantar, no está más el bolso. Ya sabía de otros casos así, desde gente que pierde la notebook en un evento, hasta en un negocio de comida rápida, o en otros lados. Pero realmente esta vez me confié, porque había poquísima gente. Es lamentable tener que estar ahora atento a todo, en vez de simplemente confiar. En el local, la gente encargada me atendió muy bien. La policía igual comentó que es frecuente, que pasa todos los días. (Aroma tienen buen café, aunque puede que tengan los sandwichs más caros del planeta).

Lecciones aprendidas:

– No se descuiden

– La redundancia es la mejor estrategia: Este es un “mindset” que tengo desde que leí “Sadrac en el horno”, de Silverberg, creo. El personaje malo principal, es el Khan de casi todo el mundo. Y una de sus frases y estrategias favoritas, es esa: la redundancia es la mejor estrategia. Tengo que mejorar en ese aspecto, ser más ágil, y no depender tanto de un solo aparato, herramienta o artefacto. Debería escribir un test: pasar una semana sin usar una máquina en particular, o algo así.

– El poder de la nube: tengo prácticamente todo lo que me importa de información y herramientas, en la web. Así, que cuando tenga una nueva máquina, sólo tengo que pasar cosas que tengo en distintos lugares, desde Skydrive, sitios web, y otros.

Eso fueron lecciones aprendidas.

Pero más, mucho más importante, aprendí a apreciar el apoyo que me dieron todos, en estos días. Gracias, muchas gracias!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

 

Primera semana sabática del año

Monday, March 30th, 2009

El viernes pasado, comencé mi primera semana sabática del año. Esta “semana extendendida”, debería termina el lunes 6 de Abril. Pero el proyecto en el que estoy trabajando fue extendido una semana más. Usualmente, no doy clases ni charlas, pero esta vez, debido a reordanimientos en mi calendario, estaré dando un curso de Scrum y una clase de .NET.

Así, que decidí esta vez compromenterme a una lista de objetivos, pero a cumplir en dos semanas, de acá al lunes 13 de Abril.

La lista incluye:

– Escribir un post explicando las motivaciones e ideas iniciales a implementar en AjProcessor.

– Mejoras menoras (soporte de acceso e invocación a objetos .NET), refactoring mediano, y primera versión publicada de AjCat, y post.

– Agregar soporte de bloques y variables indexadas a AjTalk, y post.

– Publicar un post explicando lo hecho en AjPepsi.

– Código inicial de proyecto de código abierto, en Java, y post.

Bien, eso es todo. Me gustaría ponerle más foco en un a sola semana, pero esta vez, tendré que ocuparme de otros temas.

Como siempre, tendré que publicar un post de cierre, con lo efectivamente entregado.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez

Webcast sobre Geneva Framework

Tuesday, February 10th, 2009

Mañana miércoles daré, junto con Sebastián Renzi  (@SebaRenzi) un nuevo webcast, esta vez sobre Geneva Framework, el nuevo framework de Microsoft para el manejo de seguridad basado en claims.

Pueden registrarse en:

Webcast MSDN: Identidad – Profundizando Geneva

Es a las 2:00PM, hora de Bogotá (GMT -5). Es 5:00PM, hora de Buenos Aires (GMT -2).

Estaremos mostrando:

– Identidad
– Qué es un claim
– Qué es un Token
– Cómo programar un Security Token Service
– Revisión de Código de ejemplo de Geneva Framework

Como siempre, colecciono enlaces sobre un tema. Pueden visitar:

http://delicious.com/ajlopez/geneva
http://delicious.com/ajlopez/sts
http://delicious.com/ajlopez/authentication
http://delicious.com/ajlopez/security

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com/
http://twitter.com/ajlopez