Привет, меня зовут Поляков Павел, я 15+ лет в айти и я хороший разработчик. Так говорят мои коллеги, так говорят мои менеджеры, так я думаю про себя сам. У меня есть жгучее желание делиться знаниями с другими разработчиками и не только.

В этот канал я буду постить кусочки информации которую полезно было бы знать любому разработчику. В текстовом виде. А что еще интересно - у меня есть ТикТок: https://www.tiktok.com/@gooddevknows, где я в коротких видео тоже рассказываю о том, что знает хороший разработчик.

Поехали!

Хороший разработчик знает что такое OLTP и OLAP

В зависимости от того, что мы собираемся делать с данными, мы выбираем тип базы данных, где будем их хранить.

1️⃣ OLTP - online transaction processing

Цель - обеспечить ежедневную работу бизнеса. Например - пользователь делает заказ в интернет магазине, данные о заказе сохраняются в базу данных предназначенную для OLTP и обрабатываются дальше - со временем меняется статус заказа.

Для OLTP часто используют реляционные базы данных, например PostgreSQL.

2️⃣ OLAP - online analytical processing

Цель - принимать решения основываясь на большом объеме данных. Например, мы хотим посчитать среднюю сумму заказа за десять лет существования нашего интернет магазина. При этом в день делается 10 тысяч заказов.

Для OLAP часто используются колоночные базы данных, предназначенные бля бизнес аналитики, например Amazon Redshift.

⬛️ Еще раз OLTP - каждый день, для поддержки бизнес процессов; OLAP - когда нужно, для аналитики. Лучше не смешивать.

Хороший разработчик знает что такое KISS, YAGNI и DRY

Есть универсальные принципы разработки, которые сделают код вашего сервиса или приложения понятнее и легче в поддержке.

1️⃣ KISS - keep it simple, stupid

Чем проще ваша программа, тем лучше она будет работать. Тем легче покрыть ее тестами. Не нужно выдумывать лишних абстракций, стараться сделать все максимально расширяемым в БУДУЩЕМ, делаем минимум, но хорошо, то есть просто и понятно.

2️⃣ YAGNI - you aren't gonna need it

Тебе это не понадобиться. Не нужно концентрироваться на облегчении своей жизни в будущем. Пытаться представить как программа будет изменяться в будущем и подстилать себе соломку. Чаще всего, изменяться она будет не так. А может не будет. А может и вовсе окажется что этот компонент не нужен, им никто не пользуется, тогда и расширять незачем - просто удаляем.

3️⃣ DRY - don't repeat yourself

Не повторяйся или не будь заложником копи-пэйста. Если один и тот же код используется более трех раз - вынесем его в отдельную функцию. Так его будет легче поддерживать. Но помни keep it simple, если это ведет к тому, что понять что происходит будет сложнее - оставим как есть, подождем еще.

⬛️ Еще раз - не надо усложнять сейчас, если это нужно будет в будущем - время найдется.

Хороший разработчик знает как что-то объяснить, часть 1

Разработка это не только написание кода, это еще и обсуждения, умение договариваться, умение делиться знаниями и объяснять.

Когда мы что-то рассказываем, то цели могут быть разные, одна из самых интересных это - объяснение. Например мы хотим объяснить, что новый фреймворк намного лучше, чем тот, что используется.

Когда мы что-то объясняем, мы помогаем слушателю ответить на вопрос "почему?". Почему, то что мы говорим это важно и стоит узнать больше про это? Объяснение снижает цену потребления информации. После того что он узнает, слушателю станет проще углубиться в тему самостоятельно.

Самая большая ошибка при объяснении, мы часто думаем, что те кто будут тебя слушать знают тоже что и мы. Это не так. Если начать говорить о том, что слушателю будет сложно понять, то есть большой риск что им станет сложно, не интересно, и они прекратят нас слушать.

Подумаем, кто будет нас слушать? Можно расположить слушателей на шкале понимания предмета.

Тем кто ближе к А нужно знать зачем это все нужно, а тем кто ближе к Z интересно знать как это сделать. В ходе объяснения мы помогаем слушателю двигаться от A до Z.

⬛️ Еще раз - резюмируем, после нашего объяснения, слушатель должен почувствовать, что он стал умнее. Дальше он сможет сам начать разбираться в теме или спросить у нас подробности.

Подписывайся, чтобы увидеть часть 2 - пошагово разберем как подготовить хорошее объяснение.

Хороший разработчик знает как что-то объяснить, часть 2.
🎥 видео в TikTok.

Мы разобрались что такое объяснение и какова его цель. Наша цель — чтобы человек, который нас слушает, почувствовал себя умнее и смог дальше углубиться в тему.

Существует простой рецепт как подготовить хорошее объяснение. Оно должно состоять из таких частей:

1. Соглашение
2. Контекст
3. История
4. Связь
5. Описание
6. Вывод

1️⃣ Мы начинаем с соглашения - какой-то общеизвестный факт, чтобы дать человеку почувствовать, что он понимает что происходит. Дать уверенность в том что он сможет понять тему.

2️⃣ Контекст - почему вещь о которой мы говорим вообще важна?

3️⃣ История - без истории наши слова это просто факты. История добавляет эмоции, слушателю проще связать себя с проблемой. Простейший сюжет — был парень Стас. У Стаса была проблема и он был в отчаянии. Стас решил проблему и теперь он счастлив. Ты хочешь почувствовать себя как Стас?

4️⃣ Связь. Если нам нужно рассказать о чем-то, о чем слушатель вообще может не знать — рассказываем на примере того что он знает. Например, как рассказать про фильм "Чужой"? "Чужой" - это как фильм "Челюсти", только в космосе.

5️⃣ Описание. Чем дальше двигается человек по шкале понимания, тем более он хочет получить ответ на вопрос "Как?". Как сделать то о чем ты говоришь? Как мне тоже стать счастливым как Стас? Теперь можно начать описывать решение, упуская неважные подробности.

6️⃣ Вывод. Резюмируем все о чем мы сказали ранее и добавляем призыв к действию. Что человек должен сделать после объяснения?

⬛️ Еще раз — хорошее объяснение состоит из соглашения, контекста, истории, связи, описания и вывода.

Теперь соберем все вместе и посмотрим пример объяснения.

Подписывайся и смотри часть 3.

Хороший разработчик знает как что-то объяснить, часть 3
🎥 видео в TikTok.

Хорошее объяснение состоит из шести частей:

1. Соглашение
2. Контекст
3. История
4. Связь
5. Описание
6. Вывод

Давайте соберем все вместе на примере, я объясню почему аккаунт "Хороший разработчик знает" это маст хэв в подписках.

Известно, что быть разработчиком это супер. У тебя интересная работа, перспективы, хорошая компенсация.

Но, как и в других профессиях, у нас есть выбор — можно быть хорошим, востребованным разработчиком и контролировать свою карьеру, а можно просто плыть по течению. Что же нужно делать, чтобы стать хорошим разработчиком?

🎬
Представьте Стаса, Стасу 25 лет, он back-end разработчик. Карьера Стаса топчется на месте, он миддл уже 3 года, менеджером быть не хочет, что делать дальше? Еще Стас любит TikTok, ведь тут можно залипнуть на смешные видео. Как-то раз Стасу в рекомендации попал ролик с аккаунта "Хороший разработчик знает", он был интересным, Стас узнал что-то новое. Стас решил подписаться на канал и через месяц понял куда ему расти как разработчику. Через 3 месяце Стаса запромоутили в синьора и подняли зарплату на 2 тысячи долларов.

Канал "Хороший разработчик знает" это как пройти дорогие курсы на Cousera, только тратить нужно всего минуту в день и он доступен прямо в TikTok.

Чтобы эффективно развиваться как разработчик, получать знания о том как быть хорошим разработчиком и закреплять уже известные — просто подпишись на аккаунт в TikTok. Здесь практически каждый день что-то новое.

Получать качественные знания из TikTok можно и это очень просто — подписывайся на аккаунт "Хороший разработчик знает" и расти как специалист.
🏁

Еще раз — хорошее объяснение состоит из соглашения, контекста, истории, связи, описания и вывода.

Сумели опознать все части в моем объяснении?

Хороший разработчик знает что такое функциональные и нефункциональные требования.
🎥 видео в TikTok.

Хорошо поставленная задача содержит требования. Что должно получиться, чтобы мы поняли, что достигли цели? Давайте разберемся какие бывают требования.

