How to Survive the Day

How to Survive the Day

A bunch of pills about it.

944ea93d87f2872251a6c05a68c3d4be?s=128

Fabio Cicerchia

May 27, 2019
Tweet

Transcript

  1. 5.

    Foundations You need rock solid grounds to be able to

    face any challenge with flexibility 1 Smart Moves Most of the times the basics are not enough and you need to start be “creative” about how to approach to the problem 2 Last Resort If everything else failed there’s only one thing to do 3
  2. 8.

    Know How to Debug 1. Start with code that already

    works or 1. Always Reproduce the Bug Before You Start Changing Code 2. Read the error message / stack trace 3. Run your code every time you make a small change 4. Guess and Check 5. Write a Test Case that Reproduces the Bug
  3. 10.

    Doubt your Assumptions • Are you sure what you’re thinking

    is true it really is? • What are the chances you might be wrong? • It won’t hurt you, I promise
  4. 12.

    Take a Step Back • Beware of Yak Shaving •

    Have a 1000-foot view of what you have • Think again about what are you really trying to accomplish
  5. 14.
  6. 16.

    Change POV Often • Did it worked so far? ◦

    Yes: Good ◦ No: Don’t keep banging your head there
  7. 17.
  8. 18.

    RTFM Literally "Read The F**king Manual"; a term showing the

    frustration of being bothered with questions so trivial that the asker could have quickly figured out the answer on their own with minimal effort, usually by reading readily-available documents. People who say "RTFM!" might be considered rude, but the true rude ones are the annoying people who take absolutely no self-responsibility and expect to have all the answers handed to them personally. http://rtfm.urbanup.com/773100
  9. 20.

    Take Notes • We are not a faultless human beings

    • Mostly overwhelmed with thoughts • Write it down ◦ Use pen & paper ◦ Post-it ◦ Evernote ◦ Notepad ◦ ... ◦ It doesn’t really matter where • Go back to your notes! • Check older notes as well for missed ones
  10. 23.

    The Master Should Always Work • The Master branch should

    always be your starting point • The Master is most often linked to the current production state ◦ So if it works there it is “safe” to use • Don’t use unstable branch as you don’t know exactly the state they are in ◦ You think you do? ▪ Would you bet your money on it?
  11. 25.

    Push Everyday • It saves you from hardware faults •

    It saves you from human mistakes • It allows other people to review you work • It allows other people to work on the same code • Some best practices: https://sethrobertson.github.io/GitBestPractices/
  12. 27.

    Pull Everyday • It saves you from conflict-resolution headaches •

    It allows you to get latest version (possibly bug-free)
  13. 29.

    Git Rebase • Align you branch with the master •

    You’ll get all the fixes and won’t experience all the pain behind them • You keep the history clean • Rebase even within your own branch ◦ Squash commits together
  14. 31.

    Green Build • Let the CI system be your best

    friend • It helps you running the whole test suite while you keep coding • Go back and check all the pipeline steps for weird behaviours or warnings • Review your Merge Request before asking others to do it
  15. 33.

    Multiple Bugs • What if you think it’s one bug

    but there are more? • Are you tackling the right one? • Focus one bug at the time, limiting the Yak Shaving • Separate the context for each bug (that means a new branch as well)
  16. 35.

    Beat the Flow • Break the loop • Break the

    recursion • Exit from the flow
  17. 37.

    Understand How Things Are Structured • Tech Stack • Server

    Side Framework (if any) • Client Side Framework (if any) • Databases • Queues • Cache Systems: Redis, Memcached, Varnish • Storage • File System • Workers • Virtual Machines / Containers • APIs
  18. 39.

    Always Have Your Safety Net • Logging system: App Logs,

    Service Logs, ELK, Sentry • Monitoring systems: Nagios, Zabbix, NewRelic, Datadog • Profiling System: XHProf, SF Timeline, Blackfire • Remote Debugging: XDebug • Raw Debugging Techniques: ◦ Comment out block of codes ◦ var_dump/echo/print/file_put_contents
  19. 41.

    Take A Break • AWAY FROM THE SCREEN (the smartphone

    as well) • Coffee • Drink water • Little walking • Chit-chat with your co-workers • Have a cigarette • Quick phone call • Use the restroom ;)
  20. 43.

    Bend the Environment to Your Will • Put the environment

    to your desired state ◦ Adjust the DB records as well
  21. 45.

    Is it necessary? Quite often when you’re stuck in the

    mud you get lost in trying to fix whatever thing comes up, losing sight of what you should be really achieving. Ask yourself this question would allow you to stop, think and possibly take a change of course. There’s no right number about the numbers of changes of course you can make in order to overcome the issue.
  22. 46.
  23. 47.

    Ditch it If at the question “Is it necessary?” the

    answer is no, then just ditch everything. Do a git reset --hard origin/master e start over, and this time you might not need to do anything as the problem was not actually a problem after all.
  24. 50.

    Ask For Help • Rubber Duck • Deskmate • Go-to

    Guy • Ex-Colleagues • Community: Google Groups, Slack, Forums, GitHub Issues, Gitter
  25. 51.
  26. 53.

    Learn RegExp • Why? ◦ They’ll make your life way

    more easier • They can be applied in any context ◦ IDE ◦ Source Code ◦ SEO Rewrites (haproxy, nginx, apache, …) ◦ Shell (grep, sed, awk) ◦ GMail or any Email Client ◦ Google Analytics Filters ◦ …
  27. 54.
  28. 55.

    Use vim • Yes! You’ve heard ;) • You can

    exit with :wq • It changes your approach to working with text document • You can replace flexibly using the regex • You can write, easily enough, custom macros for anything • You can turn a spreadsheet in a bash script in 5 minutes • It can literally do anything: https://www.vim.org/scripts/ • It has few package managers as well: Vundle, Pathogen, NeoBundle, vim-plug
  29. 56.
  30. 57.

    To Google • You can’t just ask him whatever comes

    to your mind • Try to be synthetic and straight to the point • Include keywords, such as: framework, language, error code, error string, … • Use the quotes to narrow down your search (exact match) • Strip out un-relevant information from the error message, such as: file path of your pc, usernames, hostnames, …
  31. 58.
  32. 59.

    Git Blame • This doesn’t mean literally blame the person

    • It is useful to understand when the last change was made • It is useful to read the commit message to get a bit of context (so here the necessity of clear and useful commit messages) • It is useful to check the whole commit structure • It is useful to know who wrote the code and ask him if he/she remembers anything about it
  33. 60.
  34. 61.

    Grep • Simple, fast and powerful tool • It searches

    inside the file contents ◦ Yes, it supports RegExp • You can customise the output based on different needs ◦ Show a bit of context, by showing preceding and following lines ◦ Show the line number ◦ Inclusive/Exclusive matching
  35. 62.
  36. 63.

    Find • Simple, fast and powerful tool • It searches

    based on filename/dirname ◦ Yes, it supports RegExp • You can customise the output based on different needs ◦ Files older than X days ◦ Retrieve symlinks
  37. 64.
  38. 65.

    Linters • They help you catching the errors before executing/committing

    • Are easy to use • We keep forgetting of them, so embed them in your IDE (yes even in vim)
  39. 67.

    Unit Tests • You can catch errors or mistakes you

    didn’t encountered during your manual testing • They allow you to refactor without worries • They allow other to refactor without cursing the author • They let you write better code, in a testable way, even if you don’t write tests
  40. 69.

    Smoke Tests • High level tests • Non-exhaustive set of

    tests • Aiming at ensuring that the most important functions work • If these tests are broken it useless going further with deeper level of tests
  41. 72.

    • It doesn’t mean that the issue is exactly where

    you’re looking at • It doesn’t mean that the issue is part of the task you’re working on Go The Extra Mile
  42. 73.

    Go The Extra Mile • You might be working on

    a PHP code, but you need to get your hands dirty with server configuration • You might be working on a mobile app, but you need to set up an API service just to keep working • You might be working on a certain level, but you need to have the flexibility of looking elsewhere and acting on it, even if it’s not your responsibility. Or you’ll be stuck forever waiting the knight in shining armour coming to rescue you. No-one wants to be that damsel in distress ;)
  43. 76.

    • Drop the cache: application, local to home folder, global

    to system • Drop the vendors folder • Loose the permissions, don’t be shy for a chmod -R 777 • Are the services running? • Can you reach, from where the issue is, the services? • Iptables? • DB Grants? • Are you hitting varnish rather than the frontend? • Is the VPN up and running? • Expired SSL keys? • Opcache? • Doctrine cache? • Are you looking at the right environment? • Is the source-code updated? • Have you dumped all the static assets? Need to Go Wild?
  44. 78.

    WIP