27 May 2015, 09:30

Around the Web - May 2015



  • A day at Devoxx France (in French) : a summary from Xebia about the Devoxx France conference (Java based but not only) and their findings.
  • Mix-IT Web was in Lyon in April, and the M6 Web tech team wrote a feedback in French - Day 1 - Day 2 ; it deals both with tech and agile topics.




  • The Apple Watch: User-Experience Appraisal : a review on how you app should behave (or not behave) on the new Apple IWatch ; transition with iPhone is also managed and the way to dealt with content and how you should manage your interactions.

Web performance

NoSQL, ElasticSearch

  • Elastic released a new (commercial) plugin for ElasticSearch caled "Watcher" and which aims to raise "alerts" when some events occured and according to some conditions, it may generate an action (email being sent, interaction with another system, etc).
  • M6 Web Tech team published a video (in French) about an introduction to Cassandra.


  • Indoor geolocation technology : article (in French) about indoor geolocation technology, describing and comparing Wifi vs NFC vs Beacon vs Magnetic field to provide geolocation.

25 Mar 2015, 09:30

Around the Web - March 2015


Responsive Web Design (RWD)


  • This API is so Fetching : fetch API is to be used for asynchronous actions and is to be more resilient than a XHR (ie ajax) call. Some exemples are given in the blog post ; it can be used from Firefox 39 and Chrome 42 (currently in dev status) but a Fetch Polyfill exists to start using this API from now.
  • CSS Reference which introduces itself as an extensive CSS reference with all the important properties and info to learn CSS from the basics ; this article gives a more introduction on its purpose and how to use it.
  • Meteor, develop faster than a rocket (in French) : an introduction to Meteor  a full stack and isomorphic javascript framework in which you use Javascript both on client and server side. It also uses MongoDB (NoSQL Document Oriented database & schemaless) to store data and it's based on Node.JS. A second article will show how you can create a mobile app easily.


  • Your job is not to write code : Engineers' job is not to write code, Project Managers' job is not to manage project and so on. Our job is to make a better product.
  • A Bug Hero to fight against bug invasion (in French): in an agile team, in each sprint, a developper is commited to do the 1st level support, fix bug and manage incident to avoid disturbing the whole team and sacrifice the sprint. If no bugs, developer is aimed to fix small tasks that are not on the critical path for the sprint dlivery. Interesting both for the disturbing management effect and as it enforces developpers to have a global knowledge of the system, not only his own part.  


  • Understanding SQL's null : because querying null is not as easy as it may be and also null may not mean null in the way you expect.
  • PoWa (Postgresql Workload Analyser), released as a 2.0 version, provides a better (from what it is said, not tested) monitoring and performance tools on your Postgres 9.4 cluster.


Compose is a way of defining and running multi-container distributed applications with Docker. Back in December we opened up its design to the community. Based on the feedback from that, Compose will be based on Fig, a tool for running development environments with Docker.

Machine takes you from “zero-to-Docker” with a single command. It lets you easily deploy Docker Engines on your computer, on cloud providers, and in your own data center

Swarm is native clustering for Docker containers. It pools together several Docker Engines into a single, virtual host. Point a Docker client or third party tool (e.g., Compose, Dokku, Shipyard, Jenkins, the Docker client, etc.) at Swarm and it will transparently scale to multiple hosts. A beta version of Swarm is now available, and we’re working on integrations with Amazon Web Services, IBM Bluemix, Joyent, Kubernetes, Mesos, and Microsoft Azure.

  • so now you can orchestrate all your process from zero to production using docker (based) solutions. Even if some products are still in beta so far, a very interesting move !


23 Apr 2014, 09:30

Web Roundup - 23/4