1️⃣ Функциональные требования или functional requirements
Чаще всего, когда мы разрабатываем программное обеспечение, мы знаем что оно должно делать. Еще лучше, когда мы знаем почему оно должно это делать. Для решения какой бизнес задачи мы пишем эту программу?

Например, мы пишем новый Телеграм, нужно сделать так, чтобы если пользователь шлет в чат картинку, мы ее где-то сохраняли, и показывали другим участникам чата.

Это функциональное требование для нашего приложения и бэк-энда. Если мы это не сделаем, наш продукт не будет решать бизнес задачу.

2️⃣ Нефункциональные требования или non-functional requirements

С другой стороны, когда мы разрабатываем что-то, мы не всегда сразу знаем КАК мы это будем делать. Многие вещи, которые непосредственно не относятся к бизнес процессам, могут повлиять на пользовательский опыт или на сложность поддержки программы в будущем.

Например, есть множество вариантов куда сохранять картинки в нашем мессенджере — мы можем сложить их прямо на диск на сервере, а можем положить в S3. Но только вариант с S3 обеспечит хорошую долговечность этих картинок (99.999999999%).

Большинство нефункциональных требований можно отнести к таким категориям:

1. Performance (производительность)
2. Security and compliance (безопасность и соблюдение правил)
3. Recoverability (возможность восстановления)
4. Maintainability (удобство в обслуживании)
5. Reliability (надежность)
6. Availability (доступность)
7. Scalability (масштабируемость)
8. Usability (удобство использования)

⬛️ Еще раз - требования которые напрямую относятся к решению бизнес задачи — функциональные. А нефункциональные это требования которые могут напрямую быть не видны пользователю или клиенту, но могут сильно повлиять на их опыт.

Дальше мы подробно рассмотрим категории нефункциональных требований.

Хороший разработчик знает про виды нефункциональных требований.
🎥 видео в TikTok.

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

Большинство нефункциональных требований можно отнести к таким категориям:

1. Performance (производительность)
2. Security and compliance (безопасность и соблюдение правил)
3. Recoverability (возможность восстановления)
4. Maintainability (удобство в обслуживании)
5. Reliability (надежность)
6. Availability (доступность)
7. Scalability (масштабируемость)
8. Usability (удобство использования)

Теперь рассмотрим примеры.

Performance
- Как быстро для пользователя должен открываться сайт?

Security and compliance
- Как мы обезопасим приложение от неавторизованного доступа?
- Как мы можем обеспечить исполнение закона о защите персональных данных?

Recoverability
- Если база данных упадет, как мы можем восстановить данные?

Maintainability
- Если что-то идет не так, наш сервис шлет разработчикам уведомления об этом?

Reliability
- Как мы можем убедиться, что сервис работает стабильно?

Availability
- Если датацентр затопит — наш сервис продолжит работать?

Scalability
- Если ссылку на сайт разместят на reddit — он выдержит нагрузку?

Usability
- Как можно упростить для пользователя использование приложения?

⬛️ Еще раз — нефункциональные требования напрямую не решают бизнес задач, однако могут критически повлиять на опыт пользователя. Либо сделать поддержку программу невыносимой для разработчика.

Очень важно обдумывать и документировать такие требования как можно раньше.

Было интересно? Поделись каналом с другом.

Хороший разработчик знает что такое DORA метрики.
🎥 видео в TikTok.

Современные процессы разработки включают в себя DevOps практики.

Как мы можем измерить насколько они хороши в нашей организации?

В течение 6 лет DevOps Research and Assessments (DORA) группа из Google проводила исследование, чтобы выявить метрики, которые отражают качество DevOps в командах.

Они пришли к выводу, что это можно сделать благодаря четырем ключевым метрикам:

1️⃣ Deployment frequency

Частота деплоев. Как часто ваша команда успешно релизит на продакшен? Чем чаще тем лучше.

2️⃣ Lead Time for Changes

Время внесения изменений. Сколько времени занимает путь от коммита в master до релиза на продакшен? Чем меньше тем лучше.

3️⃣ Change Failiure Rate

Коэффициент ошибок. Процент деплоев, которые привели к проблемам на продакшене. Чем меньше тем лучше.

4️⃣ Time to Restore Service

Время восстановления. Сколько времени нужно, чтобы восстановиться после ошибки на продакшене. Чем меньше — тем лучше.

Регулярно измеряя эти метрики вы можете получить оценку уровня DevOps и следить за ее прогрессом. Оценка может быть такой: Elite, High, Medium или Low.

⬛️ Еще раз — с помощью DORA метрик можно следить за качеством DevOps в вашей команде или организации. Для этого нужно измерять четыре метрики.

О чем еще рассказать про DevOps? Пишите в комментариях.

Хороший разработчик знает какие метрики нужно измерять.
🎥 Видео в TikTok.

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

Но что именно нужно мониторить? Исследования Google говорят, если вы можете мониторить только четыре метрики, то начните со следующих:

1. Latency
2. Traffic
3. Errors
4. Saturation

Они назвали их Four Golden Signals.

1️⃣ Latency

Время которое требуется сервису для ответа. Важно разделять успешные и ответы про ошибки. Обычно если мы возвращаем ошибку 500, то это происходит быстро. Но это не говорит о том, что наш сервис здоров.

2️⃣ Traffic

Сколько трафика получает наш сервис? Для http сервисов это как правило измеряется в количестве запросов в секунду.

3️⃣ Errors

Коэффициент ошибок. Какой процент запросов заканчивается ошибкой? Если большой, то вероятно что-то идет не так, нужно проверить.

4️⃣ Saturation

Как ваш сервис использует ресурсы? Если мы видим, что уровень CPU очень высокий - пора задуматься о скейлинге. А хорошо если это происходит автоматически.

Если вы измеряете все четыре сигнала и уведомляете человека, когда какой какой-то где-то проблема, то можно утверждать что ваш сервис разумно покрыт мониторингом.

⬛️ Еще раз - чтобы не было проблем, нужно на них оперативно реагировать. Для этого можно мониторить четыре золотых сигнала - latency, traffic, errors, saturation.

Было что-то новое для вас? Расскажите об этом в комментариях.

Хороший разработчик знает как использовать технику Fist to Five на митинге.

Иногда мы проводим митинги, например, чтобы договориться о чем-то с командой. В таком случае нам важно уметь оперативно узнать, что думают о том что мы обсуждаем участники. Здесь нам поможет техника Fist to Five.

Давайте представим, мы собрали команду из 5 человек, чтобы договориться о том, какую технологию мы будем использовать на новом проекте. Вы предлагаете Kotlin. Дискуссия идет уже 30 минут, и не видно чтобы она шла к завершению.

Мнения присутствуют разные. Кто-то говорит что ему нравиться идея, кто-то хочет сначала потыкать Kotlin дома, а кто-то говорит - давайте продолжим просто писать на Java.

С помощью техники ✊ To 🖐 мы получим фидбэк, есть ли у группы консенсус по вопросу. Готовы ли мы двигаться в направлении использования Kotlin? Для этого каждому нужно с помощью своей кисти отразить отношение к вопросу.

Можно показать 6 знаков:
1. Кулак — мне не нравится, я блокирую
2. Один палец — я вижу большие проблемы, которые нужно решить сейчас
3. Два пальца — я вижу небольшие проблемы, которые нужно решить сейчас
4. Три пальца — я вижу небольшие проблемы, которые нужно решить потом
5. Четыре пальца — мне нравится идея
6. Пять пальцев — идея супер, я готов вести этот проект

Если все участники показывают 3 и выше - консенсус присутствует, и вы можете начинать реализацию идеи. Если хоть кто-то показывает меньше трех - есть проблемы которые нужно решить до того как продолжать.

На нашем митинге показали только тройки и даже пятерку - так вы поняли, что команда, в принципе, не против попробовать Kotlin.

⬛️ Еще раз — митинги важны, а правильные инструменты сделают митинги эффективными. С помощью техники Fist to Five можно быстро узнать есть ли в группе консенсус по вопросу.

Хочешь узнать больше про митинги? Пиши в комментариях.

Хороший разработчик знает истории и учится на чужом опыте.

Я хочу рассказать историю о том, как хакер украл у компании, где я работал, более 10.000€. В то время я работал в финтехе, мы разработали новый продукт для онлайн кредитования.

Грубо говоря архитектура была такая - пользователь заполнял форму, где указывал данные про себя и сколько он хочет взять денег в кредит. Затем эта заявка проходила скоринг. А затем, в зависимости от результата, бэк-энд делал выплату.

Однажды кто-то заметил, что один 🧑‍💻 получил больше 10.000€. По бизнес правилам это было невозможно, потому что максимальный кредит который мы давали был 1500€ в одни руки.

Мы стали разбираться, и выяснили, что он получил выплату по одной заявке 8 раз! Мы стали копать дальше, и выяснили что, скорее всего, 🧑‍💻 для результата достаточно было просто очень быстро нажимать на кнопку подачи заявки — когда происходит сабмит формы. Потому что мы успешно обработали одну и туже заявку 8 раз.

На фронт-энде мы просто делали кнопочку "серой", но не блокировали клики по ней. На бэк-энде мы проверяли статус заявки, но если нажимать с разницей в миллисекундах, то запросы будут обработаны разными копиями аппликейшена и статус не успевал обновляться. Это называется race condition, ну и наш security фэйл, конечно же.

Дальше этот кейс ушел в суды и я не знаю чем он закончился. Ну а со стороны инжинеринга, мы конечно же быстро закрыли уязвимость.

⬛️ Еще раз, при проектировании всегда думайте что может пойти не так — design for failure. Мы не подумали и это стоило минимум 10.000€.

А у вас были какие-то security фейлы? Рассказывайте.

Давайте немного познакомимся и посмотрим кто у нас тут где. Меня зовут Павел, я в IT уже более 15 лет. Сейчас по документам я Senior, а по ощущениям Staff+. Работаю в SHARE NOW, каршеринг сервис в 🇩🇪 Германии.

Расскажите плз, где вы в IT, это поможет мне лучше готовить контент. Отвечайте по свои ощущениям, а не по документам.

Хороший разработчик знает как правильно сравнивать расходы на инфраструктуру или что такое TCO.

Сейчас существует много вариантов хостинга наших приложений и инфраструктуры. Мы можем использовать облачные решения, такие как AWS, можем взять дешевые и мощные дедикейтед серверы у Hetzner. В теории мы даже можем построить свой дата-центр. Но как разобраться какой вариант эффективней для нашего конкретного случая?

Давайте рассмотрим на примере. Представим что мы запускаем стартап - социальная сеть для любителей панд. В нашей соцсети можно будет дружить, размещать смешные картинки про 🐼, у нас будет даже чат для пандолюбов!

С точки зрения инфраструктуры мы видим, что нам нужен будет сервер, чтобы разместить фронт-энд и бэк-энд, PostgreSQL база данных и что-то под файловое хранилище.

* далее все расчеты примерны

1️⃣ Предположим, что мы думаем разместить это на Hetzner - сервер для приложения и вебсокетов, сервер для базы данных и файловое хранилище для картинок на 5 терабайт. Примерно, это будет стоить 45€ + 45€ + 27€ = 120€ в месяц.

2️⃣ Теперь посмотрим на AWS. Приложение разместим в Fargate - 320€ в месяц. База данных около 420€ в месяц. S3 который сохраняет по 1Тб в месяц - 23€. Итого 765€ в месяц.

Кажется выбор очевиден, ведь 120€ в месяц значительно дешевле чем 765€ в месяц. Однако мы не учли один важный момент. Мы хотим чтобы наша архитектура была эффективной и безопасной, а значит мы должны регулярно обновлять все зависимости.

В случае с хостингом на своих серверах, нам нужен будет человек, который будет настраивать сервер, регулярно следить за доступными обновлениями, обновлять версию базы данных до актуальной версии. Стоить такой специалист будет, например, 2000€ в месяц.

А в случае с облачным решением за нас это будет делать AWS.

💵 Поэтому нужно сравнивать суммы 2120€ и 765€. Правильно сравнивать суммы, которые мы платим за Total Cost of Ownership.

⬛️ Еще раз - TCO это стоимость покупки ресурса + стоимость его обслуживания.

Считали раньше TCO? Расскажите в комментариях.

Хороший разработчик знает кто такие Staff и Principal инженеры.

