Blog de Unai Estebanez

Recientemente hemos tenido un poco de choteo en el curro con el tema de mi agenda, me explicaré.
Yo utilizo una agenda……. ¡de papel!, y claro, entre Informáticos y Telecos esto lleva a todo tipo de bromas.
El caso es que mi elección no es aleatoria, es meditada y he elegido una agenda de papel con pleno uso de razón :-).
Mis razones son las siguientes:

• Tiene una batería ilimitada
• Nunca se cuelga
• No necesita conexión a Internet para funcionar
• No necesita actualizaciones para corregir bugs
• Esta disponible inmediatamente, no tarda nada en cargar
• Introducir datos en ella es mucho más rápido que en cualquier dispositivo electrónico (haz la prueba con un compañero, rétale a introducir una cita y veras como acabas antes en papel)
• No necesitas leer un manual de instrucciones para saber como funciona
• Es más flexible en cuanto al tipo de datos que puedes introducir
• No importa que se te caiga al suelo
• No cansa la vista
• Es muchísimo más barata, de hecho me ha salido gratis
• Opera en un rango de temperaturas muy amplio
• El tiempo de vida del papel es variable dependiendo del tipo pero suele superar los 100 años

Evidentemente tiene desventajas:

• No te avisa de tareas próximas (esto se puede solventar añadiendo una entrada X días antes en la agenda de papel).
• Cada año pierdes los datos antiguos (no necesito saber que el año pasado fui al dentista el dia X), aunque nada te impide guardar agendas viejas
• No se permiten búsquedas (tampoco lo he necesitado nunca)
• Otras que no echo en falta

El caso es que sigo sosteniendo que, para mi (no hablo de alguien con una agenda muy complicada),es la mejor solución. Es sencilla y eficaz y eso es lo que cuenta.

Creo que de un tiempo a esta parte mucha gente ha perdido el norte, eligen soluciones por la tecnología que utiliza no por su funcionalidad real y esto se da mucho sobre todo entre la gente que frecuento (Ingenieros) y esto es extraño porque, precisamente de un Ingeniero, se espera que sea capaz de elegir de forma racional una solución a un problema.

En fin, este post me da mucho que pensar y abre vías para otro próximo en el que recordar aquellos años donde todavía existían cabinas de teléfono.

Hoy me he llevado una grata sorpresa al ir a descargarme la última versión del programa de dibujo DIA
Buscando en la zona de plugins de python he encontrado ¡mi pequeño plugin para exportar máquinas de estado UML a texto!. Desde luego es gratificante y a pesar de su sencillez me siento contento con el, espero que a alguien le pueda servir de ayuda o al menos como base para otros plugins más complejos.
Se puede encontrar en la Zona de python para el DIA y se llama “sm_export.py”.
Estupendo, empiezo el día con una sorpresa agradable.

He creado una nueva sección donde dejar mis herramientas, de momento empiezo con un sencillo front-end para el rsync. Es muy simplón pero sirve para sincronizar mis discos duros externos y tener siempre un backup.

Si, me ha costado años pasar por el aro, inclinar la cabeza y reconocerlo pero, es así, no hay más remedio que mantener la compatibilidad hacia atrás.

Si no mantienes esta compatibilidad es muy difícil “vender” tu solución y atraer a los usuarios. ¿Porqué iban a querer usar tu solución?.

Ahora resulta que tienen que “tirar a la basura” todo lo que ellos ya tenían con su antigua solución, ya estaban entrenados con la antigua solución y saben como trabajar con ella. Posiblemente incluso tenga errores la antigua versión pero han descubierto como “esquivar” estos problemas y sacar su trabajo diario adelante. Además las nuevas versiones de cualquier cosa suelen traer consigo una mayor funcionalidad pero también fallos nuevos.

