QuarkBlog_2.0

So what is Emacs’s kryptonite? Low memory and disk space.

Crees que lo has visto todo cuando en la eterna batalla entre el bie.. digo… entre Vi/Emacs, de repente … zas en toda la boca!

En este artículo voy a explicar cómo hacer uso del operador JOIN del álgebra relacional en el mundo real de las bases de datos y las ventajas que reporta en la selección de datos. No pongáis caras que no voy a hablar ni de álgebra relacional ni de teoría de conjuntos. Esto son JOINs para seres humanos

Qué es una JOIN

Es una operación que combina registros de dos tablas en una base de datos relacional que resulta en una nueva tabla (temporal) llamada tabla de JOIN. En el lenguaje de consulta SQL hay dos tipos de JOIN: INNER y OUTER, si bien cada vendedor añade a sus productos modificaciones y atajos para hacer más versátiles estas operaciones.

Como caso especial, una tabla (tabla base, vista o una tabla JOIN) puede realizar la operación JOIN sobre ella misma otra vez. Esto se conoce como self-JOIN.

Matemáticamente, un JOIN es una relación de composición. Estas son las operaciones fundamentales en el álgebra relacional.

Supongamos que tenemos dos tablas: una de películas y otra de directores relacionadas entre sí:

Si quiero sacar todas las peliculas y el nombre de su director haría lo siguiente:

Internamente la base de datos crearía una tabla temporal con todas las filas de la tabla movies cruzadas a su vez con todas las filas de la tabla directors, para después seleccionar las filas que cumplen la condición m.id = d.id. En total maneja 4×3 = 12 filas para obtener un resultado final de 4 registros.

En este caso no es problemático, pero cuando tenemos una tabla de un millón de registros y otra de diez millones, la cosa se vuelve muy fea: la base de datos tiene que manejar 10.000.000.000.000 filas cuando el resultado final quizá este formado por unas pocas decenas.

Aqui es donde entran en juego los JOINs: cuando aplicamos esa operación, la base de datos sólo devuelve el conjunto de filas afectadas por el JOIN, descartando todas las demás.

NOTA: esto no siempre es cierto, ya que las bases de datos modernas disponen de un optimizador de consultas que en determinados casos convertirá la sentencia SQL con el tradicional WHERE en una JOIN. Como he dicho en determinados casos funcionará bien, en otros no.

La sentencia reescrita como una JOIN quedaría de la siguiente manera:

INNER, OUTER, LEFT, … ¿Cuál utilizo en cada momento?

El circulo T1 representa todos los registros de nuestra primera tabla mientras que el circulo T2 representa todos los registros de la segunda tabla. Hay una intersección entre los dos circulos, eso representa los registros de ambas tablas que están relacionados entre sí por sus claves ajenas y primarias. ¿Fácil, no?

El color azul representará los datos que devuelve cada tipo de JOIN.

INNER JOIN

Una INNER JOIN sólo devuelve aquellos registros que coinciden en ambas tablas. Así cada registro que devuelva T1 debe tener su pareja en T2 enlazada por una clave ajena. En términos de lógica de primer orden sería equivalente al operador AND.

OUTER JOIN

Una OUTER JOIN es la operación complementaria a una INNER JOIN. Sólo devuelve aquellos registros que no estén emparejados en T1 y en T2. En términos de lógica de primer orden sería equivalente a la operación NOT AND.

LEFT JOIN

Una LEFT JOIN devuelve los registros que están en la tabla de la izquierda (T1) tanto si tienen pareja en T2 como si no.

Si tienen pareja, devuelve el dato relacionado. Si no, rellena los huecos con NULL.

Es posible hacer la misma operación con la tabla de la derecha, en ese caso estaríamos hablando de una RIGHT JOIN pero lo habitual es utilizar como pivote siempre la izquierda.

LEFT OUTER JOIN

Una LEFT OUTER JOIN combina las ideas de la LEFT JOIN y la OUTER JOIN. Basicamente si utilizas una LEFT OUTER JOIN obendrás los registros de la tabla izquierda que no emparejan con ninguno de los de la tabla de la derecha.