☀️ Спешу заявить — никакие тайтлы не влияют на то, что мы можем сделать как разработчики. Никакие тайтлы не ограничивают ваше возможное влияние. В здоровых компаниях верх берут хорошие идеи, идеи подкрепленные фактами и цифрами, а то от кого они идут — не важно.

Большинство разработчиков как-то представляет карьерную лестницу до Senior. Давайте быстро по ней пробежимся (условно):

1️⃣ Junior — в целом что-то понимает. Еще не понятно как настроить IDE, ошибки компилятора вызывают грусть. Не спешит принимать решения самостоятельно.
2️⃣ Middle — если кто-то расскажет что и как надо сделать, то он сможет это сделать. Может потом в мердж риквесте окажется что он не покрыл какие-то граничные случаи, но работать будет. Иногда предлагает оптимизации.
3️⃣ Senior — сформировавшийся специалист, задается вопросом ПОЧЕМУ мы должны это делать? Принимает информированные решения, анализирует трэйд-оффы, измеряет. Координирует разработку в команде, является тем "кто-то" для мидла. Делится знаниями, поддерживает Middle и Junior. В основном влияет на свою команду.

Описание позиций немного по штампам. Чем больше и лучше, в культуре инжинеринга, компания, тем сильнее и люди в этих уровнях.

Senior может стать конечной точкой в карьере и это совершенно нормально. Это хороший специалист который постоянно приносит пользу. Для компании — отлично, для самого человека — если ему конфортно в этой роли, то тоже отлично.

Ну вдруг хочется большего, что дальше? Дальше, условно, пути два - можно пойти в менеджмент трек и заботиться о людях, а можно продолжить в инжинеринг треке и заботиться о технологиях.

Для этого существуют уровни Staff и/или Principal. Обычно они появляются в компаниях с 30+ инженерами. Эти уровни можно объединить под Staff+

4️⃣ Staff+ — основное различие от Senior это уровень влияния. Он постоянно влияет на несколько команд, иногда на всю компанию. Улучшает процессы и технологии во всем инжинеринге. Менторит Senior людей. Хорошо знает доменную область. Координирует взаимодействие между командами. Учавствует в принятии стратегических решений.

Я описал продактового Staff+. Есть еще и с фокусом на технологию, например, у вас в компании работает создатель какого-то популярного опенсорс фреймворка.

⬛️ Еще раз — не тайтл решает насколько вы хороший разработчик, если разобраться, то можно оценить по реальным делам. Но тайтлы нужны, чтобы разработчик ощущал прогресс. Еще они видны снаружи вашей компании — так о вас могут сложить первое впечатление не знающие вас люди.

Согласны с описанием? Пишите в комментарии.

Хороший разработчик знает истории и учится на чужом опыте

Сегодня я расскажу о том, как я удалил базу данных на продакшене в первый раз.

Тогда, в середине 2000х, я работал на маленькую 🇳🇱голландскую компанию. У этой компании был внутренний, на то время инновационный, продукт для трекинга задач. Он действительно был красивее чем альтернативы, которые были доступны в то время. Отдельно менеджменту нравилось, что это наш собственный велосипед и мы могли его обновлять.

Однажды и мне поручили внести какое-то изменение в этот продукт. Процесс разработки был тоже простой — правь php файлы по ftp и смотри что получилось. В базу ходи через phpMyAdmin. Окружений было два - integration и production. Разница была в названии баз данных, которые они использовали.

И вот в какой-то чудный момент я, с помощью phpMyAdmin дропнул таблицу в базе данных. Я делал это уже десятки раз. Моя рука обладала мышечной памятью. Без секунды сомнения мой палец подтвердил удаление в появившемся попапе. Дело было сделано. Еще через минуту я понял, что я удалил таблицу в production базе данных. Это была основная таблица, та, где хранились таски.

Я обновил страницу в phpMyAdmin — таблицы не появилось 🙀. Через 5 минут судорожных кликов по табам в браузере я решил сказать об этом кому-то еще. Дальше пошел damage control.

В результате компания потеряла таски за последние 3 месяца. Потому что оказалось, что бекапы были предусмотрены, но они не работали. Нашелся только старенький, что лучше, чем ничего.

Меня никто ни разу не упрекнул в том, что я это сделал. Я знаю, что был разговор с человеком, который был ответственным за бэкапы. В отношении меня было понятно, что это была механическая ошибка. За бэкапами стали смотреть лучше. А в будущем мы перешли на Redmine.

