Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Development Principles & Philosophy

5 817 vues

Publié le

Slides from the talk I gave at Web2Day/Tech2Day 2015.

Principles and philosophy guides our developer lives at Redsmin, Bringr and now iAdvize. Here is what we've learn in the past 3 years working in startup environments, the ideas shared behind this talk are language and paradigm agnostic.

Recording (in french): https://www.uslide.io/presentations/Aw6sX5ug-Tfzw5rNXAmdJg

Publié dans : Technologie

Development Principles & Philosophy

  1. 1. @FGRibreau DEVELOPMENT PRINCIPLES & PHILOSOPHY
  2. 2. François-Guillaume RIBREAU @FGRibreau
  3. 3. Bringr
  4. 4. Bringr Performance oriented Social MediaManagement
  5. 5. Bringr Leader européen de l'engagement client en temps réel. (click2chat, click2call, click2video, community, ...) #sold
  6. 6. Bringr
  7. 7. Developer oriented real-time monitoring and administration service for Redis
  8. 8. @FGRibreau COMPUTER SCIENCE IS ABOUT TRADEOFFS
  9. 9. @FGRibreau VS WHEN YOU FIGHT TO SURVIVE BETTER CHOOSE THE RIGHT PATH
  10. 10. @FGRibreau How can I make the right choice while coding?
  11. 11. @FGRibreau EASY.
  12. 12. @FGRibreau FOLLOW AND DISCOVER PRINCIPLES
  13. 13. @FGRibreau
  14. 14. SEPARATION OF CONCERNS @FGRibreau
  15. 15. SEPARATION OF CONCERNS @FGRibreau A.K.A THINK ABOUT ____#ROLES
  16. 16. @FGRibreau MONOLITH(S)
  17. 17. @FGRibreau Bringr #monolith
  18. 18. Use the Separation of Concerns Luke! Morpheus (not sure about this one)
  19. 19. @FGRibreau Bringr Bringr Strategy Bringr Impact Bringr ... Bringr Sourcing Bringr ... Bringr Alerts
  20. 20. @FGRibreau Bringr Strategy Bringr Impact Bringr ... Bringr Sourcing Bringr ... Bringr Alerts
  21. 21. @FGRibreau Bringr Strategy Bringr Impact Bringr Backend .... Bringr Sourcing Bringr Account ... Bringr Alerts
  22. 22. @FGRibreau Bringr Strategy Bringr Impact Bringr Backend .... Bringr Sourcing Bringr Account ... Bringr Alerts Filtering Statistics Rules EnginePublishing Statistics Updater UIUIUI Indexing G+ Vimeo Facebook Youtube Wordpress Twitter Notifications ... ... ...
  23. 23. @FGRibreau “DIVIDE MICROSERVICES BETWEEN ACTIVE AND PASSIVE ONES
  24. 24. @FGRibreau MICROSERVICE TYPE DEFINITION ACTIVE ACT ON SOMETHING PASSIVE REACT TO SOMETHING
  25. 25. @FGRibreau MICROSERVICE TYPE e.g. IN THE ASYNC WORLD ACTIVE PUBLISHER PASSIVE CONSUMER #AMQP #RabbitMQ
  26. 26. @FGRibreau THE LESS ACTIVE ONES, THE BETTER
  27. 27. @FGRibreau THE LESS ACTIVE ONES, THE BETTER THE MORE PASSIVE ONES, THE BETTER
  28. 28. @FGRibreau “DIVIDE STATE AND LOGIC INSIDE MICROSERVICESMICROSERVICES
  29. 29. @FGRibreau “DIVIDE STATE AND LOGIC INSIDE MICROSERVICESCOMPONENTS
  30. 30. @FGRibreau My Worker My Worker My Worker State Repository #atomic #concurrency #resilient #scaleOut
  31. 31. @FGRibreau State Repository #parallelism #resilient #scaleOut State Repository My Worker A My Worker B
  32. 32. @FGRibreau EACH MICROSERVICE SHOULD HAVE ITS OWN RESPONSIBILITY
  33. 33. @FGRibreau EACH MICROSERVICE SHOULD HAVE ITS OWN RESPONSIBILITY limit bug domain
  34. 34. @FGRibreau EACH MICROSERVICE SHOULD HAVE ITS OWN RESPONSIBILITY limit bug domain clear contracts
  35. 35. @FGRibreau EACH MICROSERVICE SHOULD HAVE ITS OWN RESPONSIBILITY limit bug domain clear contracts easier scaling
  36. 36. @FGRibreau EACH MICROSERVICE SHOULD HAVE ITS OWN RESPONSIBILITY limit bug domain improved velocity clear contracts easier scaling
  37. 37. LET’S ADD ANOTHER PRINCIPLE
  38. 38. @FGRibreau “FAIL FAST, FAIL OFTEN
  39. 39. @FGRibreau crash process as soon as possible log errors restart process alert developer
  40. 40. @FGRibreau (NodeJS) process ramcpu I/O OS fail fast, fail often
  41. 41. @FGRibreau (NodeJS) process ramcpu I/O OS fail fast, fail often CPU, RAM and I/O are limited NodeJS process can’t always monitor himself
  42. 42. @FGRibreau WE DO WANT CONSTRAINTS
  43. 43. @FGRibreau WE DO WANT CONSTRAINTS No more than 90% CPU during X mins
  44. 44. @FGRibreau WE DO WANT CONSTRAINTS No more than 90% CPU during X mins No more than 512Mo of RAM during X mins
  45. 45. LET’S ADD ANOTHER PRINCIPLE
  46. 46. @FGRibreau “EVERYTHING SHOULD BE LIMITED IN BOTH SPACE & TIME
  47. 47. @FGRibreau NodeJS process ramcpu I/O OS fail fast, fail often
  48. 48. @FGRibreau NodeJS process ramcpu I/O OS fail fast, fail often Supervisor
  49. 49. @FGRibreau NodeJS process ramcpu I/O OS fail fast, fail often Supervisor limited in space & time
  50. 50. @FGRibreau NodeJS process dev staging prod CONFIGURATION MANAGEMENT
  51. 51. @FGRibreau //  config.js module.exports  =  function(){        switch(process.env.NODE_ENV){                case  'development':                        return  {dev  setting};                case  'production':                        return  {prod  settings};                default:                        return  {error  or  other  settings};        } };
  52. 52. @FGRibreau app.configure('development',  function(){    app.set('configPath',  './confLocal');    //  “./confLocal”  is  a  constant }); app.configure('production',  function(){    app.set('configPath',  './confProduction');  //  “./confProduction”  is  a  constant });
  53. 53. @FGRibreau NodeJS process dev staging prod SHOULD MY PROCESS KNOW ITS OWN CONFIGURATION?
  54. 54. NOPE.
  55. 55. @FGRibreau constants files environment variables distributed CONFIGURATION
  56. 56. @FGRibreau constants files environment variables distributed Simplicity Genericity Knowing every running environments One configuration to rule them all CONFIGURATION
  57. 57. LET’S INVENT A NEW PRINCIPLE
  58. 58. @FGRibreau “EVERY CONSTANT NUMBER, BOOLEAN OR STRING* SHOULD BE CONFIGURABLE
  59. 59. @FGRibreau var env = require('common-env')(logger); var config = env.getOrElseAll({ amqp: { login: 'guest', password: 'guest', host: 'localhost', port: 5672, reconnect: false } }); var conn = require('amqp').createConnection(config.amqp); AMQP_LOGIN="user" AMQP_PASSWORD="azerty" node server.js npm install common-env https://github.com/FGRibreau/common-env
  60. 60. @FGRibreau NodeJS processLauncher SoC FTW env. vars.
  61. 61. @FGRibreau But my cloud provider uses AMQP_ADDON_LOGIN what should I do?
  62. 62. @FGRibreau ? var config = env.getOrElseAll({ amqp: { addon:{ login: 'guest', password: 'guest', host: 'localhost', port: 5672, reconnect: false } } }); var conn = amqp.createConnection(config.amqp.addon);
  63. 63. @FGRibreau
  64. 64. NOPE.
  65. 65. @FGRibreau NodeJS processLauncher SoC env. vars.
  66. 66. @FGRibreau NodeJS processLauncher SoC env. vars. Internal code is dependent from external naming convention
  67. 67. @FGRibreau var config = env.getOrElseAll({ amqp: { login: { $default: 'guest', $aliases: ['AMQP_ADDON_LOGIN'] }, password: 'guest', host: 'localhost', port: 5672, reconnect: false } }); var conn = amqp.createConnection(config.amqp);
  68. 68. // /config.js var logger = require('my-logger').createLogger(); var env = require('common-env')(logger); module.exports = env.getOrElseAll({ amqp: { login: 'guest' // ... } }); // /app.js var config = require('./config'); // /src/my/own/module.js var config = require('../../../config');
  69. 69. @FGRibreau Does it respect SoC?
  70. 70. NOPE.
  71. 71. var logger = require('my-logger').createLogger(); var env = require('common-env')(logger); module.exports = env.getOrElseAll({ amqp: { login: 'guest' // ... } }); /config.js
  72. 72. var logger = require('my-logger').createLogger(); var env = require('common-env')(logger); module.exports = env.getOrElseAll({ amqp: { login: 'guest' // ... } }); /config.js
  73. 73. var logger = require('my-logger').createLogger(); var env = require('common-env')(logger); module.exports = env.getOrElseAll({ amqp: { login: 'guest' // ... } }); /config.js
  74. 74. // config now asks for logger module.exports = function (logger) { var env = require('common-env')(logger); return env.getOrElseAll({ amqp: { login: 'guest' // ... } }); }; /config.js
  75. 75. // config now asks for logger module.exports = function (logger) { var env = require('common-env')(logger); return env.getOrElseAll({ amqp: { login: 'guest' // ... } }); }; /config.js // caller, must specify logger to use config // app.js var logger = require('my-logger').createLogger(); var config = require('./config')(logger);
  76. 76. HUM I THINK I KNOW THIS PRINCIPLE
  77. 77. @FGRibreau DEPENDENCY INVERSION This is the D from S.O.L.I.D:
  78. 78. @FGRibreau AGAIN.
  79. 79. // /app.js var config = require('./config')(logger); // /src/my/own/module.js var config = require('../../../config')(logger); ✘ DI ✘ DRY
  80. 80. // /app.js var config = require('./config')(logger); // /src/my/own/module.js module.exports = function (config) { }; ✔ DI ✔ DRY
  81. 81. HUM, LET CREATE US A REMINDER
  82. 82. @FGRibreau “”../“ IS A CODE SMELL
  83. 83. @FGRibreau LET’S TALK ABOUT CRON
  84. 84. @FGRibreau CRON
  85. 85. @FGRibreau CRON
  86. 86. #USERS
  87. 87. CRON IS NOT WORKING ANYMORE
  88. 88. #YOU
  89. 89. @FGRibreau CRON
  90. 90. @FGRibreau CRON
  91. 91. #USERS
  92. 92. CRON IS NOT WORKING ANYMORE
  93. 93. #YOU
  94. 94. @FGRibreau
  95. 95. @FGRibreau Process (e.g. cron) ramcpu I/O OS
  96. 96. @FGRibreau server Process (e.g. cron) ramcpu I/O OS Supervisor
  97. 97. @FGRibreau
  98. 98. @FGRibreau ?
  99. 99. @FGRibreau ?
  100. 100. @FGRibreau IT’S ALL ABOUT TRADEOFFS
  101. 101. LET’S INVENT A NEW PRINCIPLE
  102. 102. @FGRibreau “I SHOULD ALWAYS BE PROACTIVELY ALERTED
  103. 103. @FGRibreau NOTIFICATIONS ALERTS !=
  104. 104. @FGRibreau OK. LET’S RECAP
  105. 105. @FGRibreau “DIVIDE MICROSERVICES BETWEEN ACTIVE AND PASSIVE ONES
  106. 106. @FGRibreau “DIVIDE STATE AND LOGIC
  107. 107. @FGRibreau “EVERYTHING SHOULD BE LIMITED IN BOTH SPACE & TIME
  108. 108. @FGRibreau “EVERY CONSTANT NUMBER, BOOLEAN OR STRING* SHOULD BE CONFIGURABLE
  109. 109. @FGRibreau “”../“ IS A CODE SMELL
  110. 110. @FGRibreau “I SHOULD ALWAYS BE PROACTIVELY ALERTED
  111. 111. @FGRibreau “[add your own]...
  112. 112. @FGRibreau THE MOST IMPORTANT PRINCIPLE BEING
  113. 113. @FGRibreau SEPARATION of CONCERNS
  114. 114. @FGRibreau LET’S GO FURTHER
  115. 115. @FGRibreau PRINCIPLE Code dependencies should always be up-to-date
  116. 116. @FGRibreau AUTOMATION Build should break if code dependencies are not up-to-date
  117. 117. @FGRibreau PRINCIPLE Code style should always be consistent
  118. 118. @FGRibreau AUTOMATION Run a style-checker at each build
  119. 119. @FGRibreau PRINCIPLE Every developers should follow D.R.Y. (Don’t Repeat Yourself)
  120. 120. @FGRibreau AUTOMATION Run a structural code similarities tool at each build
  121. 121. @FGRibreau HERE IS WHAT WE DID
  122. 122. @FGRibreau https://github.com/FGRibreau/check-build
  123. 123. ONE LAST THING
  124. 124. @FGRibreau “DON’T CREATE CONVENTIONS YOU CAN’T ENFORCE
  125. 125. @FGRibreau PRINCIPLES
  126. 126. @FGRibreau PRINCIPLES CONSTRAINTS
  127. 127. @FGRibreau PRINCIPLES AUTOMATION CONSTRAINTS
  128. 128. @FGRibreau PRINCIPLES CONVENTIONS AUTOMATION CONSTRAINTS
  129. 129. @FGRibreau PRINCIPLES CONVENTIONS AUTOMATION CONSTRAINTS CODE
  130. 130. Follow me @FGRibreau Questions? Join us @iAdvize! Thank you!

×