Como ejemplo, y simplificando bastante en aras de una mayor claridad, he implementado un sistema que a partir de un diagrama UML de máquinas de estados, crea un código neutro descriptivo de la máquina y luego posteriormente una runtime crea la máquina a partir de esta descripción y la ejecuta. Este sistema resuelve varios de los problemas de los que adolece el antiguo sistema que tenemos pero, que curioso, nadie lo usa (excepto yo).

El porque esta claro, la gente está bastante ocupada con su día a día y no se quieren arriesgar a usar algo que puede que tener fallos y encima desconocen (tienen que aprender). Prefieren esperar a que otro la use y además resulta que no la pueden usar en proyectos viejos por no ser compatible.

En fin, la realidad es dura, pero he aprendido del error, hay que mantener a toda costa la compatibilidad hacia atrás. Ahora bien, ¿como hacer esto si el antiguo sistema tiene limitaciones insalvables?. ¿Emulando?, tal vez los tiros vayan por ahi…..

Al final mi mujer, que me conoce y sabe que soy lector habitual, no se ha resistido y me ha regalado un e-book.
Ella lo ha hecho con toda su buena intención pero, es normal, se ha perdido en el mar de dispositivos, formatos, etc.
Me regaló un dispositivo llamado SPCInternet 550, se puede encontrar información en la dirección http://www.spcinternet.com/informacion-producto/SPCinternet-5500/
¡Que decepción!, los motivos:

• Los menús son lentísimos, el interfaz gráfico es imposible de usar sin desquiciarse.
• Los PDFs que se bajan directamente de Internet son incomodísimos de visualizar.
• El software de conversión a formatos de e-book no tiene en su lista a este dispositivo.
• El USB es 1.1, ¿en el año 2010?,¿tanto se ahorran por usar USB 1.1?, ¿tanto consume USB 2.0?
• Los índices en los libros brillan por su ausencia.
• No soporta EPUB con DRM, y yo tengo por costumbre comprar libros.
• Solo soporta PDF,FB2 y TXT
• No tiene pantalla tactil, 3G, Wifi o cualquier otro extra.

En fin, una decepción total. Por supuesto es un dispositivo mediocre, pero vale 200 y pico euros, no lo regalan con un pedido de pizzas.

En mi opinión es excesivamente caro para la funcionalidad que ofrece.

La gota que colmó el vaso fue el decir, - Vale, no me importa pagar por libros bien formateados. (de hecho compro habitualmente libros). Acto seguido voy a “la casa del libro”, pincho en “libros electrónicos” y hay disponibles para la compra, pero, ¡vaya hombre!, son EPUB con DRM y mi “cacharrito” no soporta EPUB con DRM.

Total, reflexionando un poco, tengo un libro electrónico que no puede leer libros que me compre legalmente, un libro que no visualiza correctamente lo que me bajo de Internet. ¿Para que puedo utilizar este dispositivo?.

Pues nada, de vuelta a su estantería, lo he devuelto a tiempo, gracias a dios.

Ahora el siguiente paso es conseguir dar con un libro electrónico decente,pero, ¿e-book o iPad?. Fue ver el iPad en la tienda y enamorarme de un flechazo, ¡vaya interfaz de usuario!, ¡vaya agilidad!, así si se puede leer libros electrónicos, navegar, ver el correo, etc… y por unos 100 euros más de lo que valdría un libro electrónico decente. Ahora bien, no tiene tinta electrónica, es una pantalla de toda la vida, de las que cansan los ojos. Y yo leo bastante.

¿iPad o e-book?, esa es la cuestión….

Dado que existe cierta confusión sobre los conceptos básicos de video, audio, formatos, contenedores,muxers y demás parafernalia vamos a comentar lo más básico por lo menos para entender algo cuando leemos documentos.

Streams, Muxers, Codecs, Contenedores y demas parafernalia

¿Qué es un codec?

Es imprescindible para sobrevivir en esta maraña de conceptos entender la diferencia entre un codec y un contenedor.

Un codec es un algoritmo de compresión que se utiliza para reducir el tamaño de los datos a transmitir (video, audio o lo que sea), llamados streams.

