Poster & Pattern
Workshop avec Julien Priez
Séances 1 & 2
https://www.behance.net/julienpriez
https://instagram.com/boogypaper/
Details… Piece inspired by the great master @kab101ism / Pieza inspirada en el gran maestro @kab101ism #legzletter #calligraphy #sketch #kab101 #practice
Suite de mes aventures dans le nord et de mes portraits de Ch’tis. Aujourd’hui, Jean-François Caron, maire de Loos-en-Gohelle. La trajectoire de cette ville et de ses habitants est passionnante. D’une soit-disant no go zones du Nord, elle est devenue un fleuron du développement durable et de la participation citoyenne…
« L’exploitation des mines – et leur fermeture - ont eu des conséquences terribles sur Loos. Des conséquences environnementales, sociales et économiques. Plus d’arbres, des sols pollués, un chômage de 14%, un paternalisme très marqué chez les anciens patrons. Ce paternalisme empêchait les mineurs d’être maîtres de leur destin. Et puis, une piètre image de la région dans les médias. Quand les journalistes viennent ici, ils sont presque embêtés s’il fait beau. Ça ne colle pas à l’image qu’ils ont et qu’ils veulent donner du Nord. Ajoutez à cela une banderole «Pédophiles, chômeurs, consanguins : bienvenue chez les Ch'tis !» brandie au Stade de France. Vous imaginez la perception que pouvaient avoir les habitants d’eux-mêmes… Tout était très dégradé ! Il a fallu faire un travail de mémoire très important pour leur redonner confiance afin qu’ils puissent à nouveau regarder vers l’avenir. Et puis, personnellement, j’ai dû faire face à de nombreuses critiques. Un maire écolo au pays des gueules noires, c’était une erreur, ici. Alors, on a remis les personnes au cœur du fonctionnement et des projets de la ville. En ayant à nouveau confiance en eux, les habitants sont devenus des habitants acteurs. Ce principe d’habitants acteurs repose sur l’intelligence collective, sur le fait qu’on les reconnaisse pour ce qu’ils sont et sur la démocratie participative. Tout est co-produit avec les Loossois. Tout cela démultiplie l’action locale. On a développé des outils pour rendre les habitants responsables. Par exemple, on a un programme appelé fifty-fifty : on fournit les moyens aux habitants qui veulent changer leur cadre de vie, mais c’est eux qui réalisent les actions. On leur fournit la peinture, et c’est eux qui peignent le mur. Une fois ces fondations de confiance et de responsabilité posées, on peut envisager l’avenir autrement. Quand vous venez à Loos, vous mettez les pieds dans une ville résiliente. On mise beaucoup sur l’éco-construction, les circuits courts, le tourisme durable, l’énergie solaire. Nous sommes Ville pilote du Développement durable. Mais pour que le développement durable parle aux habitants, il faut que ces nouveaux modèles aient un lien avec la vraie vie. Le rapport qu’ont les gens avec leur ville, c’est via leur trottoir, leurs enfants et leur voiture. Alors, certes, un maire doit avoir un discours volontariste et visionnaire, mais il doit travailler sur le concret. Avec toutes ces actions, Loos et ses habitants peuvent à présent se projeter vers l’avenir. Nous travaillons beaucoup sur le principe de Troisième révolution industrielle qui peut être une clé de la survie des écosystèmes et donc de l'humanité. Le collectif est à nouveau de qualité dans notre ville. Nous permettons la singularité et revendiquons le droit à l’erreur. Mais l’être humain évolue considérablement en fonction du contexte dans lequel il vit. Ayons à l’esprit que nous ne sommes qu’à quelques kilomètres d’Hénin-Beaumont, où les choses se passent vraiment différemment… » Jean-François, 58 ans
Pour en savoir plus sur les actions de Loos-en-Gohelle. Et si le principe de Troisième Révolution industrielle vous intéresse.
Merci aux habitants du Nord pour leur accueil en tout cas! Le prochain portrait sera parisien !
Brad Bird told The McKinsey Quarterly in 2008, “The Incredibles was everything that computer-generated animation had trouble doing. It had human characters. It had hair. It had fire. It had a massive number of sets. The technical team took one look and thought, ‘This will take ten years and cost $500 million. How are we possibly going to do this?’
“So I said, ‘Give us the black sheep. I want artists who are frustrated. I want ones who have another way of doing things that nobody’s listening to. Give us all the guys who are probably headed out the door’. A lot of them were malcontents because they saw different ways of doing things, but there was little opportunity to try them, since the established way was working very, very well.
“We gave the black sheep a chance to prove their theories, and we changed the way a number of things are done here (at Pixar). For less money per minute than was spent on the previous film, Finding Nemo, we did a movie that had three times the number of sets and had everything that was hard to do. All this because the heads of Pixar gave us leave to try crazy ideas. [x]
(Fact Source) Follow Ultrafacts for more facts
Follow Ultrafacts for more facts
Wow…this is awesome.
Fun fact: An artist named Patrick Acton also created a replica of Hogwarts, but with 600,000 matchsticks held together with 15 gallons of carpenter’s wood glue.
Automated testing in Yahoo Mail
Background:
We blogged about the evolution of Yahoo Mail to React + Flux and Node.js. It is important to focus on building a strong foundation when you are building a new platform and having a robust test infrastructure is a big part of the foundation. Yahoo Mail today relies on automated testing on our Continuous Integration pipeline before we deploy changes to production. We run Cucumber and Waitr-Webdriver based functional tests run across IE, Chrome and Firefox using selenium to certify our builds. Building this infrastructure gave us a lot of insight into the challenges of doing automated testing at the scale of Yahoo Mail.
Our requirements for a robust automated test infrastructure are as follows
- Comprehensive
- Fast and consistent
- Easy to maintain
- Shorter learning curve
All engineers are accountable for quality of the product and maintaining the infrastructure. So the infrastructure should be easy to understand. We want to make sure that the tests are comprehensive enough so that it gives us the confidence to push the code everyday without human intervention and we should have the ability to run the tests multiple times a day.
There are different levels and capabilities of tests we could have invested in. Based on the above requirements, we chose to focus on the following types of tests
Unit Tests:
We have used multiple unit testing infrastructures in Mail in the past. So going by our experience, we arrived fairly quickly at our decision to use Mocha as our test framework, Karma as our test runner and Chai for assertion. We also decided to use Sinon to stub out external methods.
Functional Tests:
Now comes the interesting part. We knew that we needed to test UI thoroughly since there are chances of things breaking when code components start interacting with each other. No one can just rely on unit tests to determine whether the code will work as expected.
On the other hand, we had to be careful about what we actually end up testing as part of the functional test suite. In an application like mail, executing our tests on actual mail data could mean that the functional tests are actually executing as integration tests. It was important for us to call out this difference that functional tests should just test the functionality of the code written agnostic to the actual data. Working with actual data brings in dependencies to setup the account to a given initial state and also go over network to all our sub-systems every time. This can be time consuming and can potentially trigger false alarms.
We divided our functional tests into two categories
- Tests at Component Level
- Tests at App Level
Component level tests focused on functionally testing a component in isolation. We would pass different props and see if the component behaved as expected. React TestUtils with Karma and PhantomJS seemed like the way to go as it was fast and easy to write. We earlier blogged about our experience with using React TestUtils for this.
App level tests focused on launching the entire app in the browser and testing real user scenarios. For example, Marking a mail as read. The Mail backend and APIs have their own robust automated tests, so our focus was to test the functionality of the client. So we decided to stub our data request layer using Sinon and return responses that can execute all the code paths for the given functionality. This means our test runs are very fast, the tests are reliable and predictable.
Now for the choice of framework, we narrowed down to two options. First option was to use the already familiar Waitr Webdriver with Cucumber. We loved this because we can write true BDD styles tests with Cucumber. We had well integrated tooling around this like support for screen capture for failing tests and running tests in parallel. On the down side, not everyone was comfortable with the relaxed syntax of Ruby, there were plenty of hacks done to make sure the tests run consistently on Chrome, Firefox and IE.
The second option was to use Protractor. The biggest advantage Protractor brought to the table was that we would be doing development and tests in the same language, Javascript. This would eliminate learning curve for writing and debugging tests. Protractor also speeds up tests by avoiding the need for a lot of “sleeps” and “waits” in tests. We used chai-as-promised for asserting promises returned by Protractor. Even though Protractor was built for testing AngularJS applications, in reality it can be used for testing any web application. It had everything that you would expect from UI testing framework.
Based on the benefits we saw and the fact that other teams in Yahoo were also going with Protractor, we chose the second option. Since we had good experience with BDD, it was easy to set this up with Protractor in the future if needed.
Organizing Protractor tests:
A typical protractor test starts to get messy very soon with promise chains. We wanted our code to be readable and maintainable. So we started creating Page Objects for the different components of our app that eliminated duplication of code and made our test files to read more like business-like expressions. With page objects and support for adding stubs for API, our protractor test started looking like this
it('marks a conversation as read', function() {
var conversation;
testHelper.stub('ReadConversations', 'read_success');
conversation = page.conversationList.getConversation(1);
expect(conversation.isRead()).to.eventually.equal(false);
conversation.read();
expect(conversation.isRead()).to.eventually.equal(true);
});
Smoke and Integration Tests:
We chose to use the Protractor setup for writing smoke and integration tests as well. The only difference is that with Smoke and Integration tests we interact with actual mail data instead of using stubs. Smoke tests comprise of a collection of tests just to make sure application is able to launch and the core flows work. A core flow could be something as simple as whether clicking on compose and sending a message works.
Integration tests are the meanest, most intensive tests we want to run on actual data before the code goes to production. Using protractor for functional, smoke and integration tests meant reusing the same infrastructure and same code for running all the tests (e.g. page objects and specs)
Running tests in the pipeline
Having a clear separation between the various tests meant we can now configure the various stages in the automation pipeline to run the test suites. The unit tests are the lowest level tests we want to run to make sure the code units are all working as expected. We want these to be completed within 5 minutes. The functional tests make sure that the components work well together. Smoke is a quick sanity check that nothing major is broken and the Integration tests are the true gate keepers for end to end quality.
On every pull request, we would run all unit tests, functional tests and smoke tests. That gave us high confidence whenever any code is merged to master, we are keeping the quality bar high and at the same time having them finished really quickly.
Every 3 hours, we build a production candidate from master. We put this build through all the tests including integration tests to make sure that the package is completely certified end to end.
The setup also allows for deploying individual components separately because we can now pick and choose the test suite we want to run, either the entire functional test suite or just the functional tests for the given component. We also have strict code coverage thresholds, application metric checks, payload size checks, code style ( lint ) checks etc on every build before its deployed to production.
We are overall excited to see things fall into place. We have many more challenges we need to overcome. We will do a separate blog post for a deep dive into our protractor setup where we will talk about page objects, writing synchronous code, stubbing and failing the test on js exceptions
Ankit Shah (@ankitshah2787) - Yahoo Mail Engineer