De nuevo, se puede realizar la operación equivalente en la tabla de la derecha aunque no suele ser lo habitual.

θ JOIN

La composición Theta es el producto cartesiano de dos tablas. Existe como operación matemática pero normalmente no es una consulta que la gente utilice, porque devuelve todos los registros de todas las tablas.

Más sobre JOINs

Dependiendo del RDBMS que utilicéis, os será posible utilizar más tipos de composiciones (por ejemplo MySQL soporta las NATURAL JOIN y STRAIGHT JOIN) así como definir composiciones que afecten a mas de dos tablas.

Estas que he comentado están disponibles en la mayoría de las bases de datos modernas.

Acabo de descubrir que hay una copia integra de esta película/documental en Google Video, y está en español. Esta película narra el nacimiento de Apple y Microsoft y las rencillas entre ellos e IBM.

Si bien todos los hechos que se narran en la película son ciertos, no se pueden tomar con rigor histórico puesto que algunas situaciones han sido exageradas u omitidas en busca de hacer la historia más adecuada al formato cinematográfico.

En cualquier caso es una buena forma de entender cómo los movimientos liberales de principios de la década de los 70 junto con la explosión tecnológica en la universidades de Estados Unidos dio como resultado la cultura hacker, pero los hackers de verdad.

En la película podemos ver al Steve Jobs visionario y mesiánico capaz de hacer que la gente se tire por un precipicio tan sólo con mover un dedo, el germen de las actuales keynotes También sale Ballmer, muy en su linea de orangután en celo.

Piratas de Silicon Valley en Google Video

El post de Jeff Attwood Coding Horror: Why Can’t Programmers.. Program? causó un revuelo considerable, tanto que hasta él mismo se vio desbordado.

Desde entonces un montón de gente —herida en su orgullo ingenieril y con mucho más tiempo libre que yo— se dedicó a resolver el problemita de marras de la forma mas freak posible.

• FizzBuzz resuelto en Basic, Forth, Perl, PHP, Pascal, Lisp, XSLT y … Brainfuck!!
• FizzBuzz resuelto en ensamblador del micro Motorola Mostek 6502, porque con 8bits basta
• FizzBuzz resuelto en C#, C, C++ y C/C++ con funciones inline en ensamblador.
• FizzBuzz resuelto en Smalltalk.
• Pero mi preferido es este, fizzBuzz resuelto en C++ utilizando mensajes de error del compilador. Se me hace difícil pensar en algo más freak que esto.

Y bien, ¿pasarían la entrevista estas soluciones?

Esta es una traducción de un post (hecha por Electriblog) del blog de Mark Shuttleworth, más conocido por sus viajes por el espacio y ser la cabeza del proyecto Ubuntu.

Hay algunas ideas que no funcionan, pero son lo suficientemente atractivas para condenarse a ser probadas una y otra vez.

DRM es una de esas ideas.

Recientemente me quedé estupefacto al ver como la clave (o llave) universal (processing key) para *todos* los discos HD producidos hasta la fecha ha sido descubierta y publicada. Me imagino que esto llevará al desentramado de los esquemas de protección de contenido del Blu-Ray y HD-DVD antes de que el 1% del mercado potencial de estos reproductores sea alcanzado.

Son buenas noticias, de hecho, porque tal vez inspire a otras personas a reconsiderar el instalar estos esquemas.

Ya hemos pasado por esto. El sistema de encriptación DVD-CSS fue craqueado rápidamente, de manera elegante y legal. Los propietarios de contenidos - Hollywood S.A. - se indignaron y persiguieron a cualquier persona que siquiera hiciera referencia al software libre que realizaba el trivial proceso de desencriptación. Usaron el DCMA (Digital Millenium Copyright Act, la nueva ley de Derecho a Copia de los EEUU vigente desde 1998 y similar a la EUCD europea) como una forma de extender las leyes de derecho a copia más allá de su intención original. Se comportaron como un venado frente a las luces de un coche - cegados por la percepción de la incipiente fatalidad en un mundo donde sus contenidos fluyen rápida y eficientemente, incapaces de ver las potenciales rutas de escape hacia la seguridad mientras esas luces se acercan. Sus mercados estaban cambiando, enfrentando nuevas oportunidades y nuevos retos, y ellos querían desacelerar el ritmo del cambio.
Los propietarios de contenido piensan que el DRM puede desacelerar la evolución natural del mercado.

En el caso de las películas, una de las mayores causas de la adopción del DRM fue la renuencia de la industria a abandonar la era analógica. Las películas son distribuidas típicamente a los cines en film de celuloide, en grandes rollos de film. Cuesta mucho duplicar y distribuir esos films a los cines que van a proyectarlas. Así que la realidad de la distribución ha definido la estrategia de estreno de muchas películas. Las compañías imprimen un cierto número de films y los envían a los cines de unos pocos países, Cuando los pases terminan en esos países esas mismas cintas son enviadas a nuevos países. Es por esto que las películas son típicamente estrenadas en distintas fechas en distintos países. Es únicamente una limitación física en la logística de mover grandes cantidades de celuloide y no tiene lugar en la era actual de la distribución digital global e instantánea.

Por supuesto, cuando aparecieron los DVDs los dueños de los contenidos no querían que se comprara el DVD en los EEUU y luego se enviara a Australia donde la película aún no había sido estrenada. De allí surge el daño cerebral que llamamos codificación regional - los propietarios de contenidos diseñaron el DVD-CSS no solo para que estuviera encriptado, sino también para que contuviera un marcador de región que previniera que fuese visionado en cualquier otro lugar que no fuera el mercado para el que había sido lanzado. Si vives fuera de los EEUU y has intentado comprar un documental de pequeña tirada en los EEUU sabrás a lo que me refiero por daño cerebral: no se puede ver fuera de los EEUU, y si la demanda en tu región no es suficiente como para justificar una edición en tu codificación de región, lo lamentamos por ti.

La verdad es que la supervivencia en cualquier mercado depende de tu habilidad para mantenerte al tanto de lo que es posible. Los dueños de las películas necesitan impulsar fuertemente la distribución global digital - eso les permitirá estrenar las películas en los cines globalmente el mismo día (previa traducción), de la misma manera en que tu y yo podemos ver de todo en YouTube el mismo día en que se sube al sitio.

La verdad es también que, conforme cambia el panorama, distintos modelos de negocios van y vienen en su viabilidad. Aquellos que tratan de imponer reglas analógicas en contenido digital se encontrarán en el lado opuesto de la marejada. Lo lamento por vosotros. Es necesario innovar (de nuevo, ¡de vez en cuando!) y mantenerse a la vanguardia , quizás estar dispuesto a canibalizar tu propio negocio actual - aunque para se honestos canibalizar el negocio de alguien más es mucho más atractivo.

Ahora mismo los dueños del contenido deberían pensar en como pueden sacar provecho de este mundo conectado en red, no luchar contra la corriente, y también en como reestructurar los costos inherentes a sus propios negocios para ponerlos más en línea con el tipo de dividendos que son posibles en un mundo totalmente digital.

Aquí tienen unas dosis de realidad:

1. Cualquier DRM que contenga llaves guardadas en local (offline) será roto. No importa tampoco si esa llave se almacena mayormente en hardware protegido, porque tarde o temprano uno de ellos será descifrado. Y si quieres que tu contenido sea visualizado en ordenadores tendrás que tener visores por software. Se los rompe más rápidamente. Así que, aunque trates de proteger cada camino analógico (mi favorito es la iniciativa de canales encriptados ¡desde el equipo hi-fi a los altavoces!) alguien, en alguna parte, tendrá acceso directo a tu contenido. Todo lo que estarás haciendo es encarecer el costo de tu infraestructura - Me pregunto cual será el costo de toda la criptografía asociada con el HD-DVD/Blu-Ray, cuando tomas en cuenta la complejidad, el diseño y el costo incremental de IP, hardware y software para cada reproductor listo para HD existente.
2. La alternativa para el almacenamiento de llaves en local es el acceso solo por emisión (streaming), y es igualmente desprotegible. El sistema de emisión clásico, la TV, fue pirateado (hacked) cuando apareció el vídeo y se lo consideró uso razonable. Hoy vemos a una de las compañías de radio por satélite (creo que Sirius o XM) ser demandadas por los propietarios de contenidos por su apoyo a un dispositivo que graba sus transmisiones con calidad CD a reproductores de MP3. Los servicios de emisión de contenido web que no te permiten guardar el contenido localmente son una forma inútil de protección, fácil y regularmente contrarrestados. Y por supuesto, no todo el mundo quiere estar conectado cuando está viendo sus contenidos.
3. Todo lo que se necesita es un crack (una grieta). Para cualquier contenido, todo lo que se necesita es una copia desprotegida y tendríamos que asumir que cualquiera que lo quisiera lo tendría. Tanto sea software de un sitio de warez o música de un servicio de MP3 en Rusia, o un sistema de intercambio de ficheros, no se puede tapar todos los huecos. Asumámoslo, la gente o bien quiere pagar por tus contenidos o bien no y tu mejor estrategia es ponérselo lo más fácil posible a quienes quieren cumplir con la ley para que lo hagan. Eso no se traduce en demandar a abuelitas y niños de colegio, se traduce en sistemas de distribución que permitan a todo el mundo hacer lo correcto, y fácilmente.
4. Alguien encontrará un modelo de negocios que no dependa de la vieja forma de pensar, y si no eres tú entonces te comerán vivo. Probablemente los demandes, pero no será más que una acción defensiva ya que la industria se reforma alrededor del nuevo modelo de negocios, sin ti. Y por la industria no me refiero a tus competidores - ellos estarán probablemente en el mismo agujero - sino tus proveedores y tus clientes. Los distribuidores de contenidos están en riesgo aquí, no los creadores o los consumidores.

El miedo de la industria a Napster los guió por la madriguera del conejo. Microsoft, Apple, Sony y otros desarrollaron sistemas DRM y se lo vendieron a la industria de la música como un acercamiento “sano” a la distribución online de música. Fue un buen discurso: “Todos los beneficios de distribución de las descargas, todos los beneficios económicos del vinilo”, en pocas palabras.

De todos los contendientes, Sony fue claramente excluido porque es un propietario de contenido y no hay forma de que el resto de la industria le pague un impuesto tecnológico a un competidor (de la misma forma en que el Symbian de Nokia no ganó demasiado peso con los otros grandes porque está muy atado a Nokia). Microsoft no tenía futuro, porque son obviamente muy poderosos y la industria de la música puede ver venirse una toma de poder hostil a diez kilómetros. ¡Pero la tierna y mimosa Apple no hará daño a nadie!. Así que el iTunes y el AAC fueron rotunda y ampliamente adoptados y Apple triunfó en convertir la distribución y ejecución de música digital legal en un monopolio virtual. Apple jugó un juego magistral y sacó total ventaja de los miedos de la industria de la música.

La alegre ironía en este relato es que recientemente Steve Jobs hizo un llamamiento a la industria de la música a adoptar la distribución libre de DRM, dando a Apple una alta basa moral. ¡muy, muy bien jugado realmente!.

Hace unos años estuve en Davos, en el Foro Mundial Económico. Era tal vez 2002 o 2003, unos años después de la explosión de la burbuja puntocom. Eran los tempranos días de la iPaq, a todos los de la conferencia se les había prestado una. Recuerdo claramente estar sentado en una sesión que era mas o menos una confesión de CEOs, una especie de acto de “absolución por admisión de estupidez”. Uno por uno, figuras muy reconocidas, se fueron poniendo de pie y contaron historias de horror sobre como habían permitido a los internos manejar el manicomio y habían permitido a veinteañeros decirles como gastar el capital de sus accionistas en proyectos puntocom. Para mi esto fue muy interesante, ya que me había pasado el tiempo durante la época de las puntocom aconsejando a las grandes compañías que no sobre-invirtieran, que se enfocaran en mejorar sus relaciones con los clientes y sus socios a través de la red y no intentaran conquistar el mundo de la noche a la mañana.

