Rex de ma vie d'indépendant

Rex de ma vie d'indépendant

Lien de partage sur Google (pour les gifs) : https://docs.google.com/presentation/d/1ebt1TPBb71KzV-25ei1DleNWrpjnRBQ9rDr5lZ-tG0w/pub?start=true&loop=false&delayms=3000

Notes :

- Slide 5 : C’est un mec qui arrive
- Slide 6 : avec ses bagages
- Slide 7 : Il réfléchit à votre problème
- Slide 8 : et idéalement il le résout ou fait en sorte de vous aider à le résoudre
- Slide 9 : puis il s’en va
- Slide 12 : mais pas forcément de bonnes idées sur le long terme

- Slide 14 : 1er problème : la position du développeur

1- un développeur c’est du temps de cerveau
2- un développeur c’est la formalisation du business en ligne de code
3- un développeur doit assumer son rôle pour le bien du projet, pas pour le mec au dessus de lui

- Slide 15 : Il faut arrêter d’utiliser des ID :

1- Ça expose le métier et personne n’en a envie
2- Lorsque vous montez sur des infra master/slave vous avez plein de problèmes
3- Vous avez tendance à utiliser des uid/gid auto-incrémenté dans vos API
4- Faut arrêter

- Slide 17 :
1- Beaucoup de monde utilise MariaDB ou Mysql >5.6
2- Beaucoup de monde veux de l’emoji
3- Attention aux index (3 bytes vs 4 bytes)

- Slide 19 :
1- Gros débat
2- Symfony-Standard n’est pas faite pour le multi-kernel
3- La majorité des projets sont centralisés dans un dossier “applicatif” (app/application/) contrairement à Symfony qui split à la racine app et src
4- Il faut donc changer ce fonctionnement
5- direct benefit, lorsque le projet devient trop conséquent vous pouvez splitter en deux copier/coller + simplification du composer.json

- Slide 21 :
1- Le microkernel trait est une réelle alternative à Silex
2- Le postulat de base est identique à celui de Silex
3- Mais vous pouvez réellement switcher vers une stack Symfony et pas refaire Symfony avec Silex en globalement moins bien

- Slide 23 :
1- Il faut arrêter de faire du test pour la couverture de code
2- On sort son analyseur de code statique
3- On priorise les tests sur le code le plus complexe

- Slide 25 :
1- Je pense qu’on devrait arrêter de faire de nouveaux projets pour combler les lacunes des précédents
2- Nous avons composer
3- Il faudra effectivement dealer avec deux autoloaders
4- Mais c’est juste un problème de remise en question de nos habitudes d’acceptation du code tiers
3- Ca fonctionne avec tellement de choses

- Slide 28 :
1- On revient sur le premier slide : vous êtes payés pour mettre du temps de cerveau à disposition d’un projet
2- Faites des tests même si l’on vous dit de ne pas en faire
3- Moi j’aime Behat et phpspec

- Slide 29 :
8 scénarios
42 steps
28 specs
97 examples

- Slide 37 :
Core = votre métier (le plus complexe)
Generic = des features que l’on retrouve sur tous les projets qui peuvent être acheté auprès de tiers (recherche, envoi d’email…)
Supporting = des features qui permettent d’utiliser le core (navigation par exemple) => OK POUR LE CRUD

12fad6dce4099a21ed70cf4409fe2271?s=128

Alexandre Balmes

December 19, 2016
Tweet

Transcript

  1. Rex de ma vie d’indépendant la qualitaÿ VS la qualité

  2. Qui suis-je ? Id // Alexandre BALMES Twitter // @pockystar

    Org // vanoix.com
  3. DEPUIS 2 ANS

  4. Bon indépendant ?

  5. None
  6. None
  7. None
  8. None
  9. None
  10. Et on l’oublie (ou pas)

  11. Bien entendu, il intervient ...

  12. Toujours sur des projets de qualit(é|aÿ)

  13. QUALITAŸ VS QUALITÉ

  14. EXÉCUTANT VS CONSULTANT

  15. ID (AUTOINCREMENT) VS UUID

  16. https://packagist.org/packages/ramsey/uuid

  17. UTF8 VS UTF8MB4

  18. [mysqld] character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci # Doctrine Configuration

    doctrine: dbal: default_table_options: charset: utf8mb4 collate: utf8mb4_unicode_ci engine: InnoDB
  19. MONO(KERNEL|APP) VS MULTI(KERNEL|APP)

  20. https://github.com/black-project/black-standard

  21. SILEX VS MICROKERNELTRAIT

  22. https://knpuniversity.com/screencast/new-in-symfony3/ micro-kernel

  23. COUVERTURE DE CODE VS TESTS

  24. http://www.phpmetrics.org/

  25. NOUVEAU PROJET VS REFACTORING LEGACY

  26. https://github.com/composer/installers

  27. None
  28. NO TESTS VS DO YOUR FUCKIN JOB

  29. @domain @application @authentication Feature: Manage account and users In order

    to use application I want to manage accounts Background: Given an user named "john" with an email "john@doe.com" and a password "azerty" Scenario: An anonymous want to create an account Given an user don't have any account When he create an account And the account is added Then system should be notified that it has been successfully created And the user should not have a password And the user should not be activated And the user should be locked Scenario: John want to confirm his account Given an user just create his account When he confirm his account Then system should be notified of this registration And the user should have a password And the user should be reachable
  30. http://stakeholderwhisperer.com/posts/2014/10/ introducing-modelling-by-example

  31. LAST BUT NOT LEAST

  32. EST-CE QUE JE PEUX FAIRE DU CRUD DANS UN PROJET

    DDD ?
  33. YES. BIG FUCKIN’ YES.

  34. YES

  35. YES. BIG FUCKIN’ YES.

  36. None
  37. CORE DOMAIN + GENERIC SUBDOMAIN + SUPPORTING SUBDOMAIN

  38. MERCI

  39. None