In order to view this website properly and use all its capabilities, please activate JavaScript.
Here are the instructions how to enable JavaScript in your web browser. under the hood

no need to hit F12 , just look at the following:

logos of frameworks, applications and technologies used on

Into the cloud with Rails 4

The use of Ruby on Rails on was a premiere for me and I have to acknowledge that it took me some months to be familiar with the framework. However, for a developer accustomed to JavaScript and Php, Rails offers many advantages: read/write strength of Ruby compared to JS or Php, friendlier database handling through migrations, handy way to deal with models' implementations and validations... Rails also offers an awesome bridge between views and models. I might cite url helpers, form builders (on a single instance or a collection) and nested attributes (which facilitates parameters management through ActiveRecord's associations), but there are many more.

The asset pipeline offers a great way to organize assets, by filetype or by directory (/lib, /vendor). I divided my JS assets into various scripts, specifying those which as to be loaded at some specific times (eg 'domready') or for specific pages.

Most of my work on Rails goes on the back office part of this website, with the implementation of User and Post models, handled by the adequate controllers. Login mechanisms, security layers and session management have been important parts of this development. Post management implies creation, update or deletion, depending on user privileges. I developed a DraftPost model, which acts as an interface for Post's write access, storing modifications until the administrator validates them for publication.

HAML naturally comes as the most appropriate templating engine as it offers simplicity for views' editing (except for heavily nested and content oriented markup as noted by Chris Eppstein). Besides its simplicity, HAML fits with Scss files, by mirroring elements' ids or classes.

Accustomed to classic web hosting (all in one hosting plan, no scalability), allowed me to dive into cloud architecture. From a developer point of view, Heroku (and others PaaS) are perfect tools, Git oriented, totally scalable and versionable. Along with Heroku comes Amazon S3 for a handy management of images assets, especially when dealing with responsive images, which implies multiple instances of the same image.

Posts: Find me if you can

I'm not an advocate of using Categories and Tags for ordering blogs' posts. On I offer to users three access points to posts: by date, popularity or via global search.

Popularity metric is based on a homemade algorithm which associates the number of times a post is seen and its amount of comments. The retrieving of each page viewing rate is done through a Rack middleware. To get posts' comments, I used the Httparty gem and I implemented a Ruby class to send HTTP requests against Disqus servers. Send requests for comments and compute popularity metric are frequent and heavy processes, as they act on each post. With optimization in mind and willing to alleviate HTTP server's load, I put them in DelayedJob's jobs, running on a daily and weekly basis.

Elasticsearch (and its Ruby implementation, (Re)Tire) is the hipster choice in the land of search engines. First, I had to understand the Elasticsearch API and its components, namely analyzers, tokenizers and filters. I tested the JSON Web API on a local elasticsearch server, which has greatly improved my understanding of the system (notably the difference between indexing and searching). Then, supported by the Tire API, I implemented the appropriate JSON representation of my Post model and an adequate mapping. At last, I used the Tire DSL in the 'Search' page, looking for search keywords in Posts' titles and summaries (authors' names too). Order and highlight result sets are then done in no more than two Tire's statements.

Find appropriate content is one thing, display it to user is another. Hopefully, the awesome gem Kaminari makes pagination a child's play, and, cherry on the cake, perfectly works with Tire's search results.

Foundation 4 and HTML5 is responsive, as it offers three different interfaces. One for smartphones (screen resolution smaller than 768px), one for tablets (screen lower than 1100px) and one for large screen devices (wider than 1100px). Among many advantages, one drawback of responsive design is that it introduces overhead in markups and stylesheets (bad for page speed). However, Google recommends the use of one responsive page instead of multiple ones, as one file is far easier to index than multiple ones.