This blog is not (yet) dead ; some links :

  • Internet Explorer Web Platform Status and Roadmap : To know if/when some features of HTML5/CSS3/JS have been implemented in Internet Explorer from IE9 to "Under Consideration" or "Not currently planned"
  • If you want to build Windows 8 apps in JS (instead of .net technologies) but also more general UI in HTML/CSS/JS (more sceptical on this one), you may be interested by WinJS, recently opensourced by Microsoft. You can even try it first and then look at the code/project.
  • HTML5 Security Cheat sheet : some security points to have in mind
  • WTF, HTML and CSS? : Reasons HTML and CSS might make you say what the fuck. A curated list of commonly frustrating HTML and CSS quandaries, miscues, and dilemmas.
  • A "Should I use" in French about some ergonomic pitfalls like caroussel, intrusive pop-in, fixed headers/footers, etc with samples. Still work in progress but with some good examples.

Till next time !

15 Jan 2014, 09:30

Frontend Ops
A brilliant article was published mid June 2013 under the title Front-End Ops : by itself, there is nothing new but I really like it because it makes a smart synthesis/wrap-up on some "trends" and the requirement to improve the maturity on frontend side. Below a summary with some inline comments.

Backend is (or should be) quite mature. Even if there are still a lot of things to do, the principles and the tools are there to manage build and deployment process but also production follow-up and performance monitoring. It's just about implementing theses concepts and tools and/or applying them on your projects. We'll suppose now that your backend application is working fine or at least in a decent way.

So what about frontend side (ie what is in the browser ?) ?

A few facts about current situation :
  • More than 80% of the time used to render a page is made on browser side ; so the counterpart is that 20% is made on backend side.
  • Logic is more and more on client side with the rich UI we tend to have
  • When you look at Amazon, a 1% increase in revenue for every 100ms of improved performance.
  • You start to notice the application/web site is slow from a little less than 1 second

So don't you think it's time to invest on frontend side and stop considering that frontend code is just pushed/generated from backend side ?

It's not about focusing on performance. Performance is just a mean to deliver a good user experience and allow end users to use your service/site.

As such, Frontend developpers is not just about putting some HTML/CSS/JS alltogether and manage browser (in)compatibilities. It's even less about backend developers to generate the UI based on some auto-generated code derivated from some models and Java code. It is about to know/understand HTTP principles, how browsers render pages, what to do on backend side to improve frontend performance, etc. It's about going beyond the code to embrace the whole situation/context and deliver the expected UX.

How do we achieve this (non exhaustive list) ?

  • 2013 was the rise of the "frontend tooling chain" with the coming of Bower, Grunt, Yeoman, etc.
  • For years now we have performance tools like Webpage Test, YSlow, PageSpeed, etc
  • Firefox and Chrome DevTools are here for years and were significantly improved over time ; not to mention Firebug,
  • ...
So tools are (almost) there and still need to mature for some of them.

A few more are required :
  • Time to make product owner aware of this challenge and what it costs them not to do it. You don't need to be an Amazon to have benefits to implement it. As long as you have users, you need to provide them a good user exerience if you want your product to be used.
  • Time to make developper aware of this so that they change their habits and embrace this new field.

To conclude with, 3 quotes from the article I really like :

Frontend dev make your apps a reality for end users :

A front-end operations engineer would own external performance. They would be critical of new HTTP requests, and they would constantly be measuring file size and page-load time. [...] . They own everything past the functionality. They are the bridge between an application’s intent and an application’s reality.

Beyond performance, error management and monitoring, it's about providing a resilient system :

A front-end operations engineer would be very friendly with the quality assurance team, and they would make sure that “performance” is a test that comes up green. They’d monitor client-side errors and get alerts when things go wrong. They’d make sure that migrations to new versions of the application go smoothly, and they’d keep all external and internal dependencies up to date, secure and stable. They are the gatekeepers of the application

It's about providing a service to the users and make it using the application on a long term basis :

Not every company or team can afford this person, but even if someone puts on the “front-end operations” hat for one day a week and prioritizes their work accordingly, users win. It doesn’t matter how many features you have or how sexy your features are if they aren’t delivered to the user quickly, with ease, and then heavily monitored. Front-end operations engineers are the enablers of long-term progress.

So I wish it would be part of my job (and yours too) for 2014...