Tenemos codecs para audio como por ejemplo el conocido MP3 o el ogg-vorbis

Tenemos codecs para video como por ejemplo el DivX el MPEG-1,MPEG-2 o MPEG-4.

¿Qué es un contenedor?

Pongamos una analogía para simplificar las cosas. Pensemos en un contenedor como si fuese un paquete postal, la típica caja de embalar, con algo dentro. Cuando recibes la caja piensas:

- ¡mola!, una caja, pero, quiero lo de dentro

No nos importa la caja en si, queremos obtener el contenido, ¿como?, coges un cutter y la abres.

El formato contenedor sigue, básicamente, el mismo principio. Contiene dentro uno o varios streams (recuerda, son los datos de audio o video) comprimidos con un codec. Lo más habitual es que dentro de la caja (el contenedor) haya un stream de audio y otro de video.

Contenedores habituales son, AVI, Ogg, MOV, ASF, MP4.

Los streams que van dentro del contenedor estarán comprimidos con diferents codecs. En un mundo ideal podríamos poner cualquier stream comprimido con cualquier codec en cualquier formato contenedor. Pero, lamentablemente, esto no es así y hay incompatibilidades por lo que no todo contenedor puede llevar cualquier stream.

¿Que es un muxer?

Supongamos que queremos enviar una caja con un video y un audio dentro. Veamos como hacerlo:

• Obtienes un stream de video y un stream de audio
• Codificas cada stream con un codec
• Multiplexas (muxer) ambos streams en un solo fichero
• Metes en la caja de embalar la mezcla

Reproducción del video

Ahora recibimos la caja, la abrimos, separamos los streams (demux) en archivos diferentes, audio, video, subtitulos, etc. Este proceso no transforma ni procesa los streams.

Despues, se utiliza el decoder adecuado para descomprimir cada stream y reproducir el conjunto. Esto lo hará un software concreto, como el windows media player, el VLC, Apple QuickTime, etc.

¿Qué es un Renderizador (Renderer)?

Nos falta un paso que hemos omitido en el proceso. Este paso es el de reproducir el stream en un dispositivo hardware. Esto lo hara un renderizador que suelen implementar los players.

Un Renderizador es similar a un Codec pero la salida final no es otro stream sino una pantalla, una tarjeta de video, etc.

Confusiones con MPEG

MPEG es un tanto especial y origina mucha confusión por lo siguiente:

• MPEG es un codec y hay varias versiones MPEG-1,MPEG-2,MPEG-4,…
• MPEG también es un formato contenedor. A veces se le denomina como sistema MPEG. Hay diferentes tipos: ES,PS y TS.

Al grano, el Streaming

Una vez aclarados conceptos básicos vamos a hablar del streaming propiamente dicho.

El streaming consiste en reproducir streams en tiempo real y recibiéndolos, generalmente, a través de Internet.
Ahora bien, un stream de video suele ser algo pesado(ocupa mucho) para recibirlo entero y reproducirlo, imagina que para ver un video de YouTube esperas a descargarlo entero, tardarías (dependiendo de tu ancho de banda) minutos antes de comenzar a verlo. O supongamos un caso peor, quieres hacer videoconferencia, no es posible recibir el stream completo puesto que se está generando mientras dos personas hablan y se ven, se supone que se va generando y recibiendo en ambos extremos y en tiempo real.

El truco está en no esperar a recibir todo el stream e ir reproduciendo los trocitos que van llegando poco a poco. Como siempre veremos que hay varias formas de conseguir el mismo objetivo, es aquí donde entran en juego los protocolos.

Confusión típica

Hay que tener bien claro lo siguiente, al hacer streaming no se envia el fichero en disco, por ejemplo un fichero .mov. Se envian los streams de audio y video y en el formato en el que estén estos codificados. Recordemos que un contenedor puede alojar streams en diferentes formatos.

