Rara esta forma de Youtube de dar a elegir al usuario entre ver un anuncio sabiendo de antemano cuál, o recibir 3 durante el video.
¿Quién elige ver los 3 anuncios en lugar de solo 1? Ah, si te da curiosidad saber cual es el video, aca está el link (NSFW).
Ayer, tras un update sorpresivo de TextMate 2, me dejó de funcionar por un bug al editar archivos .js. Es lo malo de usar software en versiones alpha.
Como suele pasar, me pasó en el momento menos oportuno así que salí a cazar otro editor de código. Sublime mucho no me gusta, y me pareció buena idea probar Chocolat app, un editor bastante nuevo.
Me sorprendió cuando al ejecutar la aplicación, me recibió un cartel diciendo que podía usar el software todo lo que quisiera, pero si no abonaba la licencia, la tipografía iba a ser Comic Sans.
Efectividad del 100%, a los 15 minutos estaba sacando la tarjeta de crédito y ahora estoy usando Chocolat como mi editor de código :P
Moraleja: No te vuelvas loco si haces algo freemium, deja que se use al 100%, pero modificá un detalle que vuelva a la aplicación insoportable y que se pueda corregir solo comprando el producto.
Hace algunos días que está funcionando deportv el sitio estatal con streaming en vivo de los eventos deportivos en Argentina (seamos sinceros, 99% futbol, 1% tenis).
La calidad de la imagen es buena y tiene una disponibilidad, hasta ahora, perfecta. Habrá que ver si esto se mantiene cuando el sitio se vuelva mas popular. Tambien es cierto que los eventos deportivos son mayormente cuando la gente no está trabajando con lo que puede ver el evento por televisión con una mayor calidad y tamaño de imagen.
Como dato divertido, el player no está bloqueando por dominio con lo que podes tener tu propio sitio de streaming de futbol argentino, cortesía de nuestros impuestos (ejemplo).
Entiendo que esto es una iniciativa del gobierno, pero poner esto en un dominio .gov.ar… me molesta, no tiene nada que ver con una entidad gubernamental, es como si la BBC estuviese alojada en bbc.gov.uk, mas apropiado hubiese sido deportv.com.ar y ahi aclarar que era un sitio propiedad del estado argentino.
Cosas que nunca voy a entender de CodeIgniter, un framework de PHP bastante completo, pero que te hace repetir las mismas cosas una, y otra, y otra vez.
Entre las tareas repetitivas, me cansé de escribir las mismas funciones para crear, editar, leer y eliminar registros de la base de datos, asi que aprovechando la capacidad de extender el modelo base CI_Model, busqué alguien que ya hubiera creado estas funciones CRUD (Create, Read, Update, Delete) y las pueda heredar en mis proyectos.
Hay varias implementaciones, pero la de Jesse Terry me parece la mas sencilla y completa de todas, facil de ajustar si necesitamos hacerlo.
Hace bastante tiempo que me llaman la atención los frameworks MVC de Javascript, particularmente los 2 mas destacados, Ember y BackBone.js.
Aprovechando el fin de semana, leí la documentación de ambos y jugué un poco con su código. Primero lo primero.
Al igual que los frameworks MVC para otros lenguajes, como OnRails para Ruby, o CodeIgniter para PHP, las ventajas son órden del código, empezar a trabajar sobre una base sólida y documentada y tambien adoptar una forma de trabajo común a varios desarrolladores, esto es útil si estamos en una organización y tenemos que sumar desarrolladores al equipo.
La particularidad claramente es que en JavaScript estamos trabajando en el navegador, del lado del cliente, con lo que el Modelo, siempre tan relacionado a algo donde persistir información, al principio resulta confuso.
Esta confusión se disipa rapidamente cuando entendemos que el modelo es el encargado de, justamente, persistir la información y mantenerla sincronizada entre el cliente y el servidor.
El Controlador, como siempre es el encargado de la lógica para comunicar los datos que da el modelo y la información que se muestra al usuario, y viceversa.
La Vista, se ocupa de mostrar la información, por lo general en forma de Templates de HTML para que podamos reusar partes comunes de la aplicación.
Quienes hayan tratado de crear una aplicación algo compleja en el cliente, saben lo inmanejable que se vuelve el código para hacer algo relativamente sencillo. El tener que guardar información en el DOM del documento, estar atento a cambios en el mismo y tener que releer con timeOuts para poder mantener la estructura del DOM manejable. Claramente el DOM no está hecho para crear aplicaciones.
Un framework MVC, va a ocuparse de esta lógica de una forma muy elegante, nosotros vamos a trabajar con datos en objetos y atributos en JavaScript, y el framework se va a ocupar de mantener en sincronía esta información, con lo que el usuario ve en su pantalla.
jQuery.getJSON('/posts/1', function(post) {
$("#post").html("<h1>" + post.title + "</h1>" +
"<div>" + post.body + "</div>");
});El ejemplo de arriba es un caso típico de actualizar el DOM de un documento HTML sin usar un framework MVC.
<h1>{{ post.title }}</h1>
<div>{{ post.body }}</div>
<script>
post: {
title: 'My post title',
body: 'My post body.'
}
</script>Mientras que en este ejemplo, nosotros solo vamos a ocuparnos de mantener actualizado el objeto post, y el framework se ocupara de mantener sincronizado el DOM ya que el template contiene las variables donde va la información.
Sin tener experiencia real en estos, es dificil hacer una recomendación, a priori, Ember me pareció bastante mas complejo que BackBone.js, y va alineado con esta respuesta en StackOverflow:
Contrary to popular opinion Ember.js isn’t a ‘more heavy weight approach’ to Backbone.js. They’re different kinds of tools that target totally different end products. Ember’s sweet spot is applications where the user will keep the application open for long periods of time, perhaps all day, and interactions with the application’s views or underlying data trigger deep changes in the view hierarchy. Ember is larger than Backbone, but thanks to Expires, Cache-Control this only matters on the the first load. After two days of daily use that extra 30k will be overshadowed by data transfers, sooner if your content involves images.
Lo increíble de esto es que ninguno de ambos frameworks alcanzó todavía el release a 1.0, y ya BackBone.js está quedando atrás y siendo usado solo para aplicaciones mas sencillas, que no esten instanciadas en un navegador durante horas y donde no haya riesgo de leaks de memoria.
Mientras estaba releyendo lo escrito antes, me crucé con un tercer framework y no tuve opción mas que investigar mas y finalmente incluirlo: AngularJS, que está creado ni mas ni menos que por Google.
No se si será por el tutorial paso a paso que está super bien armado, con todo el código disponible para ir viendolo paso a paso con un Git checkout o qué, pero lograron hacer que la curva de aprendizaje sea muy leve, algo que es clave para entender un nevo framework.
Tomándoselo con mucha calma, en un par de horas y con una instancia micro de EC2 (para no ensuciar nuestra máquina), podemos hacer los 11 pasos del tutorial y entender cómo trabaja AngularJS.
Tambien me gustó mucho el hincapié que hacen en crear tests para cada paso del tutorial, algo poco visto.
Mi recomendación, si no tenes experiencia en estos frameworks, es comenzar con el tutorial de AngularJS, y después mirar la documentación de Ember y BackBone.js para entender las diferencias.