I wanted that each post occupies all page width, with explanatory text and code extracts laid side by side, or stacked on top of each other on smaller screens (ie smartphones'). Thus, when time to pick a responsive framework came up, I had to choose between Twitter Bootstrap or Zurb Foundation.

Foundation 4 offers more flexibility when it comes to manage breakpoints and visibility classes. But the main point which made me choose Foundation is that the framework invites developers to code in a 'mobile first' way. Indeed, version 4 of the framework follows ideas and design principles of Luke Wroblewski.
Already familiar with Luke's ideas (through his book, Mobile First) and seduced by the various UI elements and icons sets offered by Foundation, I made my choice on this framework.

I tried to use on this website as many HTML5 markup as possible. Elements such as nav, hgroup or aside are a semantical boost for the web page. HTML5 sectioning elements, in the other hand, fit perfectly with Rails partials generation and inclusion. My implementation of the HTML5 markup was influenced by Mark Pilgrim's Dive into HTML5.

JavaScript and SVG

I will start this section with an advocacy: yes needs JavaScript to work properly, and most of its features are JS based.
I am aware it's against the recommendation of 'progressive enhancement'. I will argue that, among other things, JS offers scalability and bandwidth saving (through responsive images and SVG drawings or animations). Without JS, social activity on the website (comments with Disqus or social plugins) is greatly compromised. A workaround could have been to develop a pure HTML version, in case of JS deactivated. But spending time on this version meant losing time for the main one. It wasn't a good choice.

JS also resolves an issue inherent to images in responsive design. Without JS, small devices should be forced to load oversized images, causing a needless bandwidth overhead. With JS activated and the use of the picturefill polyfill, a device will request an image suitable for its resolution. This is especially true for Retina displays, which need double size pictures.

Along with the use of JS, I decided to place many SVG elements throughout the website. There are various interests:

  • inline SVGs are bandwidth savers.
  • by using an appropriate JS library, as svgjs or simply with CSS, SVGs can be duplicated and animated.
  • by considering SVGs which contain images (like those present on this page), SVG manipulation allows to create new canvases (visually new images) by combining images elements. Again, bandwidth performance.

Nevertheless it's worth to notice that SVG isn't present on all browsers, thus it's important to implement images fallbacks for critical SVG elements.

Unsurprisingly Modernizr detection is focused on SVG and touch features. On the basis of the current page and the features detected by Modernizr, the appropriate JS will be requested and evaluated. For example, the file svg_home.js, in charge of animating the home page, will be loaded only on the home page and if the user agent supports SVG.

Optimize Frontend

For I started to develop a lightweight JS DOM library, jArgon.
'What's the point?', you may say. Are jQuery and other JS libraries not good enough?
Actually many reasons come into play:

  • it's fun, as simple as that.
  • jQuery is awesome but to my mind it's a DSL which hides the native JS DOM API.
  • through coding I discovered tricks and secrets of the native DOM. On this point I highly recommend the reading of John Resig's Secrets of the JavaScript Ninja.
  • the importance of JS optimization and code convention: with respectively jsPerf and JSHint.
  • jArgon doesn't offer all jQuery's features, and it doesn't need to. Indeed as often as possible I try to use the native JS DOM API. This leads to a shortened file, which means more performance for download and evaluation.

Technically speaking, jArgon is close to jQuery. It follows the decorator pattern and allows to handle DOM elements in the classic way:

  • querySelectorAll
  • query by attributes/classes
  • check for element's name, classes or attributes
  • toggle classes

Jenkins at your service

Website's development has been spread out on 4 milestones, for a total of 17 features. Each feature is a Git branch and once completed, this feature is pushed on my own Continuous Integration server, based on Jenkins.
Indeed my personal server hosts the main Git repository and a Jenkins daemon which will poll the repository for updates. If the repository changes, a serie of Jenkins jobs are trigered. It took me weeks to understand and configure Jenkins and all third parties programs, but it was worthwhile. The following is a simplified view of the two jobs chains at work on Jenkins (Jenkins ensures CI on Rails and JS codes).

Jenkins is configured to perform two integration threads. The upper thread covers Rails code, the lower thread JavaScript code. Each step on a thread is a job.

Each job will run in the context of a Rails application. Thus, configure Jenkins to maintain the state of the application between each jobs has been primordial and has involved some vanilla bash scripting. A job is described by a sequence of bash statements, which will create a bunch of new assets, the so-called 'build'. A build might be marked as 'success' or 'failure'.
For example, if the 'unit tests and code coverage' job manage to launch Rspec's test files and generate the appropriate reports, it should be a 'success'. The reports are then proposed to user discretion. A failed job stops the chain.

CI server offers numerous advantages. First, the whole bunch of Rspec's unit tests are done on another machine than the one used for development. Second, integration tests (Cucumber) can be parameterized to run on various browsers. On this point I managed to interface Jenkins with Firefox (via selenium web driver) and Chrome (through capybara-webkit).
Last but not least, long tasks, as pushing the application slug on Heroku or generate documentation are done by the CI server.

Next are snapshots of the Jenkins interface during development of

From top to bottom: an overview of the jobs on Jenkins' home page, detail of the job which ensures Rails' unit tests (note the two successful builds) and a detail of Rspec's test results for the User model.

Once Jenkins' infrastructure in place, there are still tests to be written...

Rspec and FactoryGirl are used to test critical features of the website, mainly users and privileges management. Concerning code coverage, SimpleCov perfectly fits with Rspec, as its coverage reports are created each time Rspec terminates.
On another hand, Cucumber's features are built to test REST actions which depend on user's profile (ie simple visitor, authenticated user or administrator).

Finally I wrote a Qunit test file to validate jArgon against the most common browsers on the market. As a result, jArgon is doing well under Firefox, Chrome, Safari, Android Browser and Internet Explorer (version 7 and above). For more infos on those tests, feel free to have a look at jArgon's Git repository.

Personal details

Still reading? Nice... Now a few words about my professional background.

I validated a Master's degree in Pictures and Sounds Systems Engineering in 2010. This led me to work as a web developer for a software manufacturer in Toulouse (South-West of France), specialized in software and web solutions for handling media assets in TV Channels.
I then moved to Paris in the spring of 2011. I worked as a JavaScript developer for an IPTV manufacturer. Along with developing knowledge in vanilla JavaScript (code embedded on Set Top Boxes), I also improved my skills in web development and integration, as I was in charge of maintaining the firm's technical website.
In 2012, wishing to be specialized in web development, I got a consultant position, which led me to work on the reworking of a video sharing website and to develop a video player based on the HTML5 video element.

As my consultant agency wasn't able to validate my contract, I decided to dedicate the year 2013 in learning Ruby on Rails, website security, project management and enhance my JavaScript skills. I put all this brand new expertise into practice by designing and developing

Last but not least I would like to thank my family for their financial and moral support during this key period of my professional career. Thanks guys!

Have some feedback concerning this website, want to discuss a particular topic or just like to say 'Hello!' ?
Below are an assortment of links that come in handy:

Latest See all →

Parallax scrolling: why a fixed background?

This post explains the use of a fixed background-image in parallax scrolling. To do so I review the visual concepts behind parallax and illustrate it with the Skrollr library and a few lines of Scss.

Building an audio player with CSS Flexbox and JavaScript Promises

A step by step tutorial to learn how to build an HTML5 audio player from scratch, focused on:

  • the use of CSS Flexbox for a simple responsive layout,
  • an implementation of the Mediator pattern in JavaScript to develop a maintainable player,
  • the use of Promises to simplify callbacks management

About is a blog focused on JavaScript, HTML5 and Ruby on Rails, offering tutorials and best practices, from intermediate to advanced.
Posts are structured around code snippets and out of the box examples, featuring various topics, from abstract to concrete ones (like performance or HTML5 features).
Source codes are under Creative Commons licence but original graphics are copyrighted.

For a presentation of all techniques at play on, click here.


Liked what you've seen here?
If so you might be interested in the following: