Буду рад предложениям, вопросам и идеям связанным с каналом или архитектурными/техническими вопросами. Можно написать в личку, а можно анонимно. А ответы на вопросы можно прочитать на сайте.
—————————————
Сколько стоит ваш техдолг: методики, цифры, российская специфика
В канале раз 5 упоминались статьи связанны с тех долгом, например «вводная» статья упоминалась год назад (остальные статьи по тегу). Сегодня еще один текст о долге, только авторы решили посчитать «долг» в рублях.
Текст начинается с объяснения, почему тех долг не видит бизнес и наоборот. Авторы связывают отчетность и фокус внимания бизнеса, куда не попадает техническая составляющая, не говоря уже о долге. Далее предлагается три способа подсветить долг бизнесу: прямые опросы людей, добавление тега «tech dept» в «джиру» и git churn (показывает процент перезаписанного кода за время). В конце предлагается три способа «оценки» долга в деньга:
- Считаем время, потраченное на затупы из-за тех долга и умножаем на часовую ставку. Берем цифру и показываем, сколько денег можно сохранить;
- Берем SonarQube и SQALE, полученное значение умножаем на часовую ставку, идем к бизнесу и повторяем первый вариант;
- Считаем cost of delay. Тут нужно посчитать задержку выхода фичи, в итоге получаем два числа: сколько времени фича реально делалась и сколько делалась бы без задержек.
P.S.: Учтите, что статья в блоге компании, которая «продает» собственное приложение. На базовую информацию не влияет, но мало ли.
#tech_debt
—————————————
PostgreSQL 19: Native Graph Queries Are Here
Случайно узнал, что осенью поменяю планы и буду ковыряться с постгресом. Связанно это с тем, что в сентябре выходит 19 версия, где главная, для меня, фича — нативная поддержка графов (хотя возможно гта победит графы). Почему-то уверен, что графы появились благодаря RAG и LLM. Синтаксис запросов уже описан в
ISO SQL:2023 Part 16, а язык запросов назвали SQL/PGQ (Property Graph Queries). Статья выше объясняет как будет выглядеть работа с графами в пг.Пересказывать статью не буду, кратно расскажу как работает. Для начала работы с графами определяем property graph. Делается это через
CREATE PROPERTY GRAPH, где явно указываются vertex (ноды, вершины) и edges (связи) таблицы (причем таблиц может быть больше одной). А что бы сделать запрос, используется SELECT * FROM GRAPH_TABLE (property_graph MATCH ...). Плюс стандарта в том, что язык запроса похож на cypher.В статье найдете примеры и, что радует, автор описал ограничения: fixed-depth pattern matching. Ну и другие фичи 19 версии тоже описываются.
#psql #graph
—————————————
What Is the 3-2-1 Backup Rule and Why It's Evolved to 3-2-1-1-0?
Я не DBA, поэтому о правиле 3-2-1 слышал, но использую только для 3 наборов данных и это не о коде. Если что, 3-2-1 о том, что нужны 3 копии, на 2 видах носителей и 1 копия должна быть в другом гео месте. Поэтому удивился, когда увидел 3-2-1-1-0 схему, думая что 3-2-1 уже заморочена для 80% проектов, но киберпреступления повлияли на бекапы.
Начинается текст с объяснения 3-2-1 подхода, быстро переходя в ответ на вопрос — почему такого подхода уже не хватает (спойлер: с шифровальщиками не помогает). Поэтому, как эволюция подхода, предлагается добавить 1 иммутабельную копию, отключенную от интернета и 0 ошибок от проверки восстановления (поэтому 3-2-1-1-0). Далее рассказывается, как реализовать новое правило: локальный бекап на диске, второй бекап на другом носителе, cloud copy, копия на ленте/в облаке с object lock и автоматизация накатки бекапов. В конце описываются best practices и FAQ (вопросы — пересказ статьи).
Русский перевод
#db #backups