Simple Engineer Notes
154 subscribers
147 photos
2 videos
49 links
Engineering insights from a simple perspective - focusing on DevOps, IaC, OS, automation and solutions without the complexity.

https://www.goncharov.xyz
Download Telegram
πŸ“„ OMG i can become root! Keynotes

https://pretalx.devconf.info/devconf-cz-2025/talk/LXBAUV/

- UAG(use after free) attack still actual in 2025
- use modern language = there’s no the problem
- at least there 3 techniques to mitigate problems in c/c++
- however it’s better to detect it. Hopefully there are some methods to do that
- and prevent


#conf #linux #devconf
πŸ€”2
πŸ“„Playbooks or Makefiles: choose your trade offs before it is too late

https://pretalx.devconf.info/devconf-cz-2025/talk/KFLFFZ/

- simplicity is crucial
- sometimes makefiles are too complicated
- ansible is too chatty and verbosity is higher. But it’s easier to understand what’s happening
- the future is: boring to write, difficult compile easy to read
- if you have problem and use regex than you have two problems now
- the same applicable for ansible
- the tool depends on the context

#conf #devconf #linux #ansible
😁1πŸ’©1
πŸ“„How a hit on the head made me into a better leader (Management lessons learned from a health emergency)

https://pretalx.devconf.info/devconf-cz-2025/talk/KSRNMN/

- Even if you are unhappy with your manager, don't hit him or her on the head.
- surgery and week in hospital is enough for the retro
- Listen to that headache. Gather data and use them.
Set up meaningful SLAs. Make sure you know when to take action based on alerts, and that you also know what to do with them.
- Fishbone vs. Five Whys
Issues rarely happen
because of one single root cause, but rather because of a combination of different factors. Limiting your investigation to one path increases resolution time and decreases user happiness.
- Three-dimensional risk management.
- Remove silos
- Mapping knowns and unknowns. Put your knowns and unknowns on the table.
It will help with ideas what to do next.
- Al as a diagnostic tool

#devconf #conf
πŸ’―1
πŸ“„Shifting Performance Engineering Left

https://pretalx.devconf.info/devconf-cz-2025/talk/NLWP8Z/

- perfomance tests must be part of your pipeline
- so they must be easy to start
- https://github.com/kube-burner/kube-burner

#devconf #conf
πŸ€”1
πŸ“ƒThe Art of Troubleshooting

https://pretalx.devconf.info/devconf-cz-2025/talk/DC9XWT/

- the book https://artoftroubleshooting.com/book/
- there are 2 mindsets: expert & fixer
- the systems are too complicated our days
- compare working & affected envs to detect the difference
- rubber duck debugging works because the brain switch to another mode. Nowadays AI can be used instead of the duck
- stay curious to learn new debug techniques and train your brain
- not possible/make sense to fix all the problems
- Troubleshooting is explaining the discrepancy between what you expect and what you observe
- every fix is an attempted fix
- did it work before?
- separate facts from assumptions. Use AI prompt: how to verify that …
- have set of possible causes and theories
- ask yourself and clients: what are you trying to achieve? Maybe you are fixing the wrong problem
- isolate/compensate the root cause
- happy fixing


#devconf #debug #conf
πŸ”₯2