Esto se debe tener en cuenta a la hora de transmitir porque no todos los formatos son soportados por todos los reproductores. Al hacer uso de protocolos como RTP los formatos soportados suelen ser limitados.

Los protocolos para el streaming

Tradicionalmente lo que ha interesado en la transmisión de datos es que las dos partes reciban una copia exacta de los datos,¿alguien querría un texto incompleto?. Ahora bien, hablando de vídeo, no resulta tan importante el que se pierda un fotograma como el que el vídeo tenga que dar saltos parándose cada dos por tres porque no han llegado absolutamente todos los datos. Es por este motivo por el que para transmitir vídeo se priorizará el que sea ágil su reproducción antes que esta sea completa (no perdamos fotogramas).
Por estos motivos se han ideado protocolos de transmisión de datos en los que prima la velocidad y estos son los que usaremos para hacer streaming.

HTTP y FTP, y en general todos los que funcionan sobre TCP son protocolos que priman la exactitud de la información y no la velocidad (garantizan que se entregan los datos y además el orden en que se entregan). Por ello, generalmente, se evita usar estos protocolos para hacer streaming. En su lugar se usarán protocolos basados en UDP, que no garantiza la entrega ni el orden de entrega, pero que es más rápido. Apoyándose en este protocolo (UDP) se ha ideado un estándar en Internet para la retransmisión de audio y vídeo, el protocolo RTP.

El protocolo RTP

RTP nos proporcionara entrega de datos en tiempo real independientemente del protocolo subyacente (TCP o UDP), aunque generalmente usaremos UDP.
RTP pude usarse como unicast(uno sirve a otro) o como multicast(uno sirve a muchos). Si lo utilizamos como unicast, copias separadas de los datos son entregadas a cada destinatario. Si usamos multicast los datos se envían desde el servidor solo una vez y la red es responsable de transmitir esos datos a múltiples destinos. El multicast es la forma más eficiente para muchas aplicaciones, como la videoconferencia.

Servicios RTP

RTP te permite identificar el tipo de datos que se está transmitiendo, determinar el orden en que los paquetes debieran ser presentados y sincronizar los streams de diferentes fuentes.
Los paquetes RTP no tienen garantizado el orden de entrega, es más, no está garantizado que lleguen todos. Es tarea del receptor reconstruir la secuencia enviada por el servidor y detectar las pérdidas de datos.
Dado que RTP no proporciona un mecanismo para asegurar la entrega a tiempo u otras garantías de calidad del servicio, se acompaña de un protocolo de control (RTCP) que nos permite monitorizar la calidad de la distribución de datos. RTPC También nos proporciona mecanismos de control e identificación de las transmisiones RTP.

Arquitectura RTP

Una sesión RTP es una asociación entre un grupo de aplicaciones comunicandose con RTP. Una sesión se identifica por una dirección de red y un par de puertos. Un puerto se usa para transmitir los datos y el otro se usa para el control (RTCP).

Un participante es una máquina que, valga la redundancia, participa en la sesión. Participar en la sesión puede consitir, en la simple recepción pasiva de datos(receptor), en transmitir datos de forma activa(servidor), o ambos.

Cada medio (audio, video) se transmite en una sesión diferente. Por ejemplo, si en una conferencia se va a usar audio y video, se usará una sesión para transmitir audio y otra para transmitir video. Esto permite a los participantes elegir que medios quieren reproducir, por ejemplo, uno de los participantes con poco ancho de banda pudiera querer solo recibir el audio.

El protocolo de control RTCP

Cada participante en la sesión recibirá periodicamente paquetes RTCP. Estos paquetes RTCP pueden contener información sobre la calidad del servicio, información sobre la fuente del contenido que se esta transmitiendo y estadísticas sobre los datos que se están transmitiendo.

Tenemos los siguientes tipos de paquetes RTCP:

• Reporte del remitente(Sender Report - SR)
• Reporte del receptor (Receiver Report - RR)
• Descripción de la fuente (Source DEScription - SDES)
• Bye
• Específicos de la aplicación

