$30 off During Our Annual Pro Sale. View Details »

How to Survive the Day

How to Survive the Day

A bunch of pills about it.

Fabio Cicerchia

May 27, 2019
Tweet

More Decks by Fabio Cicerchia

Other Decks in Programming

Transcript

  1. How to Survive the Day
    A bunch of pills about it

    View Slide

  2. You Need To Train Your Brain

    View Slide

  3. Skills
    Techniques

    View Slide

  4. Techniques

    View Slide

  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

    View Slide

  6. Foundations
    1

    View Slide

  7. Know How to Debug

    View Slide

  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

    View Slide

  9. Doubt your Assumptions

    View Slide

  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

    View Slide

  11. Take a Step Back

    View Slide

  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

    View Slide

  13. Don't Get Stuck For Too
    Long

    View Slide

  14. Don't Get Stuck For Too Long
    Getting Stuck is Not a Problem. Staying Stuck is

    View Slide

  15. Change POV Often

    View Slide

  16. Change POV Often
    ● Did it worked so far?
    ○ Yes: Good
    ○ No: Don’t keep banging your head there

    View Slide

  17. RTFM

    View Slide

  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

    View Slide

  19. Take Notes

    View Slide

  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

    View Slide

  21. Smart Moves
    2

    View Slide

  22. The Master Should
    Always Work

    View Slide

  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?

    View Slide

  24. Push Everyday

    View Slide

  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/

    View Slide

  26. Pull Everyday

    View Slide

  27. Pull Everyday
    ● It saves you from conflict-resolution headaches
    ● It allows you to get latest version (possibly bug-free)

    View Slide

  28. Git Rebase

    View Slide

  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

    View Slide

  30. Green Build

    View Slide

  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

    View Slide

  32. Multiple Bugs

    View Slide

  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)

    View Slide

  34. Beat the Flow

    View Slide

  35. Beat the Flow
    ● Break the loop
    ● Break the recursion
    ● Exit from the flow

    View Slide

  36. Understand How Things
    Are Structured

    View Slide

  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

    View Slide

  38. Always Have Your Safety
    Net

    View Slide

  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

    View Slide

  40. Take A Break

    View Slide

  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 ;)

    View Slide

  42. Bend the Environment to
    Your Will

    View Slide

  43. Bend the Environment to Your Will
    ● Put the environment to your desired state
    ○ Adjust the DB records as well

    View Slide

  44. Is it necessary?

    View Slide

  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.

    View Slide

  46. Ditch it

    View Slide

  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.

    View Slide

  48. Last Resort
    3

    View Slide

  49. Ask For Help

    View Slide

  50. Ask For Help
    ● Rubber Duck
    ● Deskmate
    ● Go-to Guy
    ● Ex-Colleagues
    ● Community: Google Groups, Slack, Forums, GitHub Issues, Gitter

    View Slide

  51. Skills

    View Slide

  52. Learn RegExp

    View Slide

  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
    ○ …

    View Slide

  54. Use vim

    View Slide

  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

    View Slide

  56. To Google

    View Slide

  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, …

    View Slide

  58. Git Blame

    View Slide

  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

    View Slide

  60. Grep

    View Slide

  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

    View Slide

  62. Find

    View Slide

  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

    View Slide

  64. Linters

    View Slide

  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)

    View Slide

  66. Unit Tests

    View Slide

  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

    View Slide

  68. Smoke Tests

    View Slide

  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

    View Slide

  70. My 2 cents

    View Slide

  71. Go The Extra Mile

    View Slide

  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

    View Slide

  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 ;)

    View Slide

  74. Need to Go Wild?

    View Slide

  75. ● Do it Big
    ● Think outside the box
    Need to Go Wild?

    View Slide

  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?

    View Slide

  77. What are your tips?

    View Slide

  78. WIP

    View Slide

  79. Got Questions?

    View Slide