Я очень много токсичных текстов написал в стол. 😏

На новой позиции впитал много интересного токсичного фарша.
🔪😟

#log

Не предавай себя

Моё важное правило:

Вокруг много контента плохого качества.
Концентрируйся на качественных примерах, ищи первоисточники.
Предпочитай стиль и качество.

У меня получилось собрать практики в эффектное комбо и применить? Да.

Вот, что вышло вместо негатива:

Благодаря общению с инженерами, работой с их вопросами, неудачами и прорывам.
Благодаря «сопротивлению» я накопил полезную выборку входных данных.
Я видел как люди с опытом в 20 лет не умеют проектировать софт, не умеют писать хорошо структурированный код с тестами. Я видел как новички быстро схватывают суть и пишут прекрасный софт, задают интересные вопросы.
Благодаря Академии я многое увидел в полезном свете для себя.
Благодаря новой роли на работе и общению с инженерами я стал смотреть шире и преисполнился.

Начал писать статью про рефакторинг, чтобы одним годным примером стало больше, чтобы поделиться мастерством.
По ходу написал ряд вступительных статей.
1 Как писать чистый код и сделать жизнь проще

2 Как не стоит писать код 

3 С чего начинать писать тесты при работе с легаси

Код финалочки прорастает здесь https://git.codemonsters.team/guides/mq-rest-sync-adapter/-/tree/feature/02-vertical-slice?ref_type=headsб

Начал писать финальный акт, написал 77 страниц с картинками, 2600 слов.
Перечитал и понял – нужна другая структура.
Фигня.
Все нужно переделать.
Нужно проще.

Не так мне математику объяснял мой гениальный препод.

Пришло время написать электрокнигу.

Давно планировал. Наконец-то родилась структура. 🔥

Бонусом я получил активного читателя, который часто задает интересные вопросы.

P.S. Ваня, спасибо тебе. Ты меня вдохновляешь.

#codemonsterslog #book
#software_craftsmanship

Супермегаукулеле

Как сделать проще? 💻🗺

Прожорливая и теплая машина

В комменты можно залить расчет сколько нужно Киловатт и как тепло будет с машиной рядом

The machine

https://fe2.net/p/themachine/

#themachine #hardware #llm

💻 друг написал хорошую выжимку в sre_guild

SRE vs. DevOps: В чем разница? 🤔

Привет, коллеги! Сегодня поговорим о том, чем же SRE отличается от DevOps?

Когда я только начинал разбираться в теме это был один из первых вопросов который я «загуглил». Иногда трудно понять где заканчивается одно и начинается другое. Давайте разберемся!

🔗 Связь SRE и DevOps:

Начнем с того, что SRE – это не замена DevOps, а скорее конкретная реализация принципов DevOps. DevOps — это философия, набор практик, направленных на улучшение взаимодействия между разработкой и эксплуатацией. SRE же предлагает практический подход к достижению этих целей.

🔑 Ключевые различия:

* DevOps: Это образ мышления, ориентированный на культуру сотрудничества, автоматизацию и непрерывную поставку ПО. DevOps говорит нам "что нужно делать".
* SRE: Это конкретный подход, описывающий как именно достичь целей DevOps, с фокусом на надежность и масштабируемость систем. SRE отвечает на вопрос "как это реализовать на практике".

Тут я пишу про DevOps в его изначальном понимании. Истинный смысл DevOps сегодня часто теряется, когда вместо интеграции между разработкой и эксплуатацией создается отдельная команда "DevOps", которая по-прежнему функционирует как изолированная единица. Имеем что имеем. 🤷🏻‍♂️

🤝 Роль SRE в DevOps-команде:

SRE-инженеры — это важная часть DevOps-команд. Они привносят инженерный подход к операционным задачам, автоматизируя рутинные процессы и используя данные для принятия решений. SRE следят за тем, чтобы системы были надежными, производительными и масштабируемыми.

🎯 Подходы к работе:

- DevOps-инженер: 
Работает над ускорением процессов, оптимизирует путь от разработки до продакшена.

- SRE-инженер: 
Обеспечивает стабильность и надежность системы, применяя инженерные принципы и автоматизацию.

В то время как DevOps-инженер стремится к скорости поставки, SRE-инженер обеспечивает надежную работу системы. Они работают вместе, чтобы достичь общей цели: быстро и качественно выпускать надежное ПО.

🚀 Пример: Как SRE обеспечивает надежность в рамках DevOps-процесса:

Представьте DevOps-команду, которая разрабатывает новое приложение. SRE в этой команде:

1. Определяет SLO/SLI: устанавливает цели по доступности и производительности.
2. Автоматизирует мониторинг: внедряет системы для отслеживания этих показателей.
3. Автоматизирует реагирование на инциденты: создает плейбуки для автоматического восстановления сервиса в случае сбоя.
4. Анализирует данные: использует метрики для выявления узких мест и оптимизации системы.

Таким образом, SRE помогает команде DevOps не просто быстро разрабатывать и развертывать ПО, но и гарантировать его надежную работу в долгосрочной перспективе.

В заключение:

SRE и DevOps — это не конкуренты, а скорее две стороны одной медали. DevOps задает направление, а SRE дает конкретные инструменты и методы для достижения успеха.

Что почитать:
Статья от Atlassian и от IBM на тему.

До связи!

😘 sre_guild

#SRE #DevOps #база #codemonsterslogs