Diciembre fue un mes bastante activo desde lo académico (En mi trabajo también, pero eso es otra historia). Fui invitado a las JCU como Estudiante que esta realizando su Tesis, y me pidieron que contara en 20 minutos cual es mi trabajo de Tesis. El resultado de ese pedido fue una charla con estas slides.

También agregue un nuevo Indexador a mi repositorio de código Hadoop en Github. Si vienen siguiendo mi trabajo, esta vez agregue un Indexador basado en las ideas de Dean y Ghemawat pero agregando un patrón Combiner in-mapper, tal como se explica en el libro MapReduce Algorithm Design. Este texto es ya una referencia obligada en mi trabajo con Hadoop, y posiblemente le dedique bastantes horas en lo que sigue para poder extraer muchas de las buenas ideas que se plantean en el.

En dicha oportunidad prometí un post con contenido sobre desarrollo para Hadoop. Acá les dejo unas diapositivas que prepare especialmente para introducir en el tema.

Ya que estamos, si quieren mirar código y si tienen tiempo colaborar, estoy subiendo mis implementaciones a un repositorio público en Github. Es un repositorio íntegramente funcional sobre Hadoop 2. Ademas estoy tratando de ir subiendo issues para favorecer la colaboración (De alguna manera marca el estado de avance de los proyectos y da una idea de lo que falta hacer).

Si tienen intenciones de colaborar o forkear, no duden en contactarse conmigo.

La mayoría del contenido no es propio, sino que es recopilado de presentaciones y webs online. La integración es a fines académicos. En la mayoría de los casos agregue referencias, pero si encuentran algún lugar que falte, por favor avísenme y lo agrego.

La herramienta que use para armar las slides es slides.com, que es una interfaz para la librería reveal.js, que esta muy copada, y solo usa HTML+CSS+JS (con librerías, obviamente).

Lo próximo es una diapo con algunos ejemplos de aplicaciones en Hadoop (instalación, código, etc…)

La practica implica ejecución de sentencias “DDL”:http://es.wikipedia.org/wiki/Lenguaje_de_definici%C3%B3n_de_datos sobre el programa _ISQL_, que es el interprete de _Firebird_.

El error fue: Statement failed, SQLCODE = -607

El código _SQL_ que daba el anterior error era:

bc. CREATE TABLE T_PRODUCTOS_COMPRADOS (
IDPRO DOM_IDPK,
FECHA DOM_FECHA ,
IDT DOM_IDPK ,
IDS DOM_IDPK ,
IDP DOM_IDPK ,
CANTIDAD DOM_CANTIDAD,
PRECIO DOM_PRECIO,
CONSTRAINT PK_T_PRODUCTOS_COMPRADOS PRIMARY KEY (IDPRO, FECHA,IDT,IDS,IDP),
CONSTRAINT FK_T_PRODUCTOS_COMPRADOS FOREIGN KEY (IDPRO, FECHA) REFERENCES T_COMPRA,
CONSTRAINT FK_T_PRODUCTOS_COMPRADOS FOREIGN KEY (IDT,IDS,IDP) REFERENCES T_PRODUCTO
);

Y el error completo era:

bc. Statement failed, SQLCODE = -607
unsuccessful metadata update
-STORE RDB$INDICES failed
-attempt to store duplicate value (visible to active transactions) in unique index “RDB$INDEX_5”

Diagnostico: El ante-ultimo y el ultimo “FOREIGN KEY”:http://es.wikipedia.org/wiki/Clave_foranea CONSTRAINT poseen el mismo nombre. Se debe cambiar el nombre de alguno de los dos.

Conclusión: Es importante que los nombres de los objetos de una DB sean descriptivos y cuidadosamente puestos.

Como primer trabajo practico, los profesores proponen la generación de un sistema ABM (también conocido como CRUD), que se subdivide en 3 ejercicios, que aumentan el grado de complejidad de la implementación.

El ultimo ejercicio, pone de manifiesto muchos de los limites que tenemos a la hora de usar los sistemas de organización de archivos fuertemente relacionados con la lógica de negocios, y el próximo paso luego de dicho ejercicio es comenzar a usar bases de datos.

“El enunciado del trabajo practico lo descargan de aquí”:http://blog.tomasdelvechio.com.ar/index.php?s=file_download&id=6

Yo he desarrollado dicho proyecto en Ruby, en consola, y pueden conseguir el código en la “Pagina del mini-proyecto”:http://sourceforge.net/projects/rubyabm/

O directamente por consola pueden descargar completamente el código fuente (habiendo instalado previamente en el sistema _Subversion_, el famoso sistema de control de versiones):

bc. svn co https://rubyabm.svn.sourceforge.net/svnroot/rubyabm

El ultimo ejercicio, que seria el mas complejo, tiene algunos problemas en la forma que esta programado, sobre todo en el nivel de abstracción en cada capa.

Veré si en el verano me siento a mirar el código, tengo algunas ideas, sobre todo me interesaría profundizar en la implementación de índices secundarios, y luego de estructurar bien las capas de la aplicación, implementar alguna interfaz gráfica, sea por GUI o web.

“RDoc”:http://rdoc.sourceforge.net/ es el programa mas usado dentro de Ruby para lo que plantee en el párrafo anterior.

En Ubuntu Karmic disponemos de los siguientes paquetes

bc. $ sudo aptitude search rdoc
i A rdoc – Generate documentation from ruby source files
i A rdoc1.8 – Generate documentation from Ruby source files (for Ruby 1.8)
p rdoc1.9 – Generate documentation from Ruby source files (for Ruby 1.9)
p rdoc1.9.1 – Generate documentation from Ruby source files (for Ruby 1.9.1)

Les dejo cortito la forma de uso del programa y una salida. Para que se den una idea del resultado, “fijense por aquí”:http://www.ruby-doc.org/core/.

bc. rdoc [opciones]

bc. $ rdoc –op doc/ –all

bc. fileHandled.rb: ……
varios.rb: …..
abmc.rb: …….
app.rb: .
main.rb: ..
altas_testing.rb:
files_testing.rb:
abmc.rb: …….
meta.rb: …….
fileHandled.rb: …….
varios.rb: …..
hashing.rb: …….
main.rb: .
abmc.rb: …….
fileHandled.rb: …….
varios.rb: …..
hashing.rb: …..
Generating HTML…

bc. Files: 17
Classes: 0
Modules: 0
Methods: 79
Elapsed: 21.324s

La verdad que funciono de maravilla, aunque recomiendo leer bien la documentación, porque se puede hacer que cada método tenga una descripción apropiada poniendo los comentarios en el lugar correcto, entre las pocas cosas que pude aprender. Les dejo la intriga

Fuente:
“El generador de documentos de Ruby”:http://spejman.blogspot.com/2008/02/rdoc-el-generador-de-documentacin-de.html

Por lo que vi, es bastante abarcador. Habrá que sentarse a leerlo para ver si son exhaustivos en calidad como en cantidad.

Del curso me entere a través del _blog_ de “Técnicos Linux”:http://tecnicoslinux.com.ar/

* “Los dueños de la cultura vs. Horacio Potel”:http://www.vialibre.org.ar/2009/03/11/los-duenos-de-la-cultura-vs-horacio-potel/
* “Horacio Potel, la filosofía, el dinero y la policía intelectual”:http://www.lalaurette.com.ar/blog/index.php/planeta/2009/09/18/horacio-potel-la-filosofia-el-dinero-y-la-policia-intelectual
* “Filosofía y Letras de UBA repudia el procesamiento de Horacio Potel”:http://www.vialibre.org.ar/2009/11/13/filosofia-y-letras-de-uba-repudia-el-procesamiento-de-horacio-potel/

Me alegra ahora postear la siguiente nota:

“Potel sobreseído”:http://www.lalaurette.com.ar/blog/index.php/planeta/2009/11/18/potel-sobreseido

Con Potel y este nuevo fallo, repitamos una vez mas: *Borrar libros = Quemar libros*.

Abajo las retrogradas leyes de _copyright_ que reproducen una estructura de poder económico (las discográficas), y no ayudan al avance de la cultura, la tecnología y la ciencia (de hecho, hoy por hoy aportan a su contrario). Como diría RMS alguna vez: _Cuando el copyright impide el progreso de la ciencia, la ciencia debe desechar el copyright_.

Durante el día *Miércoles 18 de Noviembre*, a partir de las *15 horas* se va a estar desarrollando en las instalaciones de la Universidad Nacional de San Luis, las primeras “Charlas Tecnológicas, de Software Libre e Informática”, este evento se encuentra orientado a estudiantes, profesores, profesionales y amantes de la informática en general. En el cual el grupo de usuarios de Software Libre local (San LuiX), expondrá acerca de la utilización de nuevas tecnologías basadas en software libre y el impacto que estas tienen con relación a desarrollos, investigaciones y seguridad.

Este ciclo de charlas, se encuentra organizado conjuntamente entre el departamento de Informática de la Universidad Nacional de San Luis, y San LuiX. El mismo compone la primera edición de lo que será un ciclo de charlas bimestrales con el fin de difundir el software libre como así también la cultura libre dentro de la ciudad de San Luis.

La entrada al evento es (y será) libre y gratuita.

Charlas

* Open Hardware – Lic. Jorge Arroyuelo.
* Python y la red de redes – Marcelo O. Alaniz.
* Kohana, ¿un framework mas? – Carlos Estilarte.
* Buffer Overflow, for fun and pr0fit – Facundo M. de la Cruz.

Datos a agendar

Fecha: Miércoles 18 de Noviembre de 2009.
Hora: A partir de las 15 horas.
Lugar: Universidad Nacional de San Luis – Bloque II – Sala 7. (San Luis,
Argentina).
Entrada: Libre y gratuita.

Extraído de [TOL]:

