Recruter c’est pas compliqué : on attend de quelqu’un·e des compétences —techniques principalement— avec un certain niveau d’aisance à les utiliser, à un certain prix.

Enfin, la maitrise, l’expérience et le salaire, c’est de l’ordre du “pas trop” ni du"pas assez". Ou des “pas comme ceci” et des “plutôt comme ça”. Les évidences.

Et si on cherchait plutôt à se… rencontrer ? C’est-à-dire à écrire une “proposition” plutôt qu’une “annonce”, à se poser des “questions” plutôt que d’attendre des “bonnes réponses”, à construire une confiance mutuelle plutôt que d’attendre des signes de conformité ?

Le recrutement serait déjà un espace-temps de travail commun : celui de se proposer une manière de faire équipe alors qu’on ne se connait pas, un premier échange sur nos manières de fonctionner et un “oui” explicite à l’amélioration de notre relation de travail comme objectif principal, comme co-responsabilité partagée.

Balade sensible dans les mots qu’on lit, qu’on écrit, qu’on copie, qu’on partage, qu’on modifie. Nous voyagerons les yeux fermés dans du code, des commentaires de code, des descriptions de code — informatique, législatif, moral, éthique. Et si un livre sur les semences paysannes avait autant à voir avec le commentaire d’une fonction qui retourne “Hello World” ? Et si ça devenait évident si on écoutait cet entremêlement pendant une dizaine de minutes.

On travaille, beaucoup, sans forcément savoir où va l’argent issu de notre temps travaillé, dans une entreprise qui ne nous appartient même pas. On en porte même parfois les t-shirts pour en faire la publicité ! Devenir freelance, c’est tout un autre monde : trouver un comptable, comprendre les histoires de bilan annuel… quelle plaie. Auto-entrepreneur·e, au moins ça coûte pas cher. Pas besoin de se prendre la tête avec les cotisations sécu et les points retraite ! (les quoi ?!)

En attendant, c’est le statu quo et rien ne bouge. Nous, c’est Maïtané et Thomas. On est dans des structures collectives/coopératives, et on travaille ensemble sur des projets avec d’autres collectifs. Ça implique des fois de l’argent, des fois pas. Mais souvent beaucoup de plaisir ! On avait envie de vous parler de modèles éthiques, qu’on a pratiqué avec un style sans C(e)SS(e) renouvelé : auto-entreprise, CAE, Scop, et même association de loi 1901. On a choisi et navigué en évaluant plusieurs niveaux de précarité, d’autonomie, plusieurs niveaux de rapport au temps, d’indépendance/accompagnement et plusieurs niveaux de solidarité. Si tu te dis “j’en ai marre”, “plus jamais seul·e” ou même “en collectif jamais plus”, et bien on va t’en boucher un border-radius !

• with Noémie Girard

À quoi ressemble une ville intelligente ?
Ce qu’on perçoit actuellement des ‘Smart Cities’ évoque de la captation massive de données sur les transports ou la qualité de l’air, mais il est difficile de voir au-delà de ces usages.
Comment réfléchir la place centrale de l’humain dans le futur de la ville ? Comment co-construire des stratégies territoriales résilientes et respectueuses des droits de tous ?

Nous proposons de présenter notre démarche de design itérative et de travail en équipe dans le cadre du projet de recherche-action Mind the Gaps.
Le projet étudie deux villes jumelées, Bristol (UK) et Bordeaux (FR), notamment sous l’angle des inégalités et de la qualité de vie.
Nous présenterons les enjeux et stratégies existantes des collectivités locales, ainsi que des initiatives pionnières de production de données citoyennes (Ideas for Change à Barcelone et The Bristol Approach).

Nous aborderons les questions clé du projet ainsi que notre méthodologie de documentation sur le terrain.

• with Claire Zuliani

Les entreprises libérées : ça a l’air trop bien. Si on s’écoutait, on casserait et on referait tout comme on l’entend. Doit-on forcément quitter les entreprises traditionnelles pour vivre et travailler heureu·x·se ? Ces injonctions à l’autonomie peuvent pourtant être mal vécues. Il est difficile de savoir si c’est une mode ou un vrai truc qui fait du bien.

Nous avons tou·te·s un besoin d’autonomie et des envies de cadre différents. D’ailleurs on cultive cet équilibre chacun·e à sa façon, entre des activités pro et perso, entre des activités rémunérées ou non, entre des activités à temps plein ou temps partiel. C’est quoi cet équilibre dont on a besoin et comment on le crée ? On pourrait déjà commencer par soi-même pour construire ce qui nous convient.

