jueves, 30 de diciembre de 2010

Raros Lenguajes Nuevos: Ela

RSDN

Sobre el final del año inicio una serie que espero continuar desarrollando durante el incipiente 2011: Raros Lenguajes Nuevos.

La idea es dedicar cada tanto un post a algún nuevo lenguaje que aparezca en el radar, no necesariamente de los esotéricos, si no generalmente aquellos con posibilidades interesantes de ganar adopción o servir de campo experimental en ciertas áreas, aportando ideas que se incorporen en otros lenguajes más populares, como ocurre todo el tiempo en este campo.

 

Ela

En palabras de su creador, Vasily Voronkov: "Ela is a strict dynamically typed impure functional language" (un lenguaje funcional impuro, estricto y dinámicamente tipado). Y está implementado para correr sobre el CLR de .NET ó Mono. Analicemos estas características:

Dinámico se refiere a que los tipos se definen y verifican en tiempo de ejecución, no de compilación, y estricto se refiere a que las asignaciones (por omisión) no se difieren, sino que ocurren en el momento. Los tipos son además fuertes, es decir que no hay conversiones implícitas (no se pueden sumar números y strings, por ejemplo).

Exactamente al revés que en Haskell, que es funcional pero no-escricto (o lazy) por omisión, en Ela esta característica es opcional y debe ser explícita. Por ejemplo:

let x =(&2+2)
let y
= x *2//La expresión '2 + 2' se evalúa recién en este momento

El motivo de esto es que Ela está diseñado para ser funcionalmente impuro, también al contrario de Haskell. Esto significa que un programa puede tener efectos colaterales, o más simplemente, mantener estado (usar variables). Los lenguajes funcionales puros solamente admiten constantes y funciones, y no hay estado variable, lo que permite muchas cosas interesantes, pero implica un enorme cambio de mentalidad para cualquier programador que no proviene del mundo de las matemáticas.

