Before Splats. Spoiler: it is all about tagless components

There is a recurring question about components that appear in Slack: how can I pass different attributes to a component depending on a given object?

As an example, people want to be able to do something like the object spread operator in ECMAScript.

Object Spread Properties

The TC39 proposal Object Rest/Spread Properties for ECMAScript gives us programmers the ability to use the rest and spread operators with objects.

let defaults = { name: "No one", location: "Braavos" };
let arya = { ...defaults, name: "A girl" };
console.log(arya.name); // A girl
console.log(arya.location); // Braavos

let jaqen = { name: "A girl", ...defaults };
console.log(jaqen.name); // No one
console.log(jaqen.location); // Braavos

In these two cases, the spread operator works pretty much like Object.assign:

let arya = Object.assign({}, defaults, { name: "A girl" });
let jaqen = Object.assign({ name: "A girl” }, defaults);

Wouldn’t it be great if we could just {{component varComponentName …someObject}}?

Spread in Handlebars

There is a proposal for adding the splat operator to Handlebars. You can follow the discussion on the original issue opened by mixonic or the PoC implementation by machty. The last I heard is that this feature is on hold because of performance concerns.

But I need a solution!

Let’s try to fix this problem. For that, we will create an interface for a mili-blogging (more than microblogging but not as huge as blogging) network with several (read as “at least three”) post types. Let’s call this network stumblr.

You can blog text, images and quotes in stumblr. These three types are defined as follow in the JSON payload (the Ember Data models can be found in the twiddle linked later):

// Text
{
  id: "some-text",
  type: "text",
  attributes: {
    text: "Verde que te quiero verde. Verde viento. Verdes ramas."
  }
}

// Quote type
{
  id: "some-quote",
  type: "quote",
  attributes: {
    quote: "There's one thing I always wanted to ask Jack. Back in the old days. I wanted to know about that Doctor of his. The man who appears out of nowhere and saves the world; except sometimes he doesn't. All those times in history where there was no sign of him … I wanted to know why not. But I don't need to ask anymore. I know the answer now: Sometimes the Doctor must look at this planet and turn away in shame. I'm recording this in case anyone ever finds it, so you can see. You can see how the world ended.",
    author: "Gwen Cooper"
  }
}

// Image Type
{
  id: "some-image",
  type: "image",
  attributes: {
    src: "http://my-mili-cdn.org/my-image.png",
    caption: "Some caption"
  }
}

(I know this is not valid JSON but each part is a valid JSO, close enough for me.)

We define three components, one for each type:

// Assuming the template is {{text}}
import Ember from 'ember';
export default Ember.Component.extend({
  tagName: 'article',
  classNames: ['stumblr-text']
});
// Assuming the template is
// <p class="quote-body”>{{quote}}</p>
// <p class="quote-author”>{{author}}</p>
import Ember from 'ember';
export default Ember.Component.extend({
  tagName: 'article',
  classNames: ['stumblr-quote']
});
// Assuming the template is
// <figure> 
//   <img src={{src}} />
//    {{#if caption}}<figcaption>{{caption}}</figcaption>{{/if}}
// </figure>
import Ember from 'ember';
export default Ember.Component.extend({
  tagName: 'article',
  classNames: ['stumblr-image']
});

We now have one component for each post type and we can render them statically just by invoking them, as usual. You can play with the result in this twiddle.

In this example we are very restrictive: we are assuming we will always receive an image, a quote and a text. What if our user used stumblr strictly as a photoblog?

Since we will need to choose the component based on a model we can used a property to choose between several options. As an example, we add the property componentName to the Image model:

export default DS.Model.extend({
  componentName: 'dynamic-stumblr-image'
});

We can now render the right component just using the {{component}} helper:

{{component postModel.componentName post=postModel}}

If you want to know more about the {{component}} helper, read my post about it: The Path to Contextual Components: Understanding dynamic components. Notice that we are not restricted to a property in the object to return the name for the component: we can use a helper too.

We will use dynamic-stumblr-image to set the right attributes in stumblr-image.

{{! template for dynamic-stumblr-image }}
{{stumblr-image
    src=post.src
    caption=post.caption}}

Repeat this for the rest of components and change the previous template to:

{{#each model as |item|}}
  {{component item.componentName post=item}}
{{/each}}

and you will get a pretty similar result. Examine this twiddle to see the rest of the changes (new dynamic-stumblr-foo components and new model hook in the route).

Still not there

Though it seems so, we are not producing the exact same output: our dynamic-stumblr-foo components produce an extra tag around the stumblr-foo version. Let’s get rid of that.

In a component, the property tagName let us select which tag Ember will use to surround our template. If we set tagName to ul we will make our component a list, article would make it an article, null will make Ember use div. But if we want Ember not to use any tag at all, what should we do then?

River Song always have a way out

Set tagName to ’’ (empty string). This is our way of asking Ember to get a tagless component. This has some limitations: an id is not guaranteed to get generated and you cannot expect it to call event methods like click, focus and such.

You can see the final result in this twiddle.

Final notes

There are more options here too. Creating a blueprint for component wrappers should not be too difficult. Or maybe your application does not need the duplicated components at all!

Hope you enjoyed it!

Eventos en jQuery, cómo usar on.

En la última entrega vimos que el siguiente código no funcionaba: El anuncio desencadenó un charla con Sergi manteniendo que debería escribir directamente sobre delegación de eventos, que es precisamente lo que vamos a tratar ahora.

Delegando eventos.

jQuery cuenta con muchos métodos para delegar a eventos (bind, delegate o live). Sin embargo, estos métodos están obsoletos desde jQuery 1.7 en favor de on. A pesar de eso, empezaré explicando live, pasaré a delegate y finalmente llegaré a on.

live

El problema del código original se hubiese solucionado fácilmente llamando a live en vez de a on, como se comprueba en el fiddler correspondiente. El código es idéntico, simplemente cambia on por live.

Lo que hace este método es disparar el evento en cualquier elemento que satisfaga el selector, valiéndose de la propagación.

Dado que live está obsoleto y que actualmente live usa on internamente, lo dejaremos aquí.

delegate

delegate es bastante similar a live, sólo cambia cómo llamarlo. La equivalencia de llamadas sería:

El fiddler para delegate simplemente busca el elemento #container y le añade los handlers a él con los selectores correspondientes.

Por cierto, a la hora de escribir este artículo, delegate, ya obsoleto, también delega en on.

on

Finalmente, on es el camino a seguir con jQuery, al fin y al cabo, como habéis podido comprobar, tanto live como delegate usan on internamente.

Usar on para delegar eventos es muy similar a usar delegate, salvando que los eventos y los selectores están en orden inverso. El fiddle lo muestra en funcionamiento y el código completo es el siguiente:

¿Qué es lo que está pasando realmente?

Delegar un evento no hace que jQuery lo añada a los elementos correspondientes en cuanto se creen, sino que se añaden al elemento seleccionado ya existente y, por lo tanto, la propagación se puede parar en cualquier elemento que esté por debajo de él. De ahí que tengamos que pensar dónde delegar el evento ya que podemos cancelarlo sin darnos cuenta.

Por otro lado, tal y como podemos leer en la documentación de on en la sección Event performance, no debemos complicar mucho los selectores dentro de la delegación. Si nos vemos usando selectores jerárquicos, seguramente podamos delegar el evento en un elemento más cercano.

Delegación a mano

Para simular la delegación anterior cuyo selector era una simple clase, podemos hacerla usando el siguiente código:

En él simplemente comprobamos que el elemento que ha lanzado el evento (evt.target en el código) contiene la clase box. Puede parecer poco código extra, pero sin duda son dos líneas que nos ahorramos a cambio de un selector (el cual puede ser más complicado).

Un alto en el camino, eventos.

Hacemos un alto en el camino para aprender un poco más sobre los eventos. Serán tres entregas:

  1. Eventos, cómo funcionan. Características básicas.
  2. Eventos en jQuery. Veremos cómo usar on.
  3. Eventos en jQuery. ¿Qué es eso de trigger?

¿Qué es un evento?

Un evento puede representar varias cosas, pero normalmente es una respuesta a una acción del usuario en nuestra página. Por ejemplo, al pinchar en un elemento lanzamos el evento click. Si seleccionamos un campo, se lanza el evento focus. La lista completa la podéis encontrar la página de w3schools.

 El proceso

El proceso que sigue un evento es algo más elaborado de lo que nos podríamos imaginar en un primer momento. Cuando damos una función para que maneje (handle) un evento, hacemos que maneje el evento en un elemento determinado. Por ejemplo, en este fiddle tenemos tres cajas y, cada vez que pinchamos en una de ellas, nos muestra una alerta con el número de caja, distintas cajas, responden de distinta forma. El código no es importante, pues usaremos jQuery para manejar los eventos y no las apis del DOM, como en este caso. Además, para ahorrarnos código podríamos haber escrito una función que devolviese funciones, como en este fiddle.

Manejando un evento

Para manejar un evento contamos con dos importantes conceptos: el handler y el objeto event.

El handler no es más que la función que será invocada cuando se reciba el evento. Dicha función se ha de relacionar con un nodo del documento, y sólo será invocada si ese nodo en particular recibe el evento correspondiente. Esto es importante cuando veamos qué pasa cuando se dispara un evento.

El handler recibe un argumento con un objeto Event. Aunque dicho objeto es bastante importante, esperaremos a verlo al momento en el que veamos cómo manejar eventos con jQuery.

Sin embargo, el proceso no es tan simple como disparar y recibir un evento.

Every event is bubbling

Un evento es una respuesta a una acción. La acción crea y pone en movimiento un objeto Event. ¿Pero qué camino sigue este evento?  Veamos el siguiente fiddler. El código sigue sin ser importante, sólo que estoy añadiendo un handler (así llamaremos a las funciones que se ejecutan cuando sucede el evento) a todos los elementos li, estando estos anidados y con fondo de distinto color para saber en cuál de ellos estamos haciendo click. El handler lo único que hace es cambiar el texto dentro del li.

Una vez el evento se pone en marcha, sigue subiendo en el árbol del documento, yendo nodo padre a nodo padre. A este proceso lo llamaremos propagación o bubbling. Dicho proceso se puede comprobar haciendo click en los distintos colores de fondo en el anterior fiddler.

Podemos refinar un poco más esta idea con el siguiente fidller. En él, añadimos un nodo hermano al nivel 3. Si pulsamos en el nivel 3 o 4, vemos que el hermano no pulsado no recibe el evento.

Parando un evento

Podemos evitar que un evento siga propagándose o cancelar la acción predefinida de un evento.

Un evento se dice cancelable si su acción predefinida puede ser evitada. Por ejemplo, hacer click en un enlace tiene como acción predefinida el seguir dicho enlace. Al hacer click en un botón para enviar la información de un formulario, la acción predefinida consiste en evitar dicho envío. Estos eventos son cancelables y podemos evitar la acción por defecto llamando al método preventDefault en el objeto Event que se pasa al handler. Hay una forma alternativa de evitar la acción por defecto: devolviendo false desde el handler. Sin embargo, prefiero llamar explícitamente a los diferentes métodos puesto que el comportamiento difiere en jQuery.

Por otra parte, también podemos usar el método stopPropagation para evitar que el evento se propague, aunque esto no evitaría la acción por defecto.

Notas finales

Sé que esta entrega se ha retrasado, y seguramente reduzca el número de publicaciones a dos por semana: una al principio y otra al final.

Lo importante de esta entrega no es saber cómo añadir handlers o cómo parar la propagación de un evento. Todos eso lo veremos cuando hablemos de eventos en jQuery.

Aprendiendo jQuery con la web del Senado, II

Hoy, refactorizando la web del senado, aprenderemos:

  1. A obtener el valor seleccionado de un select.
  2. A ocultar y a mostrar de nuevo un elemento del DOM.
  3. A separar un poco más la funcionalidad javascript del estilo de nuestra web.
  4. A añadir una función a jQuery.
  5. A retrasar la ejecución de nuestro código a que el document html esté listo.
  6. De paso, recordaremos cómo seleccionar un elemento del DOM.

El código original.

El código original es muy simple. Es el siguiente:

En primer lugar, no soy muy fan de poner nombres en español pero, si lo vas a hacer, al menos hazlo bien, mendrugo de pan. Se dice “selecciona”.

Como novedad, iré creando un jsfiddle para que podáis probar el código que vamos creando. La primera versión es ésta. Podréis ver que hay un poco de código extra, ya veremos para qué. Si jugáis un poco con él, veréis que el “Selecioname” cambia de posición. Además está mal escrito.

Empecemos.

Ortografía.

Como ya he dicho, no soy muy fan de poner nombres en castellano en lo que a programación se refiere. Sin embargo, de hacerlo, debemos intentar poner los cinco sentidos en los nombres.

Dicho esto, solucionemos este tema de una vez por todas. El nuevo fiddle recoge los cambios.

Primeros cambios.

Por primera vez, vamos a extender jQuery, vamos a añadir una función al objeto jQuery para saber si devuelve un resultado o no. Llamaremos a la función exist(), y vi esta implementación por primera vez en esta respuesta de StackOverflow.

Vemos que para añadir la función exists sólo tenemos que declararla como un miembro de $.fn.En dicha función, vemos si existe algún elemento comprobando que la longitud de la selección sea distinta a cero. Ésta es la forma más sencilla de extender las capacidades de jQuery.

Dentro de selectCharge, usamos la función $ como aprendimos en la primera parte para seleccionar el elemento div#fs_selecciona_orden. El código ahora mismo no es funcional, pero lo resolveremos en las siguientes secciones.

To display or not to display.

En el condicional, lo que se hace realmente es mostrar o esconder un elemento del dom dependiendo del valor seleccionado en el select.

En vez de modificar la propiedad CSS display del elemento deberíamos usar las funciones show y hide de jQuery. La razón más poderosa es que show y hide recuerdan la propiedad display anterior del elemento. Así, si el elemento tenía display: block; antes de usar hide, al llamar a show volverá a tener display: block;. Esto permite separar mejor el estilo de la programación. Si el diseñador cambiase el estilo del elemento y nosotros no tocásemos el código, la podíamos liar “parda”.

Además, podemos pasar parámetros extra si queremos que se convierta en una animación.

El código en esta fase se parece a lo siguiente:

Retoques finales.

El código requiere de dos toques finales:

  1. La función exists no es realmente necesaria.
  2. Usar jQuery con el parámetro select.

Como ahora estamos usando las funciones show y hide, no necesitamos comprobar que haya un elemento en la colección. Por lo tanto, podemos eliminar ese código.

Por último, vamos a user jQuery para obtener el valor seleccionado del select. En jQuery podemos hacerlo directamente con $(select).val(), suponiendo que select contiene el elemento DOM correspondiente. Personalmente, prefiero encontrar primero el option que está seleccionado. Para ello, usaremos una pseudoclase CSS :selected. Además, ya que estamos, compararemos con un más correcto ===.

Finalmente el código termina así:

Y el fiddle correspondiente nos permite jugar con el código y observar cómo el elemento conserva el display: block.

No tan deprisa.

Al principio os prometí ver qué pasaba con ese código extra que le había metido al fiddle.

La primera parte son dos simples líneas de código que se parecen a esto.

Otra forma de escribirlo, que nos da más pistas de qué sucede, es:

En nuestro código referenciamos elementos de html que pueden no existir cuando el código se ejecuta. Si esto pasa, nuestro código puede, en el mejor de los casos, no funcionar. Para evitar esto, usamos la función $ (otra vez nos encontramos, vieja amiga) pasándole una función que jQuery ejecutará cuando el documento este listo (document y ready, fácil).

¿Qué pasa con la otra parte? Es un poco más complicada de explicar y no voy a explicar exactamente qué sucede con los eventos en jQuery, eso será para otro momento. Veamos el código:

Básicamente, le estamos diciendo a jQuery que, cada vez que un elemento de $('select') cambie (change en inglés), debe llamar a la siguiente función. Para terminar de entenderlo, debemos saber que jQuery hará que la variable this se refiera al select correspondiente. ¿Por qué decir ‘el correspondiente’ cuando sólo hay uno? Pues porque $('select') podría devolver una colección de más de un elemento, en cuyo caso añadiría el callback (así es como llamamos a la función que le pasamos) al evento change de cada uno de los elementos.

Notas finales.

No hemos reducido mucho el código (LoC nunca ha sido un buen indicador de la calidad del código), pero a cambio hemos separado nuestro código del diseño. Si tuviera que hacer ese código, probablemente lo haría de forma diferente (¡Qué coño porras! ¡Lo he escrito hace menos de un mes! ¡Diferente!), pero no está del todo mal.

Aprendiendo jQuery con la web del Senado, I

Notas previas.

En primer lugar, agradecer a los desarrolladores que han trabajado duramente en funciones.js y en aquellos que no se han molestado en pasarlo por un minimizador de código.

Se recomienda leer antes el artículo de Javier Ramírez Los problemas del desarrollo web en España resumidos en senado.es.

El código está disponible en este gist.

Durante esta serie de artículos nos olvidaremos de que todas las funciones son declaradas en el ambiente global.

El problema del peso.

 

Antes de ponernos con jQuery, veamos un poco cómo está hecho el archivo. El archivo pesa unos 45KB (según me chiva ls -lh) y tiene unas 1313 líneas (esto, chivado por wc -l). Lo primero que intento es ver cómo está el código. Para ello, usamos alguna herramienta como jslint o jshint. En este último caso, si pegamos el código y pulsamos en Lint, nos devolverá una lista con 50 errores, añadiendo un último error indicando que ha escaneado el 23% del código y ha parado porque ha encontrado demasiados errores.

Una vez pasado por jsHint, decidi pasarlo por el compilador de Google closure, para minimizarlo un poco. Al fin y al cabo, un vistazo rápido permite ver la ingente cantidad de comentarios que hay en el archivo. Está bien que haya muchos comentarios, lo único que me preocupa es:

  1. Que los han puesto en producción (gracias, Rocío, por sustituir los días escritos a fuego).
  2. Que haya código comentado, también en producción.

De ahí que me preguntase cuánto se ahorraría minimizando de la forma más básica el código. Para ello, he usado el compilador de Google closure en dos versiones. En la primera, he usado los parámetros por defecto; y en la segunda, he pasado la opción --compilation_level ADVANCED_OPTIMIZATIONS. Echando mano otra vez de ls -lh, vemos que con los parámetros por defecto, el archivo resultante pesa 22KB, mientras que usando las optimizaciones avanzadas, el tamaño baja hasta 15KB. El archivo se queda, respectivamente, en un 50% y un 25% del tamaño original. Todo esto, realizado en cinco minutos, sin mayores ajustes de la herramienta. Cabe destacar que closure genera 1 y 6 warnings, todos ellos referidos al uso de la variable this, excepto uno, que se trata de un código que no se ejecutará nunca (ya veremos qué).

cargar_atr_destacados

La primera función que estudiaremos es, justamente la primera del archivo, la función cargar_atr_destacados. Dicha función se encuentra en este gist. Empecemos a tocar las pelotas aprender un poco.

En primer lugar, suelo preferir declarar las funciones de la forma var cargar_atr_destacados = function() {};, pero, mientras se entiendan las diferencias, me da un poco igual.

Dentro de la función, vemos que estamos ejecutando realmente el mismo código para $('#img_destacados1 img'), $('#img_destacados2 img'), $('#img_destacados3 img'), $('#img_destacados4 img') y $('#img_destacados5 img'). ¿Pesado de leer, ¿eh? ¡Pues imagínate lo pesado que debe ser de mantener! Por eso, antes de estudiar lo que hace, vamos a convertirlo, sin modificarlo mucho, en un bucle. El resultado es el siguiente

No está mucho mejor, pero al menos hemos reducido el número de líneas a casi un 25%.

Empecemos a ver qué hace el código. Todos esos signos de dólar ($) es como se llama comúnmente a la función de jQuery. Dicha función sirve para muchas (pero muchas de verdad, ¿eh?) cosas, entre ellas seleccionar elementos dado un selector de CSS. En este caso estamos seleccionando las etiquetas img dentro de los elementos cuyo id es img_destacados seguidos de un número del 1 al 5. Puesto que hay varias imágenes que cumplen dicha propiedad, el resultado es un array o vector de elementos.

Por otra parte, vemos muchas llamadas al método eq. Dicho método, como podemos observar en la documentación oficial, sirve para seleccionar un elemento específico dentro del array. Por ejemplo, eq(0) selecciona el primer elemento, eq(1) el segundo, etc. Ahora veamos porqué el uso del método anterior es innecesario.

¿Que lo geque y lo seque?

El método attr de jQuery se puede invocar de distintas formas. Si lo invocamos con un sólo argumento, como en la tercera línea del código anterior, tomará dicho parámetro como el nombre del atributo a devolver. Puesto que lo estamos llamando en una colección, podríamos pensar que nos devolverá un array de valores, pero en realidad nos devolverá sólo el valor del primer elemento. A esta forma de llamarlo lo llamaremos getter, porque nos devuelve un valor.

Por otra parte, podemos llamarlo como un setter. Para ello, le daremos dos valores, el nombre del atributo y el valor a tomar. Podríamos pensar que entonces sólo dará el valor pasado al primer objeto; al fin y al cabo, es el valor que nos devolvía. Sin embargo, dará el valor a todos los elementos de la colección. Hay una segunda y tercera forma de usarlo como setter, pero os podéis mirar la documentación para esos casos.

En general, todas las funciones de jQuery que puedan ser usadas como getter y como setter tienen el mismo comportamiento: si están siendo usadas como getter devuelven el valor del primer elemento de la colección; si están siendo usadas como setter, actualizarán el valor de todos los elementos de la colección. Teniendo en cuenta lo que hemos aprendido en el párrafo anterior, podemos refactorizar nuestro código para que quede así:

Si además sabemos que podemos pasar un objeto con todos los pares claves-valor que queremos modificar en una sola llamada, el código es:

Grabado a fuego.

Pero aún tenemos ese for ahí que no me gusta mucho, pues realmente estamos harcodeando o, como diría nuestra amiga Rocío, grabando a fuego, la cantidad de elementos a modificar. Para ello, nos fijamos en que cada grupo de imágenes está metido dentro de un div con clase mod_destacados diferentes entre sí. Además, un rápido vistazo nos permite ver que no hay más div.mod_destacados que grupos de imágenes, si participásemos en el grupo de desarrollo estaría bien que nos aseguráramos de esto o, mejor, añadir una clase estilo js-mod_destacado. Por lo tanto, lo que haremos será buscar todos los div con clase mod_destacados y dentro de cada uno de ellos modificar los attributos alt y title de las imágenes. El selector para los div es tan fácil como $('.mod_destacados'). Veamos el código completo y después lo explicamos:

Para entender este último código, sólo necesitamos aprender lo que hace la función each y la función find.

Llamaremos a la función each siempre sobre una colección jQuery y le pasaremos como parámetro una función. jQuery llamará dicha función, una vez por cada elemento de la colección, con el índice de dicho elemento dentro de la colección actual, y el elemento en sí. Además, dentro de la función parámetro, this se referirá al elemento correspondiente de la colección.

¿Os acordáis de que os comenté que la función $ valía para todo? Pues bien, en la línea 3 podéis ver que la llamamos con un único parámetro, this. Éste no es un selector por lo que no sabemos aún qué hace. Antes llamábamos a $ con un selector CSS y nos devolvía un objeto jQuery que envolvía a la colección; ahora que le pasamos un elemento del DOM, ¿qué devuelve? La respuesta es muy simple: nos devuelvo un objeto jQuery que envuelve a dicho elemento. De esta forma, podemos usar todos las funciones de jQuery en él. Por ejemplo, en este caso, usamos la función find.

La función find(selector) es muy similar a $ sólo que restringe la búsqueda a los nodos de la colección padre. Así $(this).find('img') busca todas las etiquetas imágenes dentro de $(this), es decir, entre sus nodos hijos.

De esta forma, sabiendo muy poquito de jQuery, hemos reducido un script de 37 líneas a sólo 7. Además, si aumentamos el número de imágenes, o lo reducimos, nuestro script seguirá funcionando.

Notas finales.

Como último comentario, decir que actualmente se favorece el uso de prop frente a attr en jQuery. El problema con la web del senado es que están usando jQuery 1.3.2

La versión de jQuery usada en senado.es es 1.3.2
La versión de jQuery usada en senado.es es 1.3.2

 

Un vistazo rápido a github nos permite comprobar que esa versión es de hace 4 años.

Adding organization repos to Travis-CI: Part I

It was a nice FridayPorras and I were at the BeBanjOffice and  we were working on adding organization support to Travis-CI.

First, we needed to find where the user repos were being fetch. Said and done, we found that travis is using the ServiceHookController to ask the server for repos (and to update them too, but don’t hurry, we’ll get there in part II). The controller was using the github_repositories method in the User model. Finally, we arrived to Travis::GithubApi, where all our questions found answers.

repositories_for_user just relied on Octokit#repositories for getting the repos, so we added all the code after the plus sign. You might think that this code lacks the proper security, is wrong and that it shouldn’t be there (and damn it, you’re right!) but there is no easy way to retrieve only the repos where the user has admin privileges (we wasted hours on this and a quick message to Github confirmed it).  Basically, it asks for all organizations for the given user (beware! You need to make your membership public, otherwise it won’t work) and then flat_map them to the repos in the given organization (whether the user can administrate them or not).

Later, the each block was added so we could know whether the repo belongs to the user or to an organization.

Stop! Hammertime!

We needed a way to let the user know that a repo actually belongs to an organization, so we added that info to the template (that {{#if content.organization_name}} is ours :D) and added some style so it could look this awesome:

Travis CI - Distributed build platform for the open source community

We had some tough time trying to get it vertically centered, but after realizing that Github has its tags the same way as we do, we stop trying to fix it. And they still look awesome.

More coming in part II.

The Essential Guide to HTML5: a review

After reading this book I have some encountered feelings about it: on the one hand the content is correct, everything I tested worked fine, etc but on the other hand I really find annoying the form it is presented.

When I started reading, I expected to find more about CSS3 (a topic almost not covered in the book) and less Javascript, but since this is only an expectation, I’ll try my best so it doesn’t affect this review.

Since I wrote before, the content is correct. Covers a huge part of the new apis, the examples usedare not too complex yet interesting and it is not hard to follow. Without any doubt, the form code snippets are displayed. The code is displayed in a two-column table (one for code, one for comments) and each line (each line!) is commented. Seriously, I’ve seen the <html> line commented!

And even if the content is good, the table issue makes it really hard to read if you are a medium-experienced programmer. These are my encountered feelings: good content, not that good layout.

Creating a blur effect with rinzelight.

After releasing rinzelight 0.0.3, I wondered how hard addinga blur effect would be. So I started implementing it.

We are going to do two 1D blur. In first place, open a repl and start emacs (or vim). Use rinzelight.image for reading northern-lights.jpg

First, let’s start creating a blur-kernel function with two parameters, width and sigma. Rinzelight lacks of a kernel-rank constant, so let’s add it. Open src/rinzelight/constants and add the following line to the end:

We get a horizontal kernel, which we will apply twice, one horizontally and one vertically. For getting a vertical kernel, we write one final function called transpose-horizontal-kernel:

And now, we are ready to write the blur effect:

And this is the result of a (blur (read-image "samples/northern-lights.jpg") 5 1.5 repeat-op rendering-quality):

(blur img 5 1.5 repeat-op rendering-quality)
(blur img 5 1.5 repeat-op rendering-quality)

And that's it!

Introducing rinzelight 0.0.2

I started writing rinzelight long time ago. Exactly, I started on February. Sadly, since I wasn’t getting a few points about Clojure, I stopped working on it twenty days after for half a year.

But do not let me digress. Rinzelight is finally released! Actually, rinzelight 0.0.2 is released! But let me introduce you to rinzelight.

Opening an image.

Just use rinzelight.image namespace. Then, just provide read-image of a filepath or an InputStream. Just like this:

A hash?

Yes. Four fields: image, format, width and height.

It’s an image. Let me see it!

Command your repl to display-image.

What about saving it?

The correct spell is write-image. Just give it an image and an uri.

I want to change an image’s nature.

If you want to, you can. Just look for namespaces under rinzelight.effects. Lookup tables and affine transforms are already available. There are even map-image and map-pixel-location functions. If you want to use map-pixel-location, take a look at rinzelight.effects.helper-functions for a helping hand.

What about a few examples?

I hide them under examples. They are a bit obfuscated using criterium for benchmarking, but they are not hard to understand. For running them, use lein run. They’ll take a bit, since I use them as benchmarks.