* Orientado a la conexión (con confirmación)
** Se establece una conexión (esquema de tres pasos)
** Se numeran y controlan todas las PDUs
** Sistemas de retransmisión de PDUs.
** Ejemplo: El protocolo TCP.
* No orientado a la conexión (sin confirmación)
** No se establece conexión
** Se envían tramas a la máquina destino sin acuse de recibo
** No se reintenta enviar las tramas perdidas o erróneas (Recuperación de errores en capas superiores)
** Ejemplos: IP, Ethernet
* No orientado a la conexión con acuse de recibo
** No se establece conexión
** Cada PDU es notificada y confirmada por el destino
** Se reenvían PDU erróneas
** Ejemplo: 802.5 (Token Ring)

*5) Describa los objetivos que se persiguieron en la construcción del Modelo OSI.*

Según [STA], se persiguieron 10 objetivos en la construcción del modelo OSI[1]:

# Creación de las capas adecuadas para que la integración e implementación de las capas no genere mas problemas o dificultades que las necesarias.
# Crear una separación entre capas en todo punto en que la descripción del servicio sea reducida y el numero de interacciones a través de dicha separación sea pequeña.
# El criterio para crear capas separadas es donde la tecnología a utilizar y las tareas a realizar sean manifiestamente diferentes.
# Agrupar funciones similares en una misma capa.
# Separar en los lugares donde la experiencia haya mostrado que es de utilidad.
# Independencia de capas: Una capa debería poder ser rediseñada totalmente, o cambiar sus protocolos en forma radical, y esto no debería implicar una modificación en los servicios usados u ofrecidos por las capas adyacentes.
# Separar donde convenga tener una interfaz “normalizada”.
# Crear una capa donde haya una necesidad de un nivel de abstracción distinto a la hora de gestionar los datos.
# Los cambios en funciones o protocolos no deberían afectar a las otras capas.
# Por cada capa, establecer separaciones en sus capas inmediatamente superiores o inferiores.

*6) Explique la forma por la cual las entidades pares se comunican.*

Las entidades pares se comunican a través de la cabecera de los protocolos referentes a cada capa.

Para comenzar, pensemos en un ordenador que esta ejecutando una aplicación que necesita transmitir información a otra computadora a través de una red.

La primer capa genera el flujo de bytes de aplicación, que es el conjunto de datos que debe recibir el otro equipo. Entonces, dicho bloque de datos es sometido a una serie de procesos con un orden determinado, que permite a los dispositivos comunicarse. Esto es la implementación del protocolo.

Una capa cualquiera dentro de la pila de protocolos implementada, recibe un bloque de datos de la capa inmediatamente superior. A ese bloque de datos la capa actual le anexa un conjunto de datos relativo a los servicios que dicha capa ofrece dentro de la pila de protocolos implementadas, conjunto de datos que se denomina cabecera de dicha capa. Obsérvese que el conjunto de datos que se toman de la capa superior, son anexados a la cabecera, pero en ningún momento son interpretados o modificado su contenido. Esto se debe a que a una capa no le concierne que datos hay en el bloque de datos que le envíen. Ella se encarga de anexarle la cabecera, realizar algunas otras funciones, y remitirlo a la siguiente capa inferior, o transmitirlo si se trata de la ultima capa de la pila. Al conjunto de cabecera + datos de la capa superior se le conoce como Unidad de datos del protocolo (PDU). Al proceso de que una capa n reciba una PDU de la capa n+1, le anexe la cabecera al bloque de datos, y lo transmita a la capa siguiente, se le conoce como encapsulamiento.

Luego de pasar por todas las capas y de realizarse procesos idénticos en cada una de ellas, el bloque de información es transmitido a nivel físico a través del medio. Al llegar al otro sistema, este comienza a interpretar las cabeceras. Al llegar a la capa n, dicha capa debe tener asegurado que la cabecera de la información que recibió es la cabecera generada por su misma capa en el sistema transmisor.

La capa n del sistema receptor conoce la estructura de la cabecera, porque la sintaxis y la semántica de la misma esta definida en el protocolo que ella implementa. De esta forma, cada bloque de bytes en la cabecera tiene un sentido especifico que le permiten realizar las acciones necesarias, para posteriormente entregar la PDU a la capa adyacente superior.

De esta forma, mediante el protocolo (mejor dicho, la implementación del protocolo) se comunican las capas pares.

*Bibliografía*

* [STA]: Stallings, “Comunicaciones y redes de computadoras”. 7ma edición. Capítulos 1,2
* [KUR]: Kurose, J., Ross, K., “Redes de Computadores. Un enfoque descendente basado en Internet”. 2003. 2ª Edición en Español, Pearson Education. Capítulo 1.
* [TOL]: Diapositivas de clase. Gabriel Tolosa. “Enlace al documento”:http://www.tyr.unlu.edu.ar/cms/files/02-Protocolos%20y%20OSI_0.pdf

*Notas al pie:*

fn1. Algunos puntos se transcriben de manera literal del libro.