Los paquetes RTCP son “apilables” de forma que se envía siempre un paquete compuesto que contiene al menos dos de estos paquetes descritos, un report y una descripción de la fuente.

Todos los participantes en la sesión mandan paquetes RTCP. Un participante que ha enviado paquetes de datos mandará un reporte del remitente(SR). El SR contiene el número total de paquetes y bytes enviados así como información que puede utilizarse para sincronizar los streams de diferentes sesiones.

Los participantes en la sesión mandan periodicamente Reportes del receptor (RR) a todas las fuentes de las que están recibiendo datos. Un RR contiene información sobre el número de paquetes perdidos, el número de secuencia más alto recibido y una marca de tiempo que puede utilizarse para estimar el retardo de ida y vuelta entre el emisor y el receptor.

El primer paquete en un paquete compuesto RTCP tiene que ser un paquete de reporte, incluso si no se han enviado o recibido datos, en cuyo caso se envía un RR vacío.

Todos los paquetes compuesto RTCP deben incluir una descripción del origen (Source DEScription) que contiene el nombre canónico (CNAME) que identifica el origen. Se puede añadir información aicional en el SDES como el nombre de la fuente, el email, número de teléfono, localización geográfica, nombre de la aplicación o un mensaje describiendo el estado actual del origen.

Cuando un origen se va a desconectar,manda un paquete BYE. El paquete BYE puede incluir el motivo por el que el participante abandona la sesión.

Los paquetes de aplicación proporcionan un mecanismo para que la aplicación defina y mande información a medida a través de este canal de control.

El protocolo RTSP

El protocolo RTSP (Real Time Streaming Protocol) permite controlar streams multimedia que se distribuyan, por ejemplo, via RTP. El control incluye posicionamiento en el stream, grabación e incluso control del dispositivo.

Un escenario de uso podría ser este:

El cliente accedería a un servidor seb, obtendría un meta-file con indicaciones de como reproducir el video/audio y luego se establecería una conexión RTSP para el control del streaming y una conexión RTP para la distribución del contenido en si.

Veamos un posible intercambio de mensajes entre cliente y servidor. Se puede apreciar en rojo el tipo de mensajes de RTSP como SETUP,PLAY,PAUSE y CLOSE.

Podemos hacer una analogía entre RTSP y el mando del video, el mando simplemente ordena al video que empieze, que pare, que avance, etc. Pero es el video en sí el que reproduce y el canal de transmisión de imágenes no es el del mando.

Formato de contenedor para móviles 3gp

3GP responde a estándar de vídeo de tercera generación.

Es un contenedor multimedia definido por 3GPP para su uso en teléfonos móviles de tercera generación. Es una versión simplificada de MPEG-4 Parte 14 (MP4). Los ficheros 3GP tienen la extensión .3gp o .3g2.

3GP almacena los streams de vídeo como MPEG-4 o H.263 y los streams de audio como AMR-NB o AAC-LC. 3GP describe los tamaños de la imagen y el ancho de banda de forma que los contenidos sean correctamente adaptados a las pantallas de los móviles.

Resoluciones habituales

Cuando hablamos de resoluciones(ancho x alto) las siglas más habituales con las que nos encontraremos (en el mundo de los móviles) son:

• VGA (640×480)
• CIF (352×288)
• QVGA ( 320×240) (Un cuarto de VGA)
• QCIF( 176×144) (Un cuarto de CIF)

Hoy veremos como resolver el problema de la herencia que vimos en el anterior post.
Para ello vamos a usar un nuevo concepto, el de delegación, vamos a delegar funcionalidad en otra clase.

La Delegación consiste en dejar la responsabilidad de una funcionalidad concreta a otra clase.