Claire et Thomas sont freelance et salarié plutôt satisfait·e de leur équilibre. Elles animeront ces réflexions sous forme d’un dialogue à deux. Elles inviteront le public à partager leurs expériences et ressentis tout au long du dialogue.

The usual way of writing a technical book is to open the Word or LibreOffice application, to write some content, to make a backup, to send it by email to the publisher and to deal with the feedbacks. And repeat.

However in 2018 we can do differently by using open formats like Asciidoc, by using version control to propagate changes, by using collaborative platforms like GitHub or GitLab to collate feedbacks in any form as well as transforming text and code into readable and interactive artefacts.

It gives us a unique opportunity to approach the whole process of writing in term of “content experience”, of “toolchain” and of “distribution”.

In the end, a “book” becomes a “writing format” as we can reuse the same pattern to manage any kind of “content” — articles, publications, essays, documentation — that we can transform in physical books, e-books, interactive web pages etc.

• with Antoine Fauchié

Le livre représente un idéal certain, même en 2017 : écrire un livre c’est bien, être publié c’est bien et ça fait de nous quelqu’un·e de bien. En tous cas vu de loin, ça a l’air bien mieux que d’écrire le README d’un projet ou sa documentation, un papier scientifique ou encore un rapport qu’on nous a demandé pour avant-hier. L’écriture d’un README et celle d’un livre sont-elles si différentes que ça ?

Du numérique au papier, du stylo au clavier et d’un commit git au fichier ODT, nous verrons comment infuser la culture du web dans l’édition via des contenus et des formats ouverts, les pratiques collaboratives, entre autres.

The usual way of writing a technical book is to open the Word or LibreOffice application, to write some content, to make a backup, to send it by email to the publisher and to deal with the feedbacks. And repeat.

However in 2017 we can do differently by using open formats like Asciidoc, by using version control to propagate changes, by using collaborative platforms like GitHub or GitLab to collate feedbacks in any form as well as transforming text and code into readable and interactive artefacts.

It gives us a unique opportunity to approach the whole process of writing in term of “content experience”, of “toolchain” and of “distribution”.

In the end, a “book” becomes a “writing format” as we can reuse the same pattern to manage any kind of “content” — articles, publications, essays, documentation — that we can transform in physical books, e-books, interactive web pages etc.

Il y a un an j’ai décidé de passer à temps partiel, ou plutôt aux week-end de trois jours. Est-ce que ça m’aide à rattraper mon retard dans Game of Throne, augmenter le nombre d’heures que j’alloue à ma veille technique ou bien à passer pour quelqu’un qui n’aime pas travailler ?

À vrai dire, j’ai surtout pu augmenter ma qualité de vie malgré ma baisse de salaire, ainsi que dédier ce temps à du bénévolat, m’aérer l’esprit et voir du pays en me fatigant un peu moins.

The 21st century digital economy seems to be all about data. The bigger the better. The bigger the more difficult to browse from a human point of view too.

I present several facets of data, from analog to digital, computed to manually curated.

Notre startup avait tout pour réussir : un projet innovant, une équipe talentueuse et de l’argent pour tenir 12 mois sans contrat. Pourtant 6 mois après le lancement de l’activité commerciale, le premier chèque de salaire impayé se déclare. Comment en est-on arrivé là ? Comment on s’en sort ? Seul et/ou en groupe ? Surtout quand la confiance devient aussi rare que l’argent.

What is the difference between a UI component, an npm package, a Docker image and a machine, either bare metal or a VM? Well, none really: we expec them to be resilient, composable and reliable.

This talk is a technical and functional journey around the concept of modular architectures, of quality and of resilience.

Quelle est la différence entre un composant visuel, un package npm, une image Docker et une machine, physique ou virtuelle ? À vrai dire, aucune : on attend d’eux résilience, composition et fiabilité.

Cette présentation est un voyage technique et fonctionnel autour des concepts des architectures modulaires, de qualité et de résilience, à la fois pour les machines et les êtres humaines que nous sommes.

En 2015, nombreuses sont les discussions qui portent, débattent et haranguent
les développeurs pour savoir si oui ou non, ce soir c’est monolithe ou
microservices au repas.

Alors, monolithe, microservices … ou les deux ?

Docker has shaken the software world by making LXC a commodity. Now
that the universal runtime container runC is born, what is its impact on
us, developers?

We will investigate what Docker really is, how to think in term of layers
and containers, and what are the key best practice in term of design and
security. Demonstrator can be found on GitHub.

What is the difference between a UI component, an npm package, a Docker image and a machine server? Well, none really: we want them to be resilient, stateless and composable.

This talk is a technical and a functional journey to the key concepts of our modular architecture at BBC R&D, how we ensure its quality and scalability, amongst humans and machines.