Давайте выпишем недостатки инженеринга, которые нужно избегать:

1. Должна быть возможность развернуть проект локально. С локальной инфраструктурой.
2. Периодически нужно проверять что бэкапы работают. Сейчас лучше отдать это на аутсорс и использовать, например, AWS RDS.
3. Нужно чтобы команда знала как реагировать на такие ситуации. Лучше всего проводить 🎯 Game day.

◼️Еще раз — удалять базу данных на продакшене не страшно, такое точно будет происходить и в будущем. Но важно, чтобы команда была к этому готова. Design for failure.

Какие еще ошибки вы увидели? Пишите в комментариях.

Произошел пивот!

Некоторые знают, что вместе с телеграм каналом, я пытался/юсь развивать TikTok. Где выкладываю видео ролики о том, что знает Хороший разработчик.

Так вот, после 3-х недель выкладывания роликов я сдался, потому что TikTok оказался не в состоянии найти мою аудиторию. А именно - он тестировал мои ролики в 🇩🇪Германии, где шансов стать просмотренными у них не было. Потому что я ведь говорю там по-русски.

Несмотря на все мои ухищрения, я не смог выбраться из этой ловушки. Поэтому я задействовал план Х. И теперь мои ролики выкладываются на другом аккаунте и на другом телефоне, прямо из 🇺🇦 Украины, с аккаунта зарегистрированного на украинскую симку. Сейчас посмотрим кто кого, TikTok.

Новый аккаунт пока тут: https://www.tiktok.com/@gooddevknows.official. Приглашаю вас зайти и посмотреть, подписаться и полайкать.

Например, 🎥 про YAGNI и аренду летучих мышей.

Еще я сделал такие выводы:
1. Ролики должны быть короче
2. Тогда их будет легче производить и монтировать
3. Поэтому в Телеграмме я буду продолжать писать большие посты, а в TikTok снимать кусочками.

Надеюсь боги китайских алгоритмов будут ко мне более благосклонны в этот заход.

Вы вообще как, смотрите TikTok?

Хороший разработчик знает как выбрать тип процессора в облаке

Какой бы мы не писали код, рано или поздно он выполняется на процессоре. При создании облачной инфраструктуры мы можем выбирать разные типы процессоров. Еще этот слой называют compute. Важно выбрать правильно — тогда результат мы получим быстрее, а заплатим меньше

Давайте посмотрим, какие варианты у нас есть:

1️⃣ CPU — central processing unit. Самый обычный процессор, такой стоит в вашем компьютере. Такие процессоры проще всего программировать. Они подходят для большинства стандартных задач.
CPU состоит из нескольких ядер.

2️⃣ GPU — graphical processing unit. Изначально такие процессоры предназначались для обработки графики. Но стали применяться и в других задачах, где нужен большой объем параллельных вычислений.
GPU процессор состоит из тысяч ядер. Важно, что, чтобы использовать эти преимущества, ваша программа должна уметь работать с таким процессором.

3️⃣ FPGA — field-programmable gate array. Это железо, которое можно низкоуровнево запрограммировать, чтобы оно стало лучше обрабатывать определенные задачи. Грубо говоря, такой процессор сперва нужно прошить, а только потом использовать.

4️⃣ ASIC - application-specific integrated circuit. В этом случае процессор сразу производят оптимизированным для выполнения определенных задач. Например, Google предлагает tensor processing unit для обработки TensorFlow задач.

Если характеризовать эти процессоры по цене 💰(больше мешков = дороже), эффективности 📈 и гибкости ⚖️, то будет так:

1. CPU: 💰, 📈, ⚖️⚖️⚖️⚖️
2. GPU: 💰💰, 📈📈, ⚖️⚖️⚖️
3. FPGA: 💰💰💰, 📈📈📈, ⚖️⚖️
4. ASIC: 💰💰💰💰, 📈📈📈📈, ⚖️

◼️Еще раз — процессоры бывают разные, обычно хватает CPU. Если не хватает и софт позволяет, то можно использовать GPU. Если все еще не хватает — поздравляю, вы работаете над чем-то интересным.

Использовали когда-нибудь GPU? Пишите в комментариях.