Veamos como se traduce esto a código, seguiremos con el ejemplo del otro día:
——-
Tablero
——-
Altura: int
Anchura: int
Hexagonos: Hexagono[Anchura][Altura]
————————————–
getHexagono(int,int): Hexagono
setUnit(Unit,int,int)
deleteUnit(Unit,int,int)
getUnit(int,int): Unit

Pero ahora vamos a entrar en el mundo de las 3D sin heredar. Lo que vamos a hacer es que el tablero 3D se cree mediante múltiples tableros 2D a diferentes alturas:

———-
Tablero3D
———-
profundidad: int (coordenada Z)
Capas: Tablero[profundidad]
—————————————————–
getHexagono(int,int,int):Hexagono
setUnit(Unit,int,int,int)
deleteUnit(Unit,int,int,int)
getUnit(int,int,int): Unit

De esta forma cuando se haga una petición cualquiera se usará la coordenada “Z” para acceder al array de Tableros 2D y luego las coordenadas “X” e “Y” para acceder al tablero 2D seleccionado.
De esta forma hemos evitado usar la herencia y violar el principio LSP.

Usaremos la delegación cuando queremos usar la funcionalidad de otra clase sin cambiar un ápice su comportamiento.

En el próximo post veremos que esta asociación que hemos hecho entre dos clases tiene matices, entraremos un poco más en detalles y hablaremos de agregación y composición que son dos sutilezas sobre un mismo concepto.

Hoy hablaré de el principio de sustitución de Liskov (LSP), podeis encontrar más información en wikipedia, más concretamente en este enlace.

Este sencillo principio reza así:
Los subtipos deben ser sustituibles por sus tipos base.

¡Y ya esta!, sencillo y claro.
Este principio tiene que ver con la herencia, pero herencia bien diseñada. Esto implica que cuando heredas de una clase base, debes ser capaz de sustituir tu nueva clase por la clase base sin que ocurran cosas terriblemente malas, de lo contrario, has diseñado incorrectamente tu jerarquía.

Veamos un ejemplo de clase mal diseñada:
Supongamos una clase base llamada “Tablero” ideada para crear un juego de estrategia, esta clase pudiera ser algo como lo siguiente:
——-
Tablero
——-
Altura: int
Anchura: int
Hexagonos: Hexagono[Anchura][Altura]
————————————–
getHexagono(int,int): Hexagono
setUnit(Unit,int,int) -> Pone una unidad(tanque,soldado,etc) en un hexagono
deleteUnit(Unit,int,int)
getUnit(int,int): Unit

Pongamos que ahora queremos ampliar la clase para crear un tablero en 3D así que heredamos de la clase tablero:
———-
Tablero3D
———-
profundidad: int (coordenada Z)
Hexagonos3D: Hexagono[Anchura][Altura][profundidad]
—————————————————–
getHexagono(int,int,int):Hexagono
setUnit(Unit,int,int,int)
deleteUnit(Unit,int,int,int)
getUnit(int,int,int): Unit

Como vemos hemos añadido una tercera coordenada a los métodos, todo parece que marcha, ¿verdad?.
Pues no, ¡error!, intentemos sustituir las llamadas a nuestro tablero 3D por las llamadas originales a la clase base. Ninguno de los métodos de la clase Tablero funciona correctamente en un entorno 3D. Llamar por ejemplo a setUnit(soldado,2,5) no tiene sentido para un tablero 3D. Esto viola el principio LSP.

Tablero tablero = new Tablero3D();
Unit unit = tablero.getUnit(4,5); // ¿que significa esto exactamente?

Es difícil entender el código que utiliza mal la herencia, ¿como se comporta la llamada a “getUnit” con solo dos parámetros cuando estamos en un tablero 3D?, ¿coge por defecto algún valor?, ¿coge el valor más alto o el más bajo?. De aquí no podemos obtener nada bueno, probablemente acabemos con ciertos métodos de nuestra superclase los necesitemos o no.

¿Que opciones tenemos entonces?…… pues la delegación. Veremos en el próximo post que es “delegar” y hablaremos también sobre la composición y la agregación.