ux.js is an amazing framework which helped me to be a better developer for the past 12 months.

This is a lightning talk to share the methods learnt and their impact on my codebase.

Open Source can be seen as Wonderland when you are outside of it. But maybe you fear to be scalped if you contribute a wrong piece of code… Something is missing in between isn’t it?

So where to start? How to convince your boss it is worth it? How to broaden the reach of the project? Especially in a large organisation like the BBC.

Open Source can be seen as Wonderland when you are outside of it. But maybe you fear to be scalped if you contribute a wrong piece of code… Something is missing in between isn’t it?

So where to start? How to convince your boss it is worth it? How to broaden the reach of the project? Especially in a large organisation like the BBC.

Let’s see through the Peaks.js waveformvisualisation journey how to pitch a project, how to ship it and how to build a momentum beyond the initial expectations.

The README has become the new documentation entrypoint.

From nothing to something, the README will improve the quality of your project.
And more than that, you can even design your project and shape its future by
following the same pattern.

We use Grunt plugins and the Gruntfile.js to achieve common and repetitive tasks.

Sometimes, we have to bake our own business logic so we write code. And it works.
How do we test it? By running the code. How do we reuse the code? We don’t it’s a Grunt task.

I’ll explain the story of the BBC News refactoring of Grunt tasks, how it has been simplified and fully tested.
Thanks to that, you will be able to write not only code but testable features and tricks to optimise your Gruntfile.js.

TGIF! The best aknowledged day to deploy production-ready software. But just when you were about to leave the office,
you discover a bug and want to fix it.

If only the developers had written a README.md instead of a 30 pages specification document!

C’est vendredi, jour béni de mise en production : le sysadmin est déjà à l’apéro
pendant que vous terminez un diagramme de Gantt. Hélas patatras : le site plante.

Si seulement il vous avait laissé un README.md ce gentil Amédé !

Grunt est un outil populaire chez les développeurs Node.js et frontend.

Je partage quelques pistes et techniques pour créer vos propres tâches Grunt testées et maintenables.

J’en profite aussi pour évoquer cette pratique au travers d’un retour d’expérience lors d’un sprint de deux semaines dans l’équipe de BBC News.

The Promise JavaScript pattern is receiving quite a lot of attention recently as popular asynchronous pattern.

This talk presents the way to understand the concept, how to learn using them step by step and how to design your software based on a real world example.

Remember your complex Excel VBScripts or your first handmade Access+Word mailer system nightmares?

Google Apps Scripts is a hidden replacing gem without having to buy a SAP licence.

JavaScript is the definitive language to build scripts, deploy simple & complex workflows using your company’s Google Apps services and datas: retrieve from third party providers (like Twitter), host in Spreadsheets, publish to Calendar, notify with emails and more.

Vendredi, mise en production. Vous annoncez à vos proches que pour l’apéro ce soir, c’est mort, vous êtes dé-bor-dé(e).

Un mauvais clic plus tard, le site est mort. Ambiance fin du monde pendant que vos amis s’amusent.

Si vous aviez su que la rédaction du README de votre projet vous aurait permis non seulement de préserver votre apéro sacré, mais en plus de livrer le cœur léger, vous l’auriez sûrement écrit plus tôt.

Avant que le monde ne s’effondre sur lui-même, nous ferons encore mieux : 15 minutes c’est juste ce qu’il faut pour créer un code robuste.

Le développement Web frontend – multiplicité de compétences – est l’apanage des experts … ou des stagiaires. Développer, c’est Java, C# ou PHP.

L’omniprésence des interfaces recourant à HTML induit un recours à des points de repère, tant pour les développeurs, les chefs de projet que les acheteurs. C’est une des idées qui en est ressortie de l’atelier Industrialiser l’artisanat du développement HTML à Paris Web 2010.

Depuis, l’eau a coulé sous les ponts et une liste de bonnes pratiques de développement frontend est en cours de réalisation. Nous verrons comment et pourquoi l’alimenter, entre autre pour des besoins d’industrialisation des projets.

L’industrialisation, c’est aussi un mot qui inquiète, surtout lorsque cela concerne un des pans du développement Web proche du modèle de l’artisanat. Est-ce le retour du travail à la chaîne ? Est-ce une spécialisation ou une déresponsabilisation ? Ou pire, est-ce un moyen d’apporter une réponse unique à des besoins multiples ?

Symfony does a lot of things, so as your admin-generator.

However, we still need to be connected to our app to use them. Gears, and now HTML 5, makes our web pages offline capable, so why not our admin-generators?

We’ll see how to contribute to your app from a submarine or a cave and how to improve online performances with local caching.