La más popular de las bibliotecas de JavaScript, instrumental en cambiar el panorama de este lenguaje, ha sido actualizada una vez más.
Esta versión 1.7 ya está disponible para descarga tanto en el sitio oficial (versión completa o minimizada) como en las redes de distribución de contenido de Google y Microsoft, desde donde conviene apuntarlas en nuestros sitios web para garantizar la mejor eficiencia de acceso.
Algunas de las novedades principales, además de correcciones y mejoras generales, son:
Nueva API de eventos on / off:
Esta sintaxis unifica diferentes maneras de enlazar eventos como las anteriores delegate() o bind(). La sintaxis completa es:
Enormes mejoras en el rendimiento de eventos delegados
Muchos otros frameworks basados en jQuery, al igual que muchas aplicaciones complejas hoy día, usan eventos delegados en forma cada vez más intensiva, por lo que el equipo hizo un arduo trabajo de investigación de los escenarios más típicos y logro mejorar el rendimiento de muchas operaciones en forma dramática. Vean el siguiente cuadro comparativo de velocidad de ejecución de las pruebas en diversos navegadores:
Soporte mejorado para HTML5 en Internet Explorer 6, 7 y 8
Aun utilizando bibliotecas como Modernizr o html5shiv, hay tags como <section> que eran eliminados por estos navegadores. Esta versión de jQuery (que no reemplaza las bibliotecas mencionadas) permite seguir manipulando estos elementos en métodos como .html().
Mejoras en jQuery.Deferred
El objeto jQuery.Deferred es parte del API para ejecución asincrónica. Este objeto representa una promesa de retorno de un proceso que está ejecutándose asincrónicamente, mientras nuestra aplicación puede seguir trabajando en otra cosa o atendiendo a eventos.
Esto ya funcionaba perfectamente, pero en la nueva versión se ha extendido el objeto para poder manejar notificaciones de progreso, de manera de poder reportar el avance, o poder preguntar por el estado en cualquier momento.
Otras mejoras generales
También se mejoró la activación y desactivación de animaciones para hacer más intuitivo el manejo cuando éstas operaciones están anidadas, se agregó soporte para el AMD API (definición de módulos asincrónicos), que unifica varias otras bibliotecas como RequireJS o curl.js para cargar módulos dinámicamente. jQuery contempla ahora estas operaciones correctamente y deja que los procesos de carga reporten realmente cuando el documento está ready. Finalmente esta versión agrega una función muy útil: jQuery.IsNumeric() que indica si un valor es numérico, algo que no siempre es tan fácil de determinar como parece en JavaScript.
La versión 1.0 de estas herramientas para programar Python en Visual Studio finalmente está disponible (gracias a @masaez por el aviso).
Este conjunto de herramientas es gratuito y de código abierto (bajo licencia Apache 2.0), y convierten a Visual Studio (que no es gratuito ni abierto) en una IDE muy completa para Python, soportando tanto CPython (la distribución estándar, no incluida en el paquete) como IronPython, la implementación de Python sobre el runtime de .NET.
Algunas de las características principales que hace atractivo el uso de estas herramientas es que agrega al editor básico con coloreo de sintaxis un buen soporte de Intellisense sobre miembros y firmas, navegación sobre el código como encontrar todas las referencias a un miembros, ir a su definición, o inspeccionar objetos. También soporta depuración local y remota, y perfilamiento para análisis de rendimiento.
Integra por supuesto una consola de comandos que puede usarse, al igual que el resto del entorno, también en entornos de clusters HPC y MPI, lo que permite trabajar interactivamente con infraestructura de procesamiento paralelo.
De hecho, sospecho que estos entornos son el motivo principal de la inversión de Microsoft en desarrollar estas herramientas, aún después de haber dejado el desarrollo de IronPython en manos de la comunidad. Python es uno de los lenguajes más utilizados (junto con C/C++) en el mercado de Computación de Alto Rendimiento (HPC), donde Microsoft está creciendo progresivamente a partir del lanzamiento hace unos años de Windows HPC Server. Sobre todo por bibliotecas clásicas en los mercados científicos, financieros e ingenieriles como NumPy o SciPy, y por el hecho de que programar resolución de problemas complejos en arquitecturas masivamente paralelas en C es bastante complejo, Python se ha establecido como una excelente opción.
Microsoft supo aprovechar el trabajo del equipo de IronPython para soportar su implementación en Visual Studio y la generalizo para muchas más áreas, lo que es en general una buena noticia, aún cuando lo cierto es que en la mayor parte de los contextos los programadores Python no solemos necesitar una IDE completa y preferimos la liviandad de un buen editor. En contextos complejos como HPC o uso de Interfaz de Paso de Mensajes (MPI) en ambientes distribuidos, es bueno al menos tener un buen soporte de depuración y algunas herramientas extra.
Debajo una pequeña muestra de las herramientas en acción:
El pasado 19 de julio el grupo Agiles.org de Buenos Aires realizó su ya tradicional reunión mensual, y en esta oportunidad el facilitador fue Fernando Parra (de MicroStrategy), quien contó un poco sobre los conceptos de emprendimiento alrededor del modelo Lean Startup, más basado en el foco en el diseño de producto y en el piloto inicial empujado por los mismos emprendedores más que el clásico modelo de buscar inversores para desarrollar una idea.
Este estilo de desarrollo de negocios está muy basado en una mezcla de métodos ágiles, software gratuito de código abierto, iteraciones cortas y extremo foco en el cliente final.
Y como personalmente no pude quedarme a la sesión, agrego las notas tomadas por mi amigo Ricardo Colusso:
La presentación se centró en emprendimientos de desarrollo de producto.
¿Porqué muchos emprendimientos fallan? Algunas razones: Optimismo infundado, foco 100% en el producto antes que pensar en quienes lo van a usar, resultado: el producto no encuentra mercado.
Proceso propuesto: Concepto de producto mínimo viable (MVP). Por ejemplo el primer teléfono de Apple que no permitía copiar y pegar.
Hablamos del Lean Canvas: http://leancanvas.com/ - Forma Lean de presentar información de startups. Puede bajarse gratis y usarlo/adaptarlo a lo que necesitemos (licencia Creative Commons)
La charla luego de la presentación fue por el lado de pensar cuan útil es un plan de negocios para un Llean Startup. Si quiero un subsidio de algún organismo oficial seguro que necesito hacer un plan de negocios, pero se habla de que probablemente me convenga no pedir plata y arreglarme inicialmente con lo que tenga. Se habla también sobre "burbujas" (como las punto com en 2001) que son vistas como oportunidades en el momento, pero que no tienen un sustento firme a nivel ganancias por cliente nuevo obtenido. Después estuvimos analizando en más detalle en que consiste el lean canvas, y encaramos un caso específico.
Nombres y fuentes de información mencionadas en la sesión:
Agradezco a Rick por las notas y les dejo la serie de videos (5 en total, cubriendo unos 80 minutos). Los últimos 10 minutos de la parte 5, aproximadamente, quedaron ocupados por el inicio de una actividad posterior que no tuve oportunidad de editar.
El equipo del proyecto Mono, ahora formal y legalmente a cargo del equipo original reagrupado en Xamarin tras su salida de Novell, retoma el ritmo de entregas progresivas con su versión 2.10.3 que a pesar de ser una entrega “de mantenimiento” sorprende con estadísticas como:
Mientras tanto, para espíritus exploradores, accediendo al código fuente más actual desde el repositorio de Mono en GitHub, se puede comenzar a probar el soporte para C# 5.0, al menos sobre las características definidas y publicadas hasta ahora por Microsoft.
Siguiendo con sus planes de dominar el mundo, JavaScript tiene desde hace un tiempo un interesante motor construido en .NET que permite ser embebido en cualquier aplicación: Jint
El proyecto es de código abierto y fue iniciado por Sébastien Ros y colaboradores antes de ingresar a Microsoft, donde trabaja en el equipo del proyecto Orchard.
A diferencia de otros proyectos que intentan emitir código IL a partir de JavaScript, lo que es problemático por el problema de no poder descargar los ensamblados generados, o de otros proyectos basados en el Dynamic Language Runtime, Jint es un intérprete completo basado en ANTLR.
Jint permite utilizar JS como lenguaje para extender aplicaciones dinámicamente, algo que en .NET muchos hicimos previamente utilizando IronPython o IronRuby. Pero JavaScript es bastante más amplio en su uso, y esta clase de recursos siempre es muy valioso, sobre todo en este caso en que el soporte es muy completo, cubriendo la especificación completa de ECMAScript 3.0, y soportando en el último release muchos elementos del estándar 5.0.
Dejo el ejemplo más básico de uso desde C# (obviamente puede ser embebido en cualquier lenguaje .NET):
script= @" function square(x) { return x * x; };
return square(number); ";
var result = new JintEngine() .SetParameter("number", 3) .Run(script));
La semana pasada el equipo de Google App Engine, la plataforma como servicio para ejecutar aplicaciones en la nube, anunció soporte para Go, uno de esos raros lenguajes nuevos, en este caso generado por el mismo Google, en lugar de surgir del ambiente académico o la comunidad de código abierto.
Esto hace que Go, diseñado para ser un lenguaje de sistema de un nivel apenas superior a C++, eliminando los típicos problemas de manejo de memoria y aportando características específicas para situaciones de alta concurrencia y paralelismo.
Go es un lenguaje “de llaves”, en la tradición familiar de C, pero sin necesidad de puntos y comas, al menos (las lleva pero el compilador se encarga de ponerlas solo). Veamos el clásico Hola, Mundo:
package main
import "fmt"
func main() { fmt.Println("Hello, 世界") }
Una de las características más interesantes de Go, y una de las que lo hace especialmente interesante para aplicaciones en la nube, es su implementación de co-rutinas, o funciones que pueden ejecutarse en paralelo, utilizando, casualmente, la sentencia “go”, pero además permite definir “canales” para mantener la comunicación entre procesos. Para los interesados que aún no lo hayan hecho, hay un buen tutorial de Go con muchos ejemplos.
Ayer Heroku, la plataforma para despliegue de aplicaciones en la nube (adquirida por SalesForce.com a fines del año pasado), anunció que Matz, el creador de Ruby, se sumó a su equipo como Arquitecto Jefe.
Esta es una gran noticia no solamente para la comunidad Ruby, sino para la industria en general, porque une más aún equipos innovadores y de una influencia muy positiva para toda la comunidad.
Por un lado, Matz es una persona inquieta y perseverante, que a mediados de los noventa decidió crear un lenguaje que hiciese feliz a los programadores, no a los compiladores, y a lo largo de los años mantuvo un gran liderazgo alrededor de una comunidad sumamente colaborativa que aportó grandes ideas al campo de los lenguajes y ecosistemas, y que incluso con la llegada de los "niños rebeldes" de Ruby on Rails, que trajeron una perspectiva muchas veces extrema y criticada, siguen llamando la atención sobre estilos de construcción de aplicaciones basados en agilidad, simplicidad y capacidad de expresión.
Por el otro, Heroku, desde sus humildes orígenes como una plataforma pequeña de aplicaciones en la nube en el 2007, siempre intentó hacer que el desarrollo y ejecución de las aplicaciones web fuese algo más sencillo y ordenado, y desde entonces su servicio creció para establecerse entre los mejores en satisfacción de los usuarios/desarrolladores y calidad de ejecución, además de mantener el espíritu de soporte a los emprendedores brindando la posibilidad de comenzar con niveles gratuitos que permiten construir cosas reales y empezar a invertir dinero cuando el negocio realmente empieza a despegar.
La combinación sólo puede deparar más fuerza en esa dirección sana de seguir impulsando a la "competencia", ya sean otras plataformas o lenguajes, en la dirección de la productividad y sencillez pero siempre basadas en una experiencia de desarrollo divertida y libre de stress.
Es interesante saber que Heroku planea seguir adelante con su soporte a otros lenguajes/entornos, como Node.js o Clojure (ambos soportados actualmente) mientras que el rol de Matz (y su pequeño equipo de colaboradores) será seguir desarrollando Ruby. Seguramente la cercanía aporte muchas cosas buenas a la plataforma en general, y probablemente le permita a Matz seguir jugando con otros lenguajes, algo que nunca dejó de hacer a pesar de su liderazgo en el desarrollo de Ruby.
Como regalo final les dejo un video de Matz recorriendo un poco la historia de Ruby antes de contar los planes para la próxima versión 2.0, que comenzó el desarrollo a fines del año pasado. En el video Matz habla en su tradicional simil-inglés, que espero que entiendan (tiempo total: ~35 minutos).
El matemático Alfréd Rényi decía que "un matemático es una máquina que convierte café en teoremas", frase que usualmente se le atribuye a su compatriota y colega Paul Erdös, quien solía repetirla.
Los programadores somos de alguna manera aparatos para convertir cafeína en algoritmos, lo que se hace explícito en la tradición de Java, JavaScript y el reciente CoffeeScript, todos inspirados en este alcaloide de venta libre.
Siguiendo la tradición cafetera, Maurice Machado ha colaborado con un reciente experimento notable basado en Node.js y CoffeeScript. Como breve recordatorio, CoffeeScript es una sintaxis simplificada de JavaScript, con un estilo más sucinto, bastante similar a Ruby, que se está haciendo tan popular que ya viene integrado en la distribución de Ruby on Rails 3.1, por ejemplo.
Lo que Maurice generó con CoffeeKup es un lenguaje específico de dominio (DSL) sobre CoffeeScript para generar el marcado completo de la página. Esto es, en lugar de escribir HTML, podemos escribir directamente toda la estructura de la página en CoffeeScript.
doctype 5
html ->
head ->
meta charset: 'utf-8'
title "#{@title or 'Untitled'} | My awesome website"
meta(name: 'description', content: @desc) if @desc?
link rel: 'stylesheet', href: '/stylesheets/app.css'
style '''
body {font-family: sans-serif}
header, nav, section, footer {display: block}
'''
script src: '/javascripts/jquery.js'
coffeescript ->
$().ready ->
alert 'Alerts are so annoying...'
body ->
header ->
h1 @title or 'Untitled'
nav ->
ul ->
(li -> a href: '/', -> 'Home') unless @path is '/'
li -> a href: '/chunky', -> 'Bacon!'
switch @user.role
when 'owner', 'admin'
li -> a href: '/admin', -> 'Secret Stuff'
when 'vip'
li -> a href: '/vip', -> 'Exclusive Stuff'
else
li -> a href: '/commoners', -> 'Just Stuff'
section ->
h2 "Let's count to #{@max}:"
p i for i in [1..@max]
footer ->
p shoutify('bye')
Como puede verse, se declara la estructura jerárquica de la página (cabecera y cuerpo), con sus atributos internos, y pueden anidarse los elementos como párrafos, divs, listas, y demás. Y claro, puede embeberse código en cualquier lado. No hay una diferencia directa entre la plantilla y el código.
Parece una postura muy radical, pero me parece un espacio sumamente interesante a investigar. Los experimentos de Maurice estén disponibles en GitHub y no terminan en CoffeeKup. Hay otros relacionados, como Zappa y CoffeeScript-Bespin.
Mi invitado esta vez es Mariano Koldobsky, un experimentado trabajador al que conozco desde hace años, a raíz de conocernos en una empresa en que él trabajaba y yo daba consultoría, y reencontrarnos más tarde en la comunidad ágil.
Tiempo después logramos trabajar juntos por un tiempo, hasta hace poco cuando Mariano empezó a trabajar para bvision, que tienen oficinas cerca de su casa en La Plata, capital de la provincia de Buenos Aires.
Con Mariano compartimos la pasión por la programación, la electrónica y recuerdos de nuestra generación, ya que somos los dos bastante veteranos. Pero casualmente esas dos primeras aficiones nos llevaron a elegir como tema de nuestra sesión un ejercicio de programación y cableado, utilizando una placa Arduino, que es una plataforma de hardware abierto, ideal para realizar prototipos e implementaciones sencillas y caseras de dispositivos de control.
Como verán en el video, la placa se conecta por USB (anteriormente por puerto serie) y se programa en un lenguaje de programación propio (una especie de Processing, pero basado en C++ en lugar de Java).
Algo interesante de Arduino es que es la plataforma que tomó de base Google para desarrollar su propio Android Open Accessory Development Kit, con lo que conocerla ahora puede significar algo más que un mero pasatiempo.
El video dura un poco menos de 15 minutos, y espero que les resulte tan divertido como a nosotros grabarlo. ¡Al menos por una vez van a ver algo más que código!
El próximo 21 de julio (de 18:30 - 20:00; GMT -3; horario de Buenos Aires) el amigo Juan Gabardini, viejo compañero de aventuras, estará presentando un Webinar (un seminario via web) patrocinado por la buena gente de Kleer.
El tema es el uso de casos de prueba basados en ejemplos utilizando FitNesse, la plataforma de pruebas de aceptación basada en wikis creada por el tío Bob Martin y amigos en base al FIT original de Ward Cunningham (ambas herramientas de código abierto y gratuito).
El evento es en línea y gratuita, pero los interesados deben registrarse porque hay una cantidad máxima de asistentes (aunque no se bien cuál).
La sesión se presentará utilizando GoToMeeting, un servicio de conferencias en línea de Citrix que soporta Windows y Mac OS y utiliza un cliente que se descarga al momento de la conexión, por lo que recomiendo conectarse unos 10 minutos antes para estar seguros de que todo funciona correctamente.
El temario, según la invitación, es el siguiente:
¿Cómo logramos que los requerimientos sean claros tanto para los usuarios como para los desarrolladores?
¿Cómo lograr validar continuamente y con bajo costo que el producto cumpla con los requerimientos?
Veremos las especificaciones por medio de ejemplos, una técnica utilizada para lograr estos objetivos, y Fitnesse, una herramienta libre que soporta la técnica.
Fitnesse permite escribir los ejemplos (requerimientos) como tablas o historias, y ejecutar automáticamente estos ejemplos contra la aplicación, informando si la aplicación cumple con los resultados esperados.
(gracias a José Romaniello por descubrirme este interesantísimo lenguaje)
Cobra es un lenguaje multi-plataforma y multi-paradigma que combina una cantidad de características sumamente interesantes.
Es obra de Charles Esterbrook, y su autor describe sus principios de diseño de la siguiente manera:
Programación rápida y expresiva
Rápida ejecución
Tipado estático y dinámico
Calidad soportada a nivel del lenguaje
Por supuesto que suena ambicioso y vendedor, pero en principio, es bastante realista. Veamos cómo se soporta cada cosa:
Programación rápida y expresiva
Cobra tiene una sintaxis basada en Python (sobre todo) y Ruby, lo que lo hace mucho más legible que los lenguajes "con llaves y punto y coma". Entre otras cosas, en Cobra los bloques se determinan por indentación, las listas y diccionarios se pueden declarar como literales, hay comandos como print y assert de uso sencillo y poderoso, la manera de iterar y dividir listas es simple, y mucho más.
Un ejemplo rápido de la sintaxis, con la definición de una clase:
class Person
"""
Declaración de una clase. Este comentario documenta la clase misma
"""
var _name as String # Declara variables de instancia (no estáticas)
var _age as int
cue init(name as String, age as int) # Inicializador (constructor)
base.init
_name = name
_age = age
def sayHello # Métodos
# Los corchetes interpolan valores en las strings
print 'Hello. My name is [_name] and I am [_age].'
def divide(i as int, j as int) as int
""" Este comentario documenta este método """
assert j > 0 # Si el divisor
return i / j
Rápida ejecución
Esto es logrado a través del uso de tipos estáticos con inferencia permanente, sin perder las capacidades dinámicas para los casos necesarios.
La implementación actual de Cobra utiliza la Infraestructura Comun de Lenguajes (CLI) de .NET/Mono, por lo que el compilador genera código intermedio (IL) que a su vez es es llevado a código nativo por el motor de ejecución de .NET/Mono como en otros lenguajes.
Tipado estático y dinámico
La mayor parte de la resolución es estática y en tiempo de compilación, mientras que siempre que haga falta puede utilizarse resolución dinámica en tiempo de ejecución, basada en Reflection de .NET y apoyándose en técnicas específicas de optimización.
Veamos un ejemplo sencillo de una misma función declarada estáticamente:
def add(a as decimal, b as decimal) as decimal
return a + b
... o dinámicamente:
def add(a, b) as dynamic
return a + b
En la práctica, no son la misma función, ya que la primera opera solamente con números decimales, y la segunda con cualquier tipo que soporte la operación suma.
Obviamente la primer función es más rápida, ya que se verifica y compila, y no requiere más recursos que los operandos de un largo conocido (decimal), mientras que la segunda, al resolverse dinámicamente, es verificada en tiempo de ejecución y requieres más recursos para la conversión de parámetros, etc.
Por otro lado, contar con ambas variantes es lo ideal, ya que podemos aprovechar el contrato estricto de los tipos estáticos para gran parte de la aplicación, pero con la flexibilidad de los dinámicos para las porciones que son más variables, o para facilitar el prototipado.
Nótese que el soporte a tipos dinámicos de Cobra, comparado con el de C# o VB (a partir de .NET 4), es sintácticamente más sencillo, mucho más integrado a nivel del lenguaje.
Calidad soportada a nivel del lenguaje
Cobra soporta contratos de código (algo proveniente de Eiffel que .NET 4 soporta parcialmente), pruebas unitarias, comentarios para documentación y verificación de valores nulos en tiempo de compilación, todo como parte de su sintaxis.
Veamos como las pruebas unitarias quedan embebidas directamente como parte de un método:
class Utils
shared
def countChars(s as String, c as char) as int
"""
Returns the number of instances of c in s.
"""
test
assert Utils.countChars('', c'x') == 0
assert Utils.countChars('x', c'x') == 1
assert Utils.countChars('X', c'x') == 0 # case sensitive
assert Utils.countChars(' ! ! ', c'!') == 2
body
count = 0
for ch in s
if c == ch
count += 1
return count
Las aserciones, además, pueden usarse en cualquier parte del código, y arrojan una excepción con información útil para depuración si no se cumplen (no son un IF).
Los contratos embebidos en el código permiten especificar pre y post-condiciones a los métodos, garantizando la consistencia antes de entrar y después de retornar el valor final. Por ejemplo:
class Customer
var _contacts as List<of Contact>
get contacts from var
def addContact(contact as Contact)
require # Arroja excepción si algo no se cumple ANTES de entrar
contact not in .contacts
contact.name
contact.customer is nil
ensure # Arroja excepción si algo no se cumple DESPUES de salir
contact.customer == this
.contacts.count = old .contacts.count + 1
body
contact.customer = this
_contacts.add(contact)
Y otra característica muy buena de seguridad es que los parámetros o tipos que pueden recibir nil (llamado como en Smalltalk o LISP), son los que se declaran como tales, agregando al sufijo "?" al tipo, como en:
def bar(s as String?)
if s # Es igual que preguntar "if s is not nil"
print Utils.countChars(s, c'x')
Cobra está escrito en Cobra
Una característica más que quiero remarcar es que este lenguaje está escrito sobre si mismo. Por supuesto hay una parte del compilador escrita para la plataforma nativa (C# en este caso), pero el resto está escrito en Cobra mismo, lo que hace que el lenguaje tenga un nivel de depuración y prueba mayor que otros que se construyen generalmente sobre lenguajes de más bajo nivel. Esto está sucediendo en otros lenguajes a posteriori, como en el caso de PyPy o Rubinius, pero en Cobra fue un principio de diseño.
Personalmente me parece uno de los lenguajes "experimentales" más interesantes y completos que he visto en los últimos tiempos, en parte porque se apoya en una plataforma que ya ofrece muchos servicios, y en parte por algunas de sus características maduras que y las herramientas con que ya cuenta (compilador, ejecutor de pruebas unitarias, generador de documentación, coloreador de sintaxis, etc).
Y también cuenta con soporte parcial en algunas IDEs y editores:
Visual Cobra es un complemento para Visual Studio que reconoce y colorea la sintaxis.
Naja es una IDE completa escrita en Cobra que ademas del coloreo de sintaxis tiene soporte para lista de tareas basada en comentarios, soporte para proyectos y un diseñador de formularios que genera código Cobra.
Y si uno prefiere un editor de texto hay muchos para los cuales hay complementos para soportar la sintaxis, incluyendo gedit, Notepad++, UltraEdit, Vim y TextMate (el que estoy usando yo), y mucho más para elegir según la plataforma que cada uno usa. Y para cualquier otro caso existe un detalle de las palabras clave y modificadores, de manera que en cualquier editor se puede partir del soporte para Python y cambiar estas listas.
Finalmente, dejo este video de la presentación de Esterbrook en el Lang .NET Symposium 2008. Aunque la implementación del lenguaje maduró bastante desde entonces, muchos de los principios siguen igual.
En esa sesión mi par es Diogenes Moreira, amante de la Orientación a Objetos que a pasado por múltiples tecnologías desde Cobol y PowerBuilder hasta Java y C#, siempre con su corazón cerca de Smalltalk.
Diogenes trabaja actualmente para Ilon SA y aunque tiene múltiples responsabilidades no deja de programar junto a su equipo. Participó en varios proyectos de código abierto, incluyendo colaboraciones para Pharo.
Nos conocemos por amigos comunes y por el grupo Agiles de Buenos Aires, y casualmente durante una de las reuniones mensuales de éste nos escapamos un rato a grabar este video en que hacemos algunos ejemplos con Seaside, un framework web para Smalltalk.
Como acompañamiento del video, dejo esta presentación de Esteban Lorenzano, en la que se recorren varias de las características que Diogenes comenta mientras escribimos los ejemplos:
Sin más preámbulos, el video, que dura aproximadamente 35 minutos. Estoy usando un servicio que brinda mucho mejor calidad de video (sobre todo para el código), pero tengan paciencia porque el reproductor puede tardar varios segundos (a veces casi un minuto) en empezar.
Uno de los objetivos de HTML5 es unificar el manejo de media para todos los navegadores y plataformas, pero hasta ahora, por cuestiones de indefinición de estándares, por temas de apertura, licenciamiento o comodidad tecnológica entre los jugadores del mercado, esto no ha sido sencillo.
Para solucionar este problema, el prolífico John Dyer escribió (y liberó bajo licencia GPL v2/MIT) MediaElement.js
Se trata de un reproductor de audio/video en JavaScript, como su nombre indica, que soporta una multitud de navegadores (los que soportan HTML5 y los que no) y unifica mucho más el soporte de codecs para diferentes formatos de video.
Para simplificar el uso manteniendo el soporte entre plataformas, el reproductor utiliza el mismo API en todas, basado en los tags <audio> y <video> de HTML5, implementándolos en los navegadores que no los reconocen, delegando el soporte a reproductores en Flash o Silverlight, pero que emulan exactamente el reproductor nativo.
De esta manera, el uso de estos elementos es idéntico en todos los navegadores para el productor del contenido, y la adecuación se produce en el cliente, que probablemente ya tenga los complementos necesarios descargados. La ventaja principal es que la manera de interactuar con los activos de audio o video es siempre igual.
El siguiente cuadro muestra el soporte para todos los navegadores, y la manera en que se soportan dependiendo de la plataforma:
Como siempre, el soporte se limita más en los dispositivos móviles, sobre todo en iOS, pero nótese que los navegadores de escritorio están cubiertos por completo.
La instalación de MediaElement es muy sencilla y está bien descripta en el sitio. Del lado del cliente, básicamente se reduce a incluir esta biblioteca y hoja de estilos:
Y para incluir el reproductor, utilizando el caso más extremo para dar soporte completo a todo, este es el marcado HTML (obviamente sin necesidad de incluir todos los comentarios):
<video width="320" height="240" poster="poster.jpg" controls="controls" preload="none">
<!-- MP4 en Safari, IE9, iPhone, iPad, Android, y Windows Phone 7 -->
<source type="video/mp4" src="myvideo.mp4" />
<!-- WebM/VP8 en Firefox4, Opera, y Chrome -->
<source type="video/webm" src="myvideo.webm" />
<!-- Ogg/Vorbis en versiones viejas de Firefox y Opera -->
<source type="video/ogg" src="myvideo.ogv" />
<!-- Opcional: Agregar subtitulos para diferentes lenguajes -->
<track kind="subtitles" src="subtitles.srt" srclang="en" />
<!-- Opcional: Agregar capítulos -->
<track kind="chapters" src="chapters.srt" srclang="en" />
<!-- Ante-último recurso: sólo para navegadores sin HTML5 ni JavaScript -->
<object width="320" height="240" type="application/x-shockwave-flash" data="flashmediaelement.swf">
<param name="movie" value="flashmediaelement.swf" />
<param name="flashvars" value="controls=true&poster=myvideo.jpg&file=myvideo.mp4" />
<!-- El peor de los casos: dejo una imagen -->
<img src="myvideo.jpg" width="320" height="240" title="No tiene manera de reproducir video" />
</object>
</video>
El reproductor en si soporta diferentes estilos, puede controlarse programáticamente desde JavaScript, tiene montones de opciones como tamaño para el marco de video o audio, volumen, reproducción en bucle, subtítulos (incluyendo traducción automática via Google translate), y más.
Creo que para cualquiera trabajando seriamente en media en este momento este reproductor es una de las soluciones más completas disponibles.
Cada tanto la comunidad Alt.NET se pone de acuerdo para realizar un Open Space en Buenos Aires, como en muchas otras partes del mundo. Ya he cubierto ediciones anteriores en este blog, y ahora me toca informar sobre la organización de una nueva reunión.
Como suele ocurrir, hay mucha gente que está interesada pero aún no se ha acordado la fecha definitiva, aunque hay consenso en hacerla durante el mes de julio. Para votar por la fecha que prefieran los interesados, estamos utilizando este mecanismo:
¡No sean tímidos! Todo el que esté realmente interesado en participar puede elegir qué sábado le queda mejor. Tengan en cuenta que usualmente s desde las 9 de la mañana hasta las 6 de la tarde, con la interrupción del almuerzo que se hace in-situ. Es probable que el lugar sea Microsoft de Argentina, en Bouchard 710, 4to piso, Ciudad de Buenos Aires.
Y como siempre, aprovecho para recordar que además de estas reuniones presenciales que se organizan esporádicamente en distintas ciudades, el grupo Alt.NET Hispano organiza reuniones virtuales en forma semanal (a veces más de una por semana), que se anuncian en la lista de distribución y en el calendario de reuniones del sitio.
Estas reuniones quedan grabadas y pueden verse a demanda una semana o dos después de su ejecución, y el grupo ya lleva (a hoy) 73 reuniones que pueden verse en línea o descargarse desde el histórico de reuniones.
Un traductor de bytecode YARV (basado en Ruby 1.9)
Una máquina virtual basada en V8 (el motor de código abierto de Google) conectando las partes
Sin embargo, estas tres partes pueden ser utilizadas en forma independiente o reemplazadas por otras. Así, ColdRuby puede compilar código Ruby a JavaScript para que lo ejecute un browser, o ser ejecutado directamente en Node.js (que utiliza V8 por debajo).
Para los que todavía suponen que hacer algo así en JavaScript es una locura porque puede ser muy lento, los invito a mirar este emulador de completo de una PC escrito en JavaScript por Fabrice Bellard (autor de QEMU entre otras cosas), que bootea un Linux (funciona bien en versiones actualizadas de FireFox y Chrome, al menos).
ColdRuby tiene unos cuantos detalles "raros" que surgen de las diferencias de diseño entre ambos lenguajes, como el modelo de herencia prototípica de JavaScript contra el usual, basado en clases, de Ruby. También hay detalles como la manera en que se mapean algunos tipos de datos, pero en todos esos sentidos se ha tratado de mantener la alternativa más pragmática para usos generales.
La promesa es poder ejecutar Ruby dentro del browser (algo que hasta ahora era posible solamente con la combinación de IronRuby y Silverlight), e interactuar entre ambos lenguajes.
El proyecto es temprano y todavia un tanto experimental, pero interesante.
En un mensaje de ayer en la lista de TDD en español, el amigo Carlos Blé, autor de el único libro (que yo conozca) de TDD en español (y gratuito), anunció la publicación de su framework para Dobles de Prueba en Python, construido porque no encontraban en su equipo uno como lo que ellos buscaban, y también como ejercicio.
El framework se llama pyDoubles, y el proyecto está hosteado en BitBucket para quienes quieran colaborar o derivarlo (está publicado bajo licencia Apache 2.0).
Según explican en la documentación, pyDoubles sigue la nomenclatura propuesta por Gerard Meszaros (en su ya clásico libro xUnit Test Patterns) para clasificar los dobles de prueba en stubs, spies o mocks.
Resumiendo brevemente, en el entorno de las pruebas unitarias, los dobles nos permiten reemplazar dependencias externas (que no son las que queremos probar) por otros objetos que -sólo a efectos de la prueba- se comportan como los verdaderos, facilitando la prueba de el SUT (o sistema a probar, por sus siglas en inglés).
Uno de los ejemplos clásicos es usar un doble para la capa de datos de un componente, ya que al probar nuestra lógica no necesitamos un repositorio de datos real, porque es dificultoso de mantener pero además es mucho más lento que utilizar un objeto con la misma interfaz o protocolo, que simplemente me devuelve lo que espero en el contexto del test.
La diferencia entre stubs, spies y mocks es sutil y discutida usualmente en la comunidad (desde el famoso artículo de Martin Fowler "Mocks aren't Stubs"). Lo importante en este caso es que el framework soporta los tres tipos.
Como el sitio de pyDoubles está ahora en inglés, traduzco brevemente la introducción explicando las categorías:
STUB
Reemplaza la implementación de uno o más métodos en la instancia del objeto que juega como colaborador o dependencia, devolviendo el valor que explícitamente devolvemos en la prueba. El stub es un método, pero es común llamar stub también a una clase que los contiene. El stub no tiene ningún tipo de memoria.
SPY
Hace lo mismo que el stub, pero puede registrar los métodos que se llamaron durante la ejecución de la prueba y cómo fueron invocados. Se utilizan para verificar la interacción o comportamiento.
MOCK
Además de lo que hacen los stubs y spies, es más estricto en la especificación del comportamiento esperado del sistema a probar. Antes de llamar a cualquier método en un mock, la prueba debe declarar, usando el framework, qué métodos y cómo deben ser llamados para que este comportamiento se verifique por completo. De lo contrario, la prueba falla con una excepción "UnexpectedBehavior" (comportamiento inesperado).
Como ellos explican en la documentación no hay tipos de dobles "mejores" que otros. Los mocks son más estrictos y por lo tanto hacen que las pruebas que los usan sean también más frágiles (más susceptibles a fallar por cambios menores en la implementación). Los spies son más flexibles en ese sentido, pero no alcanzan cuando necesitamos especificar un comportamiento especial en gran detalle. El resultado es que usualmente se utilizan combinaciones de los tres.
En la práctica, como siempre, conviene siempre aplicar la solución más sencilla que funcione, usualmente empezando con stubs, y luego recurrir a spies o mocks tipos cuando la prueba lo requiere.
Para ver ejemplos del uso del framework, les recomiendo ir directamente a la documentación.
El número está en Beta por ahora, y creo que lo que más le falta es revisar bien la ortografía, pero igual el contenido es excelente, y siempre mantiene ese ambiente descontracturado pero bien técnico que es la marca de agua de esta comunidad.
La revista se publica bajo licencia Creative Commons (específicamente CC-by-nc-sa-2.5), por lo que se puede distribuir y derivar en forma libre, manteniendo la atribución a la fuente original, sin usarla comercialmente, y manteniendo la licencia en las derivaciones.
El contenido incluye:
¿Qué es PyConAr?
Cómo se hizo PyConAr2010
Charlas relámpago en PyConAr 2010
Fotos de las Keynotes
El Asado de PyConAr2010
Entendiendo Decoradores en Python
Introducción a Django
PyAfipWs: facilitando, extendiendo y liberando los Servicios Web de AFIP (Factura Electrónica y otros)
InfoPython - Midiendo el Valor de la Información de Mass Media con Python.
Como generar archivos .exe e instaladores para una aplicación python
Depuración y defragmentación de memoria
NINJA-IDE, Un IDE Pensado para Python
Usando librerías adicionales y virtualenv
Desafío PET
xkcd
Advierto que son muchas páginas de contenido variado, y recuerden que está en beta, con lo que es bueno estar atento a la aparición de la versión final.
¡Felicitaciones al equipo editorial por otro número terminado!
A fines del año pasado comentaba en este blog la venta de Novell a Attachmate, una compañia de servicios de infraestructura.
Una preocupación desde ese momento, aunque al principio no parecía pasar nada, es qué valor iba a darle el nuevo dueño al proyecto Mono (una implementación de código abierto de .NET), liderado por Miguel de Icaza.
Las cosas empeoraron recientemente, y el 2 de mayo comenzaron los despidos de los equipo de EEUU y Candá, seguidos en la semana por el resto en Europa, Brasil y Japón.
Lejos de romper en llanto, el equipo original de Mono, con Miguel a la cabeza, pronto avanzó con un viejo plan que ya había discutido anteriormente y fundaron Xamarin, una companía con la que piensan mantener el servicio de soporte de Mono y el resto de los proyectos abiertos, y generar dos nuevos proyectos similares a Mono for Android y MonoTouch (para iOS). Al igual que los productos que generaron en Novell, éstos últimos serán productos pagos, con los que esperan mantener al equipo funcionando.
Conociendo la calidad y capacidad de producción del equipo, estoy seguro que pronto tendremos novedades al respeto. Miguel estima que en 3 meses pueden tener la versión preliminar para iOS, y en 4 la de Android, y seguramente en ambos casos, al empezar de cero, incorporarán mejoras y aprendizajes por sobre los productos que quedaron en Novell.
Vale recordar que Mono en si y sus otros derivados como Moonlight, MonoMac y MonoDevelop son gratuitos y de código abierto, por lo que no hay riesgos al respecto.
Mientras tanto, la conferencia Monospace sigue programada para el 23 al 25 de julio en Boston, Massachussets, EEUU, en el NERD (New England Research & Development) Center de Microsoft en esa ciudad.
Desde este humilde blog aprovecho para expresar mi admiración y apoyo a Miguel y su increíble equipo en esta nueva etapa, y quedo a la espera de las novedades que seguramente producirán a mansalva, como siempre.
Pero vamos al libro. En el prologo, Jeremy Ashkenas, el creador de CoffeeScript, explica entre otras cosas (la traducción es mía):
..."Afortunadamente para nosotros, el JavaScrit de hoy disfruta de un merecido renacimiento. Gracias al incansable esfuerzo de los implementadores de los navegadores, es actualmente el más rápido de los lenguajes dinámicos populares; está presente en todos lados, desde servidores hasta Photoshop; y es el único lenguaje que se puede usar para programar desde todos los ángulos de la web.
CoffeeScript es un pequeño lenguaje que apunta a brindar fácil acceso a las partes buenas de JavaScript: las funciones de primer clase, los objetos como hash, incluso la poco comprendida cadena de herencia por prototipos. Si hacemos bien nuestro trabajo, ustedes terminarán escribiendo un tercio del código para escribir el mismo JavaScript que hubiesen escrito de otra forma. CoffeeScript pone un alto valor a la legibilidad del código y a eliminar mucho del ruido sintáctico.Al mismo tiempo, hay una correspondencia prácticamente uno-a-uno entre CoffeeScript y JavaScript, lo que significa que no hay degradación de rendimiento -de hecho, muchas biblitoecas JavaScript terminan corriendo más rápido después de ser migradas a CoffeeScript debido a algunas optimizaciones que el compilador puede realizar."
El prólogo termina elogiando al autor del libro por sus colaboración con CoffeeScript desde los primeros días, lo que asegura que el tema está tratado desde un profundo conocedor.
El libro recorre el lenguaje y compilador en detalle, incluyendo instalación y ejecución, integración en otros ambientes e interoperabilidad con bibliotecas populares como jQuery. Y a medida que recorre los diversos capítulos, utiliza como ejemplo la construcción de un juego sencillo para dos jugadores, llamado 5x5, del que puede verse la interfaz a la derecha.
Comparto el índice general para que se den una idea del alcance:
Prólogo y Agradecimientos
Prefacio (historia, audiencia y organización del libro, proyecto de ejemplo y comunidad)
Comenzando (instalación, editores, ejecución y depuración)
Funciones, alcance y contexto
Colecciones e Iteraciones
Módulos y clases
Interactividad web con jQuery
Aplicaciones del lado del servidor con Node.js
Respuestas a los ejercicios
Maneras de ejecutar CoffeeScript (consolas web, dentro de una aplicación web, en Rails, via middleware, en Node.js, usando Middleman, en scripts del sistema operativo)
Cartillas
Bibliografía
Para terminar, dejo un video de Ashkenas presentando (en inglés) CoffeScript en la JSConf de hace un año. Es interesante ver la presentación de parte del propio padre de la criatura, pero tengan en cuenta que los doce meses transcurridos han cambiado la situación (para mejor) y ampliado las características del compilador.
Desde hace una semanas hay mucho ruido por la decisión repentina de la gente de RedGate de empezar a cobrar .NET Reflector, que siempre había tenido una versión gratuita.
Para poner un poco de contexto, cuento un poco de la historia y utilidad de Reflector:
Un componente fundamental del framework .NET es el CLR, un runtime de ejecución para múltiples lenguajes. Cualquier lenguaje que se quiera implementar en .NET necesita que su compilador (o intérprete) termine generando IL (lenguaje intermedio), una especie de lenguaje ensamblador virtualizado, que aprovecha montones de servicios comunes de la plataforma y garantiza la compatibilidad e interoperabilidad de tipos y servicios entre cualquier componente, sin importar en qué lenguaje fue escrito originalmente.
Desde los primeros días se hizo evidente (y es una característica de diseño) que tomando un assembly (un componente binario) de .NET, era fácil analizar el código fuente en IL, e incluso entre las herramientas básicas del framework se incluye el desensamblador ILDasm. Proteger los componentes contra descompilación es un tema recurrente con alternativas como la obfuscación, y que muchos consideramos irrelevante, pero eso es tema para otro momento.
Lo cierto es que para la mayoría de los mortales analizar IL no es trivial, por lo que a mediados de los 2000 Lutz Roeder creó Reflector, una herramienta que permitía descompilar un assembly a C# (hoy día también a VB y F#). Lutz mantuvo siempre esta herramienta disponible para toda la comunidad (no como código abierto, pero si gratuita) y la evolucionó constantemente a lo largo de los años, convirtiéndola en una de las principales recomendaciones para cualquier desarrollador .NET.
Reflector no sólo descompila componentes, sino que además facilita muchísimo la navegación dentro del código, tiene una excelente estructura para extensiones que ha favorecido la aparición de extensiones extraordinarias; unas tres docenas en el sitio de Codeplex que las agrupa. Pero también tiene muchísima funcionalidad para analizar tipos y dependencias, navegar objetos, mejorar posibilidades de depuración y mucho más.
En el año 2002 Lutz fue contratado por Microsoft y desde entonces trabaja en el grupo de Microsoft Expression. Con el tiempo notó que era dificil mantener el nivel de compromiso con su herramienta e hizo un acuerdo con RedGate, una compañía que se comprometía a continuar desarrollando y manteniendo una versión gratuita, con opción a producir ediciones pagas con funcionalidad adicional.
Todo iba bien con este acuerdo, hasta que RedGate anunció hace unos meses que a partir de la versión 7.x la herramienta tendría sólo ediciones pagas. El equivalente de la versión gratuita pasó a costar 35 dólares, lo que no es mucho para alguien que la usa frecuentemente, pero en otros casos puede resultar más complicado, y la comunidad no tomó la noticia con mucha alegría.
Peor aún, poco más tarde RedGate anunció que las versiones actuales pasarías a ser pagas también, y la situación con la comunidad empeoró cuando utilizaron el mecanismo de auto-actualización de Reflector para forzar a los usuarios a actualizar a una versión con fecha de expiración.
El revuelo no se hizo esperar y finalmente, ayer RedGate (más vale tarde que nunca), anunció públicamente que reconsideró el tema. Los usuarios de Reflector 6.x podrán actualizar a una versión que continuará siendo gratuita (si lo hacen hoy, actualizarán a una con fecha de expiración que puede ignorarse, porque la versión perpetua se recibirá en la próxima actualización).
Una aclaración importante: RedGate no brinda manera de descargar la versión 6.x, con lo que este mecanismo sólo funciona para quienes ya lo tienen instalado. La versión gratuita no es parte de la oferta de RedGate.
Para quienes el nivel de uso no justifica invertir 35 dólares, sin embargo, existen alternativas interesantes, algunas desde hace mucho tiempo, otras surgidas o potenciadas por el conflicto alrededor de Reflector:
MonoDevelop, Cecil.Decompiler y MonoReflector
Esta herramienta que está disponible en MonoDevelop (la IDE para Mono) también puede usarse sobre assemblies de .NET (Mono al fin y al cabo genera el mismo IL). Como casi siempre, esto no es algo interno de la IDE, sino que utiliza parte de la bilbioteca Cecil de Mono (que tiene muchísima funcionalidad para analizar y generar IL) incluyendo directamente el servicio de descompilación como puede leerse en este post del autor (Jean-Baptiste Evain, del equipo Mono en Novell).
Basado en Cecil.Decompiler, Jonathan Dickinson publicó MonoReflector, una interfaz WinForm para la biblioteca. Como la incorpora directamente, no es necesario instalar Mono: corre directamente sobre .NET.
Telerik acaba de liberar la beta de su herramienta gratuita JustDecompile (no de código abierto hasta donde veo).
Finalmente, JetBrains, creadores de ReSharper, DotTrace y muchas otras herramientas poderosas (para .NET y otras plataformas), anunció que está trabajando en un descompilador que se espera sea gratuito también, pero por ahora sólo se sabe que se llamará DotPeek (nombre elegido en un concurso por la comunidad)
El pasado 19 de julio el grupo 
) para clasificar los dobles de prueba en stubs, spies o mocks.
Ya hablé antes en este blog sobre 