Finalmente, la sintaxis general de Ela es relativamente parecida a ML (o el reciente F#), utilizando secuencias, líneas de ejecución y comparación de patrones. Un ejemplo para asustarse (aunque en realidad no es difícil de entender después de algunas reglas básicas, sería:

let filter f x::xs | f x  = x :: filter f xs;
                   
|else= filter f xs;
           _
[]           =[]

Esto define una función filter que recibe un predicado, es decir una función que evalúa cada elemento en una lista para filtrarla. El uso de esta función para filtrar los elementos mayores que 5 es tan sencillo como:

let filter' = filter (>5)

Como siempre en programación funcional, se trata principalmente de describir el resultado a obtener más que detallar los pasos a seguir para obtenerlo, y Ela sigue bien esta tradición.

¿Qué diferencia a Ela de otros lenguajes?

Además de características funcionales típicas como funciones anónimas (lambdas) y closures, y aplicación parcial.

Sin embargo, Ela toma un decisión interesante respecto de cualquier otro lenguaje (que yo haya visto), y es que toda función debe recibir un único parámetro. No cero ni más de uno. Esto que parece bastante restrictivo se resuelve en forma general haciendo que una función reciba otra, generando encadenamiento, como en:

let res = sum 23// por supuesto, devuelve 5

pero no recibe dos parámetros, sino que sum recibe como entrada 2 y devuelve una función anónima que recibe como parámetro el 3. Veamos la definición de sum:

let sum x y = x + y

Esta es una técnica conocida como currying(que toma su nombre del matemático Haskell Curry, al igual que el lenguaje Haskell que toma la otra mitad). En programación funcional esta es una técnica muy usual para componer funciones, pero no es obligatoria.

A primera vista parece raro, si, pero el hecho de pensar que toda función recibe un único parámetro cambia por completo la sintaxis del lenguaje, ya que no hacen falta más paréntesis ni separadores, y esto tiene un montón de consecuencias interesantes de analizar (y obviamente plantea varios desafíos).

Otra interesante decisión de diseño es que todos los operadores son identificadores únicos, con lo que no hay posibilidad de utilizar un símbolo con diferente semántica en dos contextos. Por ejemplo, el operador "-" (signo menos) significa resta, por lo que el operador unario para indicar un número negativo es "--" (por ejemplo: --2). Raro otra vez, pero hay algunas razones válidas relativas a la capacidad de validación de expresiones en cualquier contexto.

Es importante destacar que aunque el intérprete es totalmente funcional y puede ser embebido en código .NET o Mono, el proyecto está aún en nivel experimental.

Para los interesados, la documentación más completa por ahora es la Wiki en Google Code (en inglés), o este artículo del autor (en ruso).

 

miércoles, 29 de diciembre de 2010

Node.js: simplicidad y eficiencia

node.JS

Desde hace tiempo tenía pendiente escribir sobre Node.js (Node para los amigos). Hago una breve introducción primero para que se entienda por qué me parece importante:

Hace ya un par de años escribí un post hablando del resurgimiento de Javascript como lenguaje en todos lados, y la tendencia que veía entonces está empezando a ser notoria este año y creo que se va a afianzar el próximo.

El primero paso hacia un mayor uso de Javascript del lado del servidor fue la aparición de CommonJS como iniciativa para unificar detalles de las diferentes implementaciones, y es algo que está ganando bastante aceptación, especialmente en el soporte para los modules.

Node inició fuera de este estándar, pero luego se adaptó a CommonJS, y es un motor de Javascript del lado del servidor fuertemente basado en eventos y orientado principalmente a un manejo eficiente de comunicaciones en red. Se basa a su vez en el motor de Javascript V8, creado por Google y utilizado en Chrome, pero publicado como código abierto. Node también es código abierto con ncia MIT.

Lo notable de Node es que aprovecha la característica de Javascript como lenguaje y cultura, que a diferencia del resto del universo de la programación, siempre vio como algo natural el hacer llamadas no-bloqueantes.

Veamos la diferencia. Mientras en otros lenguajes cosas triviales como una consulta tienden a escribirse naturalmente como:

resultado = query( 'select * from Tabla');

en Javascript lo usual sería expresar esto como:

query( 'select * from Tabla', function (resultado) {
   // y aquí vemos qué hacemos con el resultado...
});

¿Cuál es la diferencia principal? Que la primer manera de llamada es bloqueante; es decir que mientras el resultado de la consulta no llega, el programa está detenido. En el segundo ejemplo, la llamada es no bloqueante, por lo que el resultado no se asigna a una variable sino que se pasa como parámetro a un callback (una función que será llamada al terminar la ejecución de la consulta, en este caso). En el ejemplo el callback se define en el mismo lugar para abreviar, pero podría ser una función definida en otra parte.

Lo importante de esta diferencia es que el estilo bloqueante de llamadas consume muchísimos recursos mientras se produce esa espera, que al involucrar acceso a disco o recursos de red puede ser por un tiempo importante, sobre todo al considerar una ambiente de alta concurrencia.

El modelo no-bloqueante o asincrónico, permite además manejar el procesamiento de esos callbacks dentro de un bucle de atención de eventos en lugar de necesitar threads separados para cada instancia. Y los threads son costosos y cuello de botella a la hora de escalar con mucha concurrencia.

Node aprovecha esta diferencia cultural de Javascript y brinda un entorno donde podemos realizar la mayor parte de las conexiones de red en forma no-bloqueante.

Veamos un ejemplo rápido que puede ilustrar la sencillez y eficiencia de Node en acción:

http = require('http');
Buffer = require('buffer').Buffer;
mega = 1024 * 1024;
bloque = new Buffer(mega);
for (var i=0; i<mega; i++) bloque[i] = 65; // Letra "A"
// SERVIDOR
http.createServer( function (pedido, respuesta) {
respuesta.writeHead(200);
respuesta.end(bloque);
}).listen(8000);

Las últimas cuatro líneas son la versión más básica de un web server en Node. ¿Sencillo, verdad?

Las primeras dos líneas utilizan el mecanismo de CommonJS de inclusión de módulos. El módulo HTTP permite acceso completo al protocolo como cliente o servidor y soporta cosas interesantísimas como la capacidad de devolver contenido como streaming. El módulo Buffer se utiliza para preparar bloques de datos binarios o crudos, no Unicode.

Las siguientes tres líneas solamente crean ese bloque de 1 Megabyte exacto de largo.

Lo más interesante son esas últimas cuatro (una sola sentencia, como se puede apreciar). Allí creamos una instancia del servidor web que atenderá en el puerto 8000 y al recibir cualquier pedido (HTTP request) responderá el bloque lleno con 1 Mb de letras A con status Ok (200) en la cabecera.

Pero lo más interesante es la manera en que se comporta el servidor si lo sometemos a una prueba de alta concurrencia. En pruebas con 100 requests concurrentes, Node llega a responder más de 800 requests por segundo (respondiendo 1 Mb para cada uno), lo que es un rendimiento asombroso. Estas características brillan en servicios de chat, presencia, colaboración o cualquier otro escenario donde típicamente deban soportarse muchas conexiones concurrentes.

Node tiene muchas otras ventajas, pero espero que hasta acá alcance para interesarlos. Lo ideal para conocer más sobre Node, además del sitio oficial, es la comunidad de artículos sobre usos y extensiones How to Node.

martes, 28 de diciembre de 2010

Kod: un editor de código (abierto) para OS X

Kod

Kod es un editor orientado a escribir código para OS X. Es de código abierto, bajo licencia MIT (modificada para no permitir vender el editor como tal) y alojado en GitHub.

Tiene algunas características muy interesantes, que me llamaron la atención y por lo que estoy empezando a usarlo con bastante buen resultado (listo lo que detallan en el sitio oficial, con mis comentarios):

  • Tiene un comportamiento muy asincrónico, y aprovecha el poder de los procesadores de múltiples núcleos que tenemos hoy día. Esto es algo que hace tiempo espero de más aplicaciones.¿Porqué tengo que esperar a que las cosas se terminen de grabar para poder seguir trabajando? Kod es muy eficiente al estar trabajando con múltiples archivos de diferentes tamaños.
  • El entorno de scripting está basado en el ascendente Node.js, sobre lo que tengo que escribir un próximo post en más detalle.
  • Interfaz de usuario inspirada en Chromium, utilizando tabs que pueden soltarse en ventanas independientes y volverse a unir, pero sobre todo, permitiendo escribir el nombre del archivo a editar directamente en la barra de direcciones, algo que es muy práctico al editar código, en lugar de tener que abrir un cuadro de diálogo.
  • Tiene algunas cosas que no usé, como que permite editar directamente archivos a través de HTTP (aunque no grabarlo, claro), y para cambiar estilos en el editor todo se hace mediante CSS 3.
  • Soporta al parecer 65 lenguajes o dialectos, y al menos tiene buen soporte para Ruby, JScript y Python por lo que vi hasta ahora.

Atención: para los que buscar una IDE, este es sólo un editor. Pero es muy interesante, parece ser activamente mantenido, y puede ser una competencia interesante a los tradicionales TextMate y Vim habituales en el mundo Mac.

Dejo como muestra una captura del editor en mi máquina:

Kod-screen

lunes, 27 de diciembre de 2010

La campaña Anti-IF

 

I have joined Anti-IF Campaign

Francesco Cirillo, de Italia, conocido por muchos como el creador de la Técnica Pomodoro para manejar el tiempo personal, inició tiempo atrás una campaña más específicamente orientada a los programadores:

El objetivo de esta campaña iniciada en 2007 es captar la atención en la comunidad de desarrollo sobre el abuso de técnicas procedurales en detrimento de las capacidades de orientación a objetos que los lenguajes que en general utilizamos tienen. El apuntar específicamente en contra del IF (y por extensión su derivado extremista, SWITCH/CASE) implica hacer foco en el valor del polimorfismo en lugar del abuso de condiciones que pueden expresarse en forma más clara y mantenible de otra manera.

El ejemplo canónico que presenta el sitio de la campaña es:


// Bond class
double calculateValue() {
   if(_type == BTP) { 
       return calculateBTPValue();
      } else if(_type == BOT) { 
       return calculateBOTValue();    
      } else {
       return calculateEUBValue();
      }
   }

 

¿Cuántas veces vemos código como éste? Peor aún, es probable que nosotros mismos seamos los culpables, tiempo atrás, o no tanto...

Entre otros problema, este código viola el principio Abierto/Cerrado (Open/Close) popularizado por el tío Bob Martin, ya que cada vez que un nuevo tipo de bono aparezca tendremos que "abrir" nuevamente esta clase para ampliar el tipo de cálculo. La solución es obvia, aunque no la vemos aplicada tan frecuentemente: utilizar polimorfismo basándonos herencia (aunque pronto puede que la herencia no se tan conveniente y cambiemos a composición). Veamos la respuesta propuesta en el sitio:


// Bond class
double calculateValue() {
_bondProfile.calculate();
}
// AbstractBondProfile class
abstract double calculate()

// BTPBondProfile class >> AbstractBondProfile
double calculate() {
...
}
// BOTBondProfile class >> AbstractBondProfile
double calculate() {
...
}
// EUBondProfile class >> AbstractBondProfile
double calculate() {
...
}

 

A partir de crear una clase base con un método abstracto, respetamos el principio Abierto/Cerrado porque podemos agregar más tipos de bono simplemente agregando nuevas subclases, sin tener que tocar (necesariamente) la base.

Es interesante ver la lista de gente que apoya la campaña, entre los que se encuentran nombres conocidos como David Laribee (conocido miembro de la comunidad Alt.NET), Kent Beck (el "padre" de Extreme Programming y JNunit), Dave Nicolette (otro reconocido agilista), y muchos otros.

 

 

 

 

viernes, 24 de diciembre de 2010

Regalo de navidad: Code & Beyond versión móvil

C&B telefoneado

Para quienes leen este blog usualmente desde su celular, acabamos de agregar un estilo mejorado para navegadores con pantallas reducidas, como teléfonos o iPods.

Esperamos que el formato les sea más cómodo para leer.

Si tienen instalada una aplicación de lectura de códigos de barras bi-dimensionales (la mayoría de los teléfonos la tienen actualmente) pueden apuntar su cámara directamente al código debajo para navegar hacia este blog:

Code & Beyond móvil

 

 

 

 

 

¡Felíces fiestas!

jueves, 23 de diciembre de 2010

Resultados de la Reunión Alt.Net en Buenos Aires

Alt.Net Hispano

Hace un par de fines de semana, el sábado 11 de diciembre, se realizó una nueva reunión del movimiento Alt.Net en Buenos Aires, en las remodeladas oficinas de Microsoft de Argentina, que duró todo el día.

Por las características de la reunión, más alguna dificultad con la conectividad, se hizo imposible capturar video, pero afortunadamente nos quedó este excelente resumen que publicó el amigo Pedro Wood, quien se vino para esta reunión desde Bariloche, nada menos. Pueden leer ahí un buen compendio de las sesiones en las que él participó y comentarios generales.

Dejo un par de fotos que tomé en los momentos de descanso del evento:

5285547260_787225a0fc.jpg

5285547018_9c3b7e4528.jpg

El set completo (son solo cuatro fotos) está disponible en Flickr.

martes, 21 de diciembre de 2010

Lenguajes esotéricos

Esoterismo

Para quienes somos aficionados a los lenguajes de programación, todo paradigma alternativo o detalle de implementación novedoso tiene un atractivo especial, ya que sin importar el hecho de que sean prácticos o relevantes como lenguajes, todos dejan alguna lección que puede ser útil en algún momento.

De hecho, hay muchos lenguajes que ni siquiera intentan ser útiles, sino que son ejercicios intelectuales, de la misma forma en que años atrás en Europa el taller de literatura potencial Oullipo producía sus obra alrededor de desafíos como escribir una novela sin la letra e, poemas usando palabras de largo ascendente en cada verso, o utilizando palíndromos.

Siguiendo esa tradición de experimentar con lo absurdo, en el terreno de los lenguajes de programación se han generado muchos que están basados en ideas locas, pero cuya implementación plantea un desafío real y un buen ejercicio.

David Morgan, también conocido como Danger Mouse, tiene una sección entera de su sitio dedicada a este tipo de lenguajes, entre los que encontramos algunos como:

Chef: en el que los programas parecen recetas de cocina

Este ejemplo es un programa que imprime los primeros 100 números de la serie de Fibonacci.

Ingredients.
100 g flour
250 g butter
1 egg

Method.
Sift the flour. Put flour into mixing bowl. Serve with caramel sauce.
Stir for 2 minutes. Remove egg. Rub the flour until sifted.
Stir for 2 minutes. Fold the butter into the mixing bowl.
Pour contents of the mixing bowl into the baking dish.

Recuerden que esto no es sólo una idea, existe un intérprete (escrito en Perl) para este lenguaje.

Piet: en en que los programas parecen arte abstracto

No confundirse con Mondrian (ambos refieren al artista Piet Mondrian), que es un lenguaje de scripting que si existe y se utiliza bastante.

Piet se basa en bloques de colores llamados Codels (pueden pensarse como pixels, pero frecuentemente se amplían a más de un pixel por codel para ver los programas con más claridad).

El lenguaje está basado en stacks y tiene una cantidad de operaciones usuales como push y pop, operaciones como add, substract y multiply, comparaciones, punteros, etc. Pero en lugar de expresarse en forma textual, se expresan como cambios entre un set de 20 colores.

Va aquí un ejemplo con el mismo ejercicio de imprimir los primeros 100 números de la serie de Fibonacci:

Fibonacci escrito en Piet

Esta imagen está magnificada y muestra con fechas el sentido de flujo del programa. Nuevamente, este lenguaje cuenta con varios intérpretes e incluso herramientas de desarrollo, incluyendo alguna IDE.

 

Esta sección del sitio de Morgan es parte de una red de sitios (unidos bajo este antiguo concepto de las primeras épocas de la web) conocido como The Esoteric Programming Languages Ring.

viernes, 17 de diciembre de 2010

LiveReload: Mejorando la productividad, tecla por tecla

Acabo de encontrarme con una herramienta asombrosamente trivial pero increíblemente útil y adictiva: LiveReload.

Esta herramienta es para Mac OS X y soporta por ahora Safari y Chrome, pero imagino que pronto veremos clones para otras plataformas y browsers. El concepto es tan básico que parece increíble que nadie lo haya hecho antes.

Básicamente LiveReload se configura para monitorear una carpeta, de la que pueden incluirse o excluirse algunas extensiones en particular, etc.

A partir de el inicio del servicio (y teniendo la extensión correspondiente instalada y habilitada en alguno de los browsers), cualquier cambio que se graba en uno de esos archivos refresca automáticamente el contenido de la página (en gran parte de los casos ¡sin refrescar la página misma!) sin que tengamos que hacer nada en el browser.

Como siempre, un video vale más que 1024 palabras, así que dejo debajo uno grabado por Gregg Pollack para que vean la magia en acción.

Por supuesto, esto no es tan fácil de lograr tan eficientemente en entornos con compilación de por medio, pero solamente la magia de tocar hojas de estilo o scripts y verlos variar instantáneamente puede transformar nuestra forma de trabajo.

jueves, 16 de diciembre de 2010

Video: Windmill trae una alternativa al testing web

Windmill

La mayoría del testing automatizado sobre aplicaciones web se hace hoy día utilizando Selenium, que se ganó su predominancia por haber sido el primer framework completo para este objetivo.

Sin embargo, quienes lo utilizan bastante empiezan a notar algunos problemas estructurales que no le restan valor, pero complican el pasar de cierto nivel de aseguramiento. Como siempre, una buena respuesta a lo límites de una herramienta suele ser utilizar otras complementarias, sacando provecho de la diversidad.

Windmill es otro framework open source,  para efectuar este tipo de pruebas que tiene algunas características prometedoras y está siendo cada vez más apreciado en la comunidad. El producto corre en Python pero sirve para probar cualquier tipo de interfaz web, soportando múltiples browsers (incluso, con algunos cuidados, el problemático IE6).

Algunas de sus características principales:

  • Múltiples browsers
  • Grabación, Edición y Ejecución de pruebas
  • Shell interactivo, basado en Python, que permite scripts para extender los casos
  • API de Proxy que permite interceptar y modificar el contexto de ejecución para contemplar situaciones posibles en distintos browsers y escenarios cliente
  • Las pruebas pueden escribirse también en Javascript, incluyendo las funciones de JSUnit
  • Controller API que permite ejecutar programáticamente cualquier tipo de acción interactiva como cliquear, escribir, esperar, arrastrar y soltar, hacer clic derecho, etc.

Pero como nada es mejor que ver algo en acción, aquí comparto un video demostrando rápidamente el framework en acción:

miércoles, 15 de diciembre de 2010

Cartilla de ayuda para vi/vim

Vim

vi es una herramienta clásica del mundo Unix que mucha gente encuentra arcaica y obscura, mientras otros son fanáticos de su simpleza y flexibilidad.

Se trata de un editor de textos escrito por Bill Joy en el 76, años antes de la fundación de Sun, famoso por sus modos de operación (insert o normal) y su capacidad para interactuar con el sistema operativo subyacente.

Uno de sus derivados más populares es Vim, creado originalmente en 1991 para las computadoras Atari Amiga y portado con el tiempo a prácticamente todas las plataformas modernas, aunque su mayor popularidad sigue estando en la comunidad Linux/Unix.

La particularidad de ambos editores es que no utilizan menúes sino comandos de texto (estilo línea de comando) o teclas especiales. Es esta característica la que fanatiza a muchos usuarios de Vim: no hace falta tocar el mouse para usarlo.

El equipo de ViEmu, un plugin para Visual Studio, Word, Outlook y SQL Server Studio que agrega a estos entornos las capacidades de comandos, macros y secuencias de teclado tradicionales de Vi, ha publicado una cartilla visual (cheat sheet) que puede ayudarnos a aprender vi/vim o servirnos de referencia para los comandos menos usados. La reproduzco vinculada a la página original donde también hayuna serie cartillas en forma de lecciones para aprender el uso en orden.

Vim Cheat Sheet

 

martes, 14 de diciembre de 2010

13 cosas que todo Programador debería saber

Portada del libro

A principio de este año O'Reilly publicó este libro que compila 97 cosas que todos en esta profesión deberíamos saber, expresadas por una serie de profesionales de diferentes orígenes, algunos muy famosos, otros no tanto.

Lo que no me había enterado es que el libro completo surgió de un proyecto colaborativo y abierto, y que todo el contenido está disponible en línea en forma gratuita, además de muchos otros consejos que quedaron fuera del libro, pero pueden ser leído y evaluados.

En la Wiki pública del proyecto puede accederse todo este contenido, proponer colaboraciones y muchos más.

Aunque el contenido principal está en inglés, creo que es un material interesante para revisar.

Una de las preguntas más frecuentes alrededor del proyecto es ¿por qué 97? La respuesta es que apuntaban a alrededor de 100 consejos, pero no querían caer en los obvios 99 o 101, por lo que decidieron tomar el número primo más cercano: 97. Toda una muestra del espíritu nerd detrás del proyecto.

Siguiendo ese tono, traduzco los primeros 13 puntos, con sus respectivos links a la wiki (cuyos textos siguen en inglés, lamentablemente; si alguien conoce alguna iniciativa para traducir el contenido, por favor, avísenme).

  1. Actúa con Prudencia por Seb Rose

  2. Aplica Principios de Programación Funcional por Edward Garson

  3. Pregúntate: "¿que haría el usuario?" (tu no eres el usuario) por Giles Colborne

  4. Automatiza tus estándares de código por Filip van Laenen

  5. La belleza está en la simplicidad por Jørn Ølmheim

  6. Antes de refactorizar por Rajith Attapattu

  7. Cuidado al compartir por Udi Dahan

  8. La regla de los Niños Exploradores por Uncle Bob

  9. Verifica tu código antes de buscar otro a quien culpar por Allan Kelly

  10. Elige tus herramientas con cautela por Giovanni Asproni

  11. Programa en el lenguaje del dominio por Dan North

  12. Codificar es Diseñar por Ryan Brush

  13. El formato del código importa por Steve Freeman

lunes, 13 de diciembre de 2010

Biblioteca open source de algoritmos y estructuras de datos para .NET

Frans Bouma

Frans Bouma, reconocido en la comunidad por su O/RM LLBLGen Pro, ha publicado recientemente en CodePlex una biblioteca open source para .NET cubriendo una cantidad importante de algoritmos y estructuras de datos clásicas que la Base Class Library no tiene, o cuya implementación podía mejorarse.

Algunas de las estructuras y algoritmos asociados son:

  • Comandos (y su administración): con soporte de undo/redo y grupos de comandos.
  • Grafos: directos y no-directos, sub-grafos, clausuras transitivas y ordenamiento topológico, etc.
  • Heaps
  • Colas prioritizadas
  • Ordenamiento
  • Bolsa de Propiedades
  • Implementaciones mejoradas de IEditableObject/IDataErrorInfo
  • Filtro de eventos
  • y otras utilidades menores

Esta biblioteca, llamada Algorithmia, se suma a las BCLExtensions, un conjunto de extension methods sobre varios tipos de la Base Class Library, para propósitos generales.

Ambos proyectos están disponibles en CodePlex, utilizando el soporte de código fuente de Mercurial y licenciados bajo BSD2.

Como Frans ya ha aclarado varias veces, no importa si a alguien le gusta más GIT que Mercurial o GitHub que CodePlex. Esas elecciones corresponden al autor, y sólo tienen importancia si uno está decidido a colaborar con el proyecto (para usarlo basta con un download plano de los fuentes), cosa que pocos hacen en la práctica, y quienes realmente quieren contribuir nunca tienen problemas en utilizar un cliente u otro de control de código.

 

viernes, 10 de diciembre de 2010

Finalmente está aquí: Chrome Web Store

Chrome Web Store

Como se venía anunciando desde hace tiempo, esta semana abrió al público la Chrome Web Store.

La idea de esta tienda en línea es brindar el mismo tipo de experiencia de búsqueda de aplicaciones con calificaciones y comentarios de usuarios, categorías, descripciones, y opciones pagas o gratuitas que los usuarios de teléfonos inteligentes disfrutan desde el éxito del AppStore del iPhone, y que fue replicado en Android, Windows Phone 7, la iPad y demás.

Hay bastante discusión en línea acerca de que esta tienda no es más que maquillaje sobre el concepto de links y favoritos, pero veamos un poco sus características:

Lo primero que notará quien la acceda desde un navegador que no sea Chrome será que las aplicaciones sólo funcionan en ese browser. La imagen a continuación está capturada desde mi Firefox.

Web Store Home

¿Porqué sólo funciona en Chrome? En principio porque las aplicaciones pueden ser de varios tipos.

El nivel más básico puede ser un sitio web tradicional al que se le agrega sólo algo de metadata que usa la tienda para identificarla. Pero también puede ser una extensión para Chrome o un tipo de aplicación web más específico que puede descargarse y correr incluso offline dentro del sandbox de Chrome. Estos dos tipos de aplicaciones pueden utilizar además el API de Chrome para brindar funcionalidad específica más integrada al browser mismo.

Desde el punto de vista de nosotros como desarrolladores, lo más importante es el Developer Dashboard, que permite publicar cualquiera de estos tipos de aplicaciones, sin restricciones específicas, ya que Google ha decidido dejar la tarea de evaluar las aplicaciones a los usuarios mismos. Para poder publicar cualquier cosa, debe realizarse un pago por única vez de 5 dólares, más orientado a verificar la identidad asociada a la cuenta utilizada que a otra cosa.

Más que ninguna otra cosa, este es un nuevo mecanismo para dar a conocer aplicaciones y sigue empujando el mercado de empresas pequeñas de desarrollo que pueden alcanzar una alcance global con facilidad.

El principal problema que veo a todo esto es que crea un nuevo silo en lugar de ser algo abierto, pero es un experimento interesante.

jueves, 9 de diciembre de 2010

Video: Virtual Alt.Net sobre Ruby on Rails

El pasado 20 de noviembre se realizó otra de las reuniones que organiza semanalmente la comunidad Alt.Net Hispano, esta vez dedicada a por completo a Ruby on Rails, y a cargo de Mario Chávez (Twitter: @mario_chavez).

Unable to display content. Adobe Flash is required.

Durante la sesión Mario recorre una serie de recursos interesantes que dejo detallados aquí para quienes quieran accederlos directamente:

  • Rails Hispano es un podcast sobre RoR en español, que se publica mensualmente, de media hora de duración.
  • Ruby on Rails Tutorials, de Michael Hartl: son varios tutoriales en video y texto, en inglés, y aunque hay parte del contenido pago, mucho es accesible en línea en forma gratuita.

Finalmente, agrego una noticia de color sobre Ruby. Para los fanáticos del Ratón Mickey puede ser interesante el anuncio de la primer conferencia Magic Ruby, a realizarse del 4 al 5 de febrero de 2011 en Disney's Contemporary Resort de Orlando, Florida, que conecta via monorail con los parques temáticos. Lo interesante de la conferencia es que es gratuita (aunque hay que pagar el pasaje y la estadía, claro).

 

martes, 7 de diciembre de 2010

Android 2.3 (Gingerbread) recién salido del horno

Siguiendo la tradición de ponerle nombres de cosas dulces a las versiones de sus sistema operativo para dispositivos, Google lanzó Android 2.3, conocido como Gingerbread, y su correspondiente Kit de Desarrollo.

Como curiosidad, estos son los nombres de las versiones anteriores:

1.51.62.0/2.12.22.3
CupcakeDonutEclairFroyoGingerbread

Cupcake

Donut

Eclair

Froyo

Gingerbread

Las mejoras principales de esta versión se enfocan en:
  • Mejoras para desarrollo de juegos Principalmente a través de mejoras en el tiempo de respuesta gracias a retoques en el garbage collector y manejo de eventos, y exponiendo más APIs nativas que permiten acceder a bajo nivel las entradas y sensores (incluyendo giróscopos), EGL/OpenGL ES, OpenSL ES, etc.
  • Más riqueza multimedia La plataforma soporta ahora estándares de video abiertos como VP8 / WebM, audio y voz AAC y  ARM-wideband, y agrega efectos como reverb, ecualización, virtualización de audífonos y mejora de bajos.
  • Más formas de comunicación La plataforma soporta múltiples cámaras, típicamente para una frontal utilizada en video chats, soporte de llamadas via internet via SIP/VOIP,  y NFC (Near Field Communications) para permitir que los dispositivos se comuniquen con otros dentro de un rango de proximidad de unos 10 centímetros.

Aquí dejo el video promocional:

Y la liberación de la nueva versión se cristaliza con la aparición en conjunto de un primer dispositivo que trae esta versión de fábrica, el Nexus S, que Google desarrolló en conjunto con Samsung. Dejo también el video promocional para que se entretengan:

 

Videos de SmallTalk 2010 disponibles

Smalltalks 2010

Como comenté hace casi un mes, la última conferencia internacional Smalltalks 2010 se realizó en Concepción del Uruguay, en la provincia de Entre Ríos, Argentina.

Esta conferencia atrajo profesionales de esta comunidad de Ameríca del Sur, del Norte y de Europa, incluyendo figuras famosas del ambiente de lenguajes de programación como Gilad Bracha.

En los últimos días, los organizadores han publicado los videos de todas las sesiones, con buena calidad de audio y video en general, para que todos podamos disfrutarlas. Tratándose de una conferencia internacional, las sesiones fueron en inglés, pero debido a la procedencia variada del público, es casi siempre un inglés pausado y fácil de seguir.

Una excepción es la charla final presentada por el Maestro Angel "Java" López, hablada en Anglish (Angel's English) que él mismo describe en el comienzo. La sesión está dedicada a AjTalk, su máquina virtual de Smalltalk implementada en C# sobre el CLR de .NET, pero además de los detalles técnicos es muy entretenida y recomendable.

AjTalk: an Smalltalk-like Virtual Machine written in C#

Primera Parte

Unable to display content. Adobe Flash is required.

 

Segunda Parte

Unable to display content. Adobe Flash is required.

lunes, 6 de diciembre de 2010

Videos: Crockford habla sobre JavaScript

JavaScript: The Good Parts

Javascript sigue creciendo en relevancia. Hace bastante tiempo, hablaba sobre este tema en otro blog, aunque todavía este lenguaje no se había afianzado tanto del lado del servidor, cosa que está sucediendo ahora gracias a Node.js.

Así que siempre vale la pena conocer más sobre Javascript, incluyendo detalles acerca de su historia. Y quien mejor para esto que Douglas Crockford, actual Javascript Architect de Yahoo!, autor del excelente libro "Javascript: The good parts", y las herramientas indispensables JSLint (un verificador de prácticas) y JSMin (un minificador de código).

A principios de este año y a lo largo de varia semanas, Crockford dio una serie de seis charlas sobre Javascript que quedaron registradas en video (en inglés). El temario completo es:

  • Volume One: The Early Years
  • Chapter 2: And Then There Was JavaScript
  • Act III: Function the Ultimate
  • Episode IV: The Metamorphosis of Ajax
  • Part 5: The End of All Things
  • Scene 6: Loopage

Reproduzco aquí la primera de las charlas, que además de reveladora es muy divertida.

La serie completa está disponible en un sitio completo dedicado a las charlas, que incluye versiones de los videos para descarga en diferentes resoluciones, o la posibilidad de verlos online, y las transcripciones completas de las charlas para quienes les cuesta más escuchar el inglés que leerlo.

Finalmente, para quienes prefieren material estrictamente en castellano, les dejo enlaces a algunos de los trabajos de Corckford traducidos por distintas personas de la comunidad:

 

viernes, 3 de diciembre de 2010

Rust: un nuevo lenguaje experimental desde los labs de Mozilla

Mozilla Labs

La gente de Mozilla Labs publicó recientemente en GitHub su proyecto Rust, un lenguaje experimental.

Según la wiki con preguntas frecuentes, estos son los puntos importantes del lenguaje:

Seguridad

  • Manejo de memoria seguro. Sin punteros nulos o huérfanos, y con administración automática.
  • Control de mutabilidad. Inmutable por omisión. No hay estado mutable compartido entre tareas.
  • Seguridad en ejecución dinámica. Permite atrapar, loguear y procesar fallas en general.
  • Sistema de estado de tipos. Permite definir invariantes complejas sobre estructuras de datos.

Concurrencia y Eficiencia

  • Control de memoria explícito, sobre alocación y disposición.
  • Tareas (corutinas) livianas, de muy bajo costo al dispararlas de a miles o millones.
  • Iteradores de pila (bloques lambda sin alocación en el heap)
  • Compilación estática y nativa.
  • Interfaz simple y directa con código C

Pragmatismo

  • Multiparadigma: puramente funcional, concurrencia/actores, procedural/imperativo, orientado a objetos.
  • Multiplataforma: Windows, Linux, OS X.
  • Strings UTF8 y tipos a nivel de máquina
  • Permite romper reglas declarándolo explícitamente

Como explican en la Wiki, el proyecto, aunque tiene algunos leves puntos de contacto, se inició mucho antes que Google publicara su lenguaje Go, y aunque su sintaxis (por ahora, ya que no es el foco del proyecto todavía) también huele a C (usando llaves, punto y coma, etc).

Para variar, desde este blog no dejamos de celebrar novedades en el ambiente de lenguajes e programación, que aún cuando no llegan a popularizarse siempre aportan conceptos e ideas interesantes que se aprovechan tarde o temprano en otro lado.

 

      jueves, 2 de diciembre de 2010

      ¿Python más rápido que C?

      Entre los videos de las 6tas jornadas de Software Libre que mencioné en el último post, encontré este que me resultó muy interesante y divertido, a cargo de Facundo Batista (uno de los sospechosos de siempre en la comunidad Python local) en el que cuenta una serie de ejercicios desarrollados junto a Lucio Torre para comparar en contextos y situaciones diferentes los tiempos de ejecución de ambos lenguajes.

      Sobre el inicio Facundo aclara que el código C fue escrito en todos los casos por Lucio y el código Python por él mismo, y ambos tienen aproximadamente el mismo nivel de experiencia y familiaridad con cada lenguaje. Cualquiera en la comunidad iría más allá y diría que ambos son reconocidos expertos en el suyo.

      Obviamente hay mucho material para discutir (aún cuando no hay intento alguno de mostrar Python realmente más rápido que C en crudo), pero el objetivo de la charla es reflexionar sobre el proceso, y se habla bastante de la forma en que aplicamos diferentes niveles de optimización. De fondo, incluso, utilizar un lenguaje de bajo o alto nivel, uno estático o dinámico, suelen ser decisiones que optimizan tiempo de desarrollo/mantenimiento, o de ejecución.

      La sesión es corta y divertida, así que la reproduzco aquí debajo, pero antes quiero replicar una frase que Facundo destaca en uno de los slides, y que coincide con algo en lo que insisto hace años, pero nunca había escuchado con esas palabras:

      "Es más fácil optimizar código correcto que corregir código optimizado"

      Disfruten el video:

      Videos de las 6tas Jornadas de Software Libre - Junín 2010

      Sextas Jornadas de Software Libre

      El 5 y 6 de noviembre pasados se realizaron en la localidad de Junín, Buenos Aires, Argentina, las 6tas Jornadas de Software Libre.

      Hubo charlas de Python, Debian, Ubuntu, Linux en general, programación y administración, como pueden ver en el Cronograma completo.

      Durante el evento se pudieron grabar las charlas y ahora ya están disponibles para quienes no pudieron asistir.

      Pueden ver muchos de los videos en esta página:

      http://unnoba.blip.tv/posts?view=archive&nsfw=dc

      Y les dejo a mano este del amigo Juan Gabardini charlando sobre la relación entre Software Libre y Métodos Ágiles. Espero que la disfruten.

      Miguel de Icaza: Más sobre Mono para OS X y iOS

      Mac OS X

      Miguel lanzó un nuevo blog personal especializado en el sistema operativo de Mac y el de iPhone/iPod/iPad, visto por supuesto, desde la perspectiva de Mono.

      Como explica en el post inicial, las razones principales para tener un blog separado del suyo personal de siempre, exclusivamente dedicado a este tema, son dos:

      • Mientras que su blog está dedicado más que nada a novedades generales del proyecto Mono, éste está orientado a documentar sus experiencias específicas con estos ambientes de Apple, en un nivel de detalle más granular, que puede molestar a quien no tiene interés específico en el tema.
      • Estos sistemas operativos son propietarios y están bastante alejados de los ambientes abiertos usuales para gran parte del público anterior.

      En cualquier caso, es muy interesante tener un buen recurso técnico con detalles sobre MonoTouch, la implementación de Mono y herramientas de desarrollo para programar aplicaciones para iOS en lenguajes .NET, que es un producto comercial (sobre todo por temas de licenciamientos varios), y MonoMac, que si es un producto abierto y gratuito para hacer lo mismo sobre Mac OS X (que sí es un sistema propietario).

      Lo que ambos proyectos brindan, fundamentalmente, es la posibilidad de programar en C# y utilizar las librerías de la BCL, pero con bindings agregados para interactuar con el entorno de Apple en Objective-C y la interfaz de usuario Cocoa, lo que es una buena alternativa para quienes están interesados en desarrollar para estos dispositivos pero no tanto en aprender todos los detalles y lenguajes específicos.