Pero el golpe real vino al final, cuando la cabeza de Sony USA y también responsable de su división de música, Sir Stinger, se paró para hacer sus paces. Se regodeo largamente sobre como Sony NO había invertido en las puntocom y como debía ser el único en la sala que no se había dejado llevar por los jovencillos. Fue un discurso muy divertido y muy ingenioso que le valió un gran aplauso y muchas risas. Me quedé pensando si el tendría alguna idea de cuantas canciones podrían entrar en la iPaq que tenía en su bolsillo, o cuanto tardarían en descargarlas. Sospeché que no. De todos los CEOs que hablaron ese día pensé que él sería el mejor candidato para ser arrollado pronto y fuertemente por el tren digital.

Sir Stringer es ahora el CEO de Sony Mundial. Es curioso, entonces, que la Sony PS3 haya sido retrasada para terminar los trabajos en su sistema de DRM.

Algunas malas ideas son demasiado atractivas para morir de una vez por todas.

1. Donald E. Knuth no necesita compiladores. Él sabe que funciona.
2. Donald E. Knuth puede leer APL.
3. El viajante de comercio visita a Donald E. Knuth primero.
4. Donald E. Knuth puede decirte si el programa va a parar, sin bloqueo.
5. Hay quien dice que Chuck Norris creó a Dios - Donald E. Knuth creó a Chuck Norris.
6. En la cena de los filosofos morían de hambre hasta que Donald E. Knuth les sirvió.Los filósofos se mueren de hambre en la cena hasta que alguien sirve a Donald E. Knuth.
7. ¿Puede Donald E. Knuth imaginar un problema computacional tan complejo que incluso Él mismo no pueda resolver en tiempo constante? Si, y también lo puede resolver en tiempo constante.
8. Donald E. Knuth no duerme. Programa.
9. Una nueva clase de complejidad computacional fue inventada después de nacer Donal Knuth: la complejidad Knuth-tacional.
10. Para Donald E. Knuth P=NP

Donald E. Knuth Facts

Mito 1: ¡No tengo tiempo para hacer tests!

Esta es la excusa más frecuente de aquellos que no quieren escribir tests. Es verdad, se necesita algo más de tiempo para escribir tests, pero si de verdad quieres escribir tests estoy seguro de que vas a encontrar el tiempo necesario.

Mito 2: ¡Los clientes no me pagan por hacer tests!

Esto a menudo es verdad, por lo menos si le dices a tu cliente que necesitas 40 horas más para hacer los tests. Creo que la mejor táctica es no mencionar la palabra testing como un tema separado y tratar la producción de código y los tests como una unidad. Asi que para estimar el coste de una funcionalidad, suma el coste de producción del código mas los tests, y presenta el resultado al cliente. Si el cliente acepta la oferta, automáticamente te pagará por el esfuerzo de hacer los tests. De todas formas repercute en la calidad final del producto así que el cliente resulta el mayor beneficiado.

Mito 3: ¡Testear me hace ir más despacio!

En un primer momento puede parecer que tengas que escribir mucho más código, lo que significa menos producción de código útil por unidad de tiempo. Pero a la larga se nota el beneficio: necesitas mucho menos tiempo para depurar tu código, es más sencillo refactorizar sin romper la funcionalidad, y tienes que escribir menos documentación porque los tests describen que es lo que hace tu programa y como debería ser utilizado. Además hay cientos de frameworks para todos los lenguajes de programación que te ayudan en la labor de escribir tests y comprobar posteriormente el resultado de manera automática.

¡A testear todo el mundo!