Для тех кому нужно потестить скорость интернета в РФ, есть сервис Яндекса, они его щас обновили, сразу после закрытия speedtest. Мне понравилось, но количество данных которые определяет, конечно немного пугает (после запуска теста, спуститесь ниже).
https://yandex.ru/internet
https://yandex.ru/internet
yandex.ru
Яндекс Интернетометр — ваша скорость интернета
Проверка скорости интернета. IP-адрес, операционная система, версия браузера, cookies, разрешение экрана и другие параметры системы.
👍1
Бодрый кодер
Для тех кому нужно потестить скорость интернета в РФ, есть сервис Яндекса, они его щас обновили, сразу после закрытия speedtest. Мне понравилось, но количество данных которые определяет, конечно немного пугает (после запуска теста, спуститесь ниже). htt…
Я кажется придумал, что имеет смысл написать на Rust в академических целях.
❤1🤔1🐳1
Хочу сегодня поднять тему, которая наболела.
Когда ты уплачиваешь что-то государству (речь про РФ), если предусмотрено, то есть простой путь — например, просто с карты через «Госуслуги», как в случае оплаты штрафов или налогов. Но все еще возникают ситуации, когда тебе дают реквизиты для оплаты.
И там тебе нужно заполнить не просто счёт и ИНН, а убедиться, что комментарий правильный, определённые поля тоже верно заполнены. А реквизиты, даже если скидывают в электронном виде, как правило, дают без возможности копирования, чтобы ты страдал.
Для меня это всегда большой стресс, хотя можно же сделать QR, чтобы отсканировал, ввел сумму и нажал кнопку «Оплатить». Некоторые делают, например, Федеральная таможенная служба, но посредники о них не знаю, дают реквизиты и целую видеоинструкцию, в зависимости от банка, как оплатить (еще и не через каждый банк это можно сделать).
Надеюсь, с ведением цифрового рубля станет лучше, но сейчас всё ещё жесть, хотя все инструменты есть.
Я тут недавно в аренду машину брал в Чите, так там мне QR через СПБ сгенерировали за одну минуту с нужной суммой в адрес ИП.
А у вас как? Вызывает боль оплата по реквизитам?
Когда ты уплачиваешь что-то государству (речь про РФ), если предусмотрено, то есть простой путь — например, просто с карты через «Госуслуги», как в случае оплаты штрафов или налогов. Но все еще возникают ситуации, когда тебе дают реквизиты для оплаты.
И там тебе нужно заполнить не просто счёт и ИНН, а убедиться, что комментарий правильный, определённые поля тоже верно заполнены. А реквизиты, даже если скидывают в электронном виде, как правило, дают без возможности копирования, чтобы ты страдал.
Для меня это всегда большой стресс, хотя можно же сделать QR, чтобы отсканировал, ввел сумму и нажал кнопку «Оплатить». Некоторые делают, например, Федеральная таможенная служба, но посредники о них не знаю, дают реквизиты и целую видеоинструкцию, в зависимости от банка, как оплатить (еще и не через каждый банк это можно сделать).
Надеюсь, с ведением цифрового рубля станет лучше, но сейчас всё ещё жесть, хотя все инструменты есть.
Я тут недавно в аренду машину брал в Чите, так там мне QR через СПБ сгенерировали за одну минуту с нужной суммой в адрес ИП.
А у вас как? Вызывает боль оплата по реквизитам?
💯5😭2❤1
Год активно использую приложение Tappsk, его основное удобство для меня - задачи ставятся не на дату, а очень быстро по категориям - сегодня, завтра, на неделе, потом. Когда на ходу нужно записывать поток задач выходит очень эффективно.
Тут после обновления на новую MacOS, бету - перестала работать. Полез переустанавливать, и случайно увидел когда было последнее обновление - 4 года назад :( При этом на телефоне обновляется стабильно.
Может кто знает, есть похожие альтернативы?
Тут после обновления на новую MacOS, бету - перестала работать. Полез переустанавливать, и случайно увидел когда было последнее обновление - 4 года назад :( При этом на телефоне обновляется стабильно.
Может кто знает, есть похожие альтернативы?
Главная новость сегодня - Сбер вернул оплату на iPhone, с помощью Bluetooth. Хорошее решение, но мне конечно больше нравится UWB, гораздо интереснее протокол. Надеюсь когда-нибудь найду время с ним поиграться. С помощью него например можно искать вещи в помещении до сантиметров или считать людей в зале :)
🧩 Кэш в Redis: не всегда "в лоб"
Часто вижу один и тот же паттерн:
– получили данные из БД,
– положили их в Redis,
– отдали пользователю.
А потом — классический цикл "сначала лезем в кэш, если нет — идём в базу".
На первый взгляд всё красиво, но тут и кроется проблема.
👉 Основное правило при проектировании кэша — учитывать частоту обновления данных и, в зависимости от этого, строить логику инвалидации. Но данные даже внутри одной таблицы редко бывают однородными. Redis — это не просто "хранение JSON".
Например, типовой кейс:
у нас есть сущность *Post*, у неё есть "тяжёлые" атрибуты (текст, автор, дата), а есть счётчики (кол-во просмотров, лайков, комментариев).
Обновляются они с совершенно разной частотой.
Если всё хранить в одном JSON-ключе, то:
- при каждом инкременте счётчика мы будем перезаписывать весь объект,
- рискуем гонками и избыточной нагрузкой,
- теряем смысл "лёгкого" кэша.
🚀 Куда эффективнее хранить две записи:
1. сам объект (Post body),
2. отдельный ключ под счётчики.
Что это даёт:
- быстрые и атомарные обновления через
- возможность сбрасывать "тело" поста по TTL, не трогая счётчики,
- гибкость в инвалидации: разные правила для разных типов данных.
А получать данные из кэша в этом случае лучше не "в лоб" (два `GET`), а через pipeline — так мы минимизируем RTT.
Для хранения вместо JSON отлично подходят структуры Redis:
-
-
Итог: кэширование — это не "сложили JSON и забыли". Это проектирование модели данных под конкретный паттерн использования. И чем тоньше вы это сделаете, тем больше выиграете в производительности и стабильности.
💡 А у вас в проектах Redis чаще живёт как "JSON-склад" или как полноценный инструмент с типами и пайплайнами?
Часто вижу один и тот же паттерн:
– получили данные из БД,
– положили их в Redis,
– отдали пользователю.
А потом — классический цикл "сначала лезем в кэш, если нет — идём в базу".
На первый взгляд всё красиво, но тут и кроется проблема.
👉 Основное правило при проектировании кэша — учитывать частоту обновления данных и, в зависимости от этого, строить логику инвалидации. Но данные даже внутри одной таблицы редко бывают однородными. Redis — это не просто "хранение JSON".
Например, типовой кейс:
у нас есть сущность *Post*, у неё есть "тяжёлые" атрибуты (текст, автор, дата), а есть счётчики (кол-во просмотров, лайков, комментариев).
Обновляются они с совершенно разной частотой.
Если всё хранить в одном JSON-ключе, то:
- при каждом инкременте счётчика мы будем перезаписывать весь объект,
- рискуем гонками и избыточной нагрузкой,
- теряем смысл "лёгкого" кэша.
🚀 Куда эффективнее хранить две записи:
1. сам объект (Post body),
2. отдельный ключ под счётчики.
Что это даёт:
- быстрые и атомарные обновления через
INCR / HINCRBY, - возможность сбрасывать "тело" поста по TTL, не трогая счётчики,
- гибкость в инвалидации: разные правила для разных типов данных.
А получать данные из кэша в этом случае лучше не "в лоб" (два `GET`), а через pipeline — так мы минимизируем RTT.
Для хранения вместо JSON отлично подходят структуры Redis:
-
HASH (для набора атрибутов), -
STRING + INCR (для простых счётчиков). Итог: кэширование — это не "сложили JSON и забыли". Это проектирование модели данных под конкретный паттерн использования. И чем тоньше вы это сделаете, тем больше выиграете в производительности и стабильности.
💡 А у вас в проектах Redis чаще живёт как "JSON-склад" или как полноценный инструмент с типами и пайплайнами?
🔥9👍2
В комментарии к прошлому посту, попросили поделиться подробнее про pipline.
Часто кэш читают/пишут «в лоб» — по одному запросу. Но основная цена Redis в проде — это RTT (туда-обратно по сети). Pipeline позволяет отправить пачку команд за один сетевой раунд — сервер выполнит их по порядку, а ответы придут одной очередью.
Что такое pipeline (и чем он НЕ является)
- Pipeline не делает операции атомарными. Это просто «упаковка» команд в один раунд-трип.
- Для атомарности нужен
- Команды в pipeline выполняются по очереди на сервере, но клиент не ждёт ответ после каждой — экономим RTT.
---
Когда использовать
- Серии однотипных чтений/записей (например, 50 ключей
- Смешанные операции, где ответы предыдущих команд не нужны для формирования следующих.
- Интеграции «на пути» запроса (критично снижать задержку).
Когда не стоит:
- Когда следующая команда зависит от результата предыдущей → делайте двумя фазами.
- Огромные пакеты (тысячи команд) — растёт задержка одной пачки и риск таймаутов. Лучше батчить.
---
Простой пример на Go.
Часто кэш читают/пишут «в лоб» — по одному запросу. Но основная цена Redis в проде — это RTT (туда-обратно по сети). Pipeline позволяет отправить пачку команд за один сетевой раунд — сервер выполнит их по порядку, а ответы придут одной очередью.
Что такое pipeline (и чем он НЕ является)
- Pipeline не делает операции атомарными. Это просто «упаковка» команд в один раунд-трип.
- Для атомарности нужен
MULTI/EXEC (**TxPipeline** в go-redis) или Lua-скрипт, либо WATCH + TxPipelined.- Команды в pipeline выполняются по очереди на сервере, но клиент не ждёт ответ после каждой — экономим RTT.
---
Когда использовать
- Серии однотипных чтений/записей (например, 50 ключей
GET / `HGETALL`).- Смешанные операции, где ответы предыдущих команд не нужны для формирования следующих.
- Интеграции «на пути» запроса (критично снижать задержку).
Когда не стоит:
- Когда следующая команда зависит от результата предыдущей → делайте двумя фазами.
- Огромные пакеты (тысячи команд) — растёт задержка одной пачки и риск таймаутов. Лучше батчить.
---
Простой пример на Go.
package main
import (
"context"
"encoding/json"
"fmt"
"time"
"github.com/redis/go-redis/v9"
)
type Post struct {
ID, Author, Title, Content string
}
func main() {
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()
rdb := redis.NewClient(&redis.Options{Addr: "127.0.0.1:6379"})
// 1) Запись: тело поста + счётчики одним pipeline
post := Post{ID: "42", Author: "alice", Title: "Pipeline 101", Content: "…"}
body, _ := json.Marshal(post)
_, err := rdb.Pipelined(ctx, func(p redis.Pipeliner) error {
p.Set(ctx, "post:42:body", body, 10*time.Minute) // TTL у тела
p.HSet(ctx, "post:42:counters", "views", 0, "likes", 0) // счётчики отдельно
p.Persist(ctx, "post:42:counters") // живут дольше тела
return nil
})
if err != nil {
panic(err)
}
// 2) Чтение: тело + счётчики за 1 RTT
var (
bodyCmd = rdb.Get(ctx, "post:42:body")
ctrCmd = rdb.HGetAll(ctx, "post:42:counters")
)
// Внимание: без Pipelined() мы сделали 2 команды, но они уйдут подряд на одном соединении.
// Для явного пайплайна:
pipe := rdb.Pipeline()
bodyCmd = pipe.Get(ctx, "post:42:body")
ctrCmd = pipe.HGetAll(ctx, "post:42:counters")
if _, err := pipe.Exec(ctx); err != nil && err != redis.Nil {
panic(err)
}
var p Post
if b, err := bodyCmd.Bytes(); err == nil && len(b) > 0 {
_ = json.Unmarshal(b, &p)
}
counters := ctrCmd.Val()
fmt.Println("noscript:", p.Title, "views:", counters["views"])
}
👍4🔥2
Бодрый кодер
#пятничныйюмор в субботу. Пропустил
Правды ради, сейчас уже не совсем так.
Я тут поменял свою теслу на Zeekr, конечно первым делом подключил ноутбук к машине, что бы разобраться как и что, написать какие-то программы.
На фоне этого, не мог пройти мимо самой популярного тулинга, которым пользуются почти все владельцы Zeekr (Zeekr ADB toolkit). Ну познакомился с создателем. У тулинга (код только у первой версии есть), код ужасный, написанный нейросетью. Но блин, он полностью решает возложенную на него задачу и куча людей которые с компом на ВЫ, экономит и экономила десятки тысяч рублей (ценны на работу по Zeekr просто космос, как и на Tesla в принципе).
Оказалось что создатель тулинга - фотограф, и просто за счет нейросетей прокачался так, что я был уверен - говорю с разработчиком. Для него это стало отдушиной от работы. И все благодаря GPT.
Я это к чему, нейросети - классно, но не нужно рассчитывать что они сделают за вас, а это большая возможность облегчить себе работу, быстро решить задачи и научиться тому, что никогда не делали.
Я тут поменял свою теслу на Zeekr, конечно первым делом подключил ноутбук к машине, что бы разобраться как и что, написать какие-то программы.
На фоне этого, не мог пройти мимо самой популярного тулинга, которым пользуются почти все владельцы Zeekr (Zeekr ADB toolkit). Ну познакомился с создателем. У тулинга (код только у первой версии есть), код ужасный, написанный нейросетью. Но блин, он полностью решает возложенную на него задачу и куча людей которые с компом на ВЫ, экономит и экономила десятки тысяч рублей (ценны на работу по Zeekr просто космос, как и на Tesla в принципе).
Оказалось что создатель тулинга - фотограф, и просто за счет нейросетей прокачался так, что я был уверен - говорю с разработчиком. Для него это стало отдушиной от работы. И все благодаря GPT.
Я это к чему, нейросети - классно, но не нужно рассчитывать что они сделают за вас, а это большая возможность облегчить себе работу, быстро решить задачи и научиться тому, что никогда не делали.
❤8👍3
Рубисты могут сильно сэкономить. Среда разработки RubyMine от JetBrains стала бесплатной для некоммерческого использования
В 2024 году JetBrains сделала бесплатными для некоммерческого использования WebStorm, Rider и RustRover. В начале 2025 года к списку добавили CLion, а сейчас — RubyMine.
По бесплатной некоммерческой лицензии доступны все функции IDE, кроме Code With Me. Для доступа к ней надо оформлять подписку.
В 2024 году JetBrains сделала бесплатными для некоммерческого использования WebStorm, Rider и RustRover. В начале 2025 года к списку добавили CLion, а сейчас — RubyMine.
По бесплатной некоммерческой лицензии доступны все функции IDE, кроме Code With Me. Для доступа к ней надо оформлять подписку.
❤🔥7🌚2
Который раз убеждаюсь — профессия разработчика не даёт заскучать. Каждый день узнаёшь что-то новое.
Недавно со мной поделились интересной находкой: оказывается, в Nginx Ingress есть встроенная поддержка телеметрии. Можно буквально «из коробки» настроить отправку трейсов в OTLP, например, в Jaeger.
Я-то всегда был уверен, что в бесплатном Nginx такой возможности нет, и даже мысли не возникало искать её в Ingress. А зря 🙂
И самое приятное: даже для «чистого» бесплатного Nginx тоже есть решение — nginx-otel. Судя по описанию, этот модуль работает аж в 4 раза эффективнее официального варианта из Nginx Plus.
#nginx #otel #observability #devops #ingress
Недавно со мной поделились интересной находкой: оказывается, в Nginx Ingress есть встроенная поддержка телеметрии. Можно буквально «из коробки» настроить отправку трейсов в OTLP, например, в Jaeger.
Я-то всегда был уверен, что в бесплатном Nginx такой возможности нет, и даже мысли не возникало искать её в Ingress. А зря 🙂
И самое приятное: даже для «чистого» бесплатного Nginx тоже есть решение — nginx-otel. Судя по описанию, этот модуль работает аж в 4 раза эффективнее официального варианта из Nginx Plus.
#nginx #otel #observability #devops #ingress
GitHub
nginx-otel/README.md at main · nginxinc/nginx-otel
Contribute to nginxinc/nginx-otel development by creating an account on GitHub.
👍8
Самое смешное
Как правило растут, видимо ждали AI, но его не будет еще год.
Акции Apple начали падать после презентации новых гаджетов
Как правило растут, видимо ждали AI, но его не будет еще год.
Начался учебный год — у меня ещё нет пар, но в преддверии занятий делюсь полезной заметкой по БД. Часто вижу, как «на всякий случай» выбирают типы побольше — в итоге едим место, замедляем индексы и ловим баги.
❌ Антипаттерны, которые встречаю:
-
-
-
-
✅ Как делаю сам:
- Строки — по задаче:
- Деньги — только
- Булево —
- Даты/время —
- Автонумерация —
📌 Пример
-- Плохо
price FLOAT;
-- Хорошо
price NUMERIC(10,2);
⚡️ Итог: грамотный выбор типов = меньше места, быстрее запросы, меньше багов.
#БД #SQL #PostgreSQL #Оптимизация #Backend #DataEngineering
❌ Антипаттерны, которые встречаю:
-
VARCHAR(255) «для всего подряд», даже если код фиксированной длины (например, 10 символов).-
TEXT для email-адресов.-
BIGINT для счётчика, где максимум — тысяча записей.-
FLOAT для денег (теряется точность).✅ Как делаю сам:
- Строки — по задаче:
VARCHAR(254)`/`VARCHAR(320) для email (под стандарты), CHAR(2) для кода страны.- Деньги — только
NUMERIC(10,2) / DECIMAL(10,2) или целые «копейки/центы» в INT`/`BIGINT.- Булево —
BOOLEAN, а не INT.- Даты/время —
DATE / TIMESTAMP, не строка.- Автонумерация —
INT по умолчанию; BIGINT — только если реально ждёте > 2 млрд строк.📌 Пример
-- Плохо
price FLOAT;
-- Хорошо
price NUMERIC(10,2);
⚡️ Итог: грамотный выбор типов = меньше места, быстрее запросы, меньше багов.
#БД #SQL #PostgreSQL #Оптимизация #Backend #DataEngineering
🔥12👍3⚡1
В продолжении поста про PostgreSQL, поделюсь про Redis. Чаще всего используют только строку, но он гораздо многообразнее.
🧱 String
— Ключ-значение, базовый кирпич. Кэш, флаги, счётчики, токены.
— Пример:
— Паттерны: rate-limit (`INCR + EXPIRE`), простые распределённые блокировки (`SET lock val NX PX 10000`)
🧩 Hash
— «Объект» с полями: компактно хранит мелкие атрибуты.
— Пример:
— Когда: профили пользователей, настройки. Плюс — частичные обновления полей.
— Нюанс: нет TTL на отдельные поля, ставится на весь ключ.
📚 List
— Упорядоченная коллекция. Очереди (FIFO/LIFO), буферы, журналы.
— Пример:
— Когда: простые очереди, ретраи. Не забывайте
🏷 Set
— Множества без дубликатов. Теги, интересы, подписки.
— Пример:
— Когда: рекомендации по пересечению множеств, дедупликация.
🏆 Sorted Set (ZSet)
— Множество с весом (score). Рейтинги, приоритизация, «календарь по времени».
— Пример:
— Когда: топ-N, очереди с приоритетом, time-index (`score = timestamp`).
— Хитрость: чистка старых данных —
🧮 Bitmap
— Битовые флаги по смещению. Ультра-дешёвая памятью аналитика по дням.
— Примеры
— Когда: «приходил ли пользователь в день D», воронки по дням, календари активности.
📏 Bitfield
— Упакованные счётчики/флаги в одном ключе.
— Пример:
— Когда: компактные счётчики для ограниченного диапазона (экономия памяти).
🔢 HyperLogLog
— Приблизительное количество уникальных (distinct).
— Пример:
— Когда: уникальные посетители/поисковые запросы, где допустима погрешность.
📍 GEO (геоиндексы)
— Геопоиск по радиусу/полигону.
— Пример:
— Когда: «что рядом», ближайшие точки интереса.
📨 Streams
— Лог событий с потребительскими группами (Kafka-лайт).
— Пример:
— Когда: event sourcing, обработка событий с подтверждениями.
📣 Pub/Sub
— Эфемерные сообщения «здесь и сейчас».
— Пример:
— Когда: оповещения в реальном времени, без хранения истории (не путать со Streams).
🧾 RedisJSON (Redis 8+)
— Хранение JSON как дерево, выборка/патчи по путям.
— Пример:
— Когда: нужны частичные обновления и индексирование полей (с RediSearch).
— Альтернатива: String с сериализацией — просто, но без частичных апдейтов.
🧠 Итог
— В Redis выбор структуры = половина решения. Строка с JSON — ок для простого кэша, но для очередей, рейтингов, счётчиков и аналитики есть куда более точные инструменты.
#Redis #БД #Кэширование #Backend #Шпаргалка #DataEngineering
🧱 String
— Ключ-значение, базовый кирпич. Кэш, флаги, счётчики, токены.
— Пример:
SET key val, GET key, INCR views, SETNX, EXPIRE key 60— Паттерны: rate-limit (`INCR + EXPIRE`), простые распределённые блокировки (`SET lock val NX PX 10000`)
🧩 Hash
— «Объект» с полями: компактно хранит мелкие атрибуты.
— Пример:
HSET user:42 name Lev email lev@..., HGETALL user:42— Когда: профили пользователей, настройки. Плюс — частичные обновления полей.
— Нюанс: нет TTL на отдельные поля, ставится на весь ключ.
📚 List
— Упорядоченная коллекция. Очереди (FIFO/LIFO), буферы, журналы.
— Пример:
LPUSH queue job1, BRPOP queue 0— Когда: простые очереди, ретраи. Не забывайте
LTRIM для ограничения длины.🏷 Set
— Множества без дубликатов. Теги, интересы, подписки.
— Пример:
SADD tags:post:1 go devops, SINTER user:42:tags post:1:tags— Когда: рекомендации по пересечению множеств, дедупликация.
🏆 Sorted Set (ZSet)
— Множество с весом (score). Рейтинги, приоритизация, «календарь по времени».
— Пример:
ZADD leaderboard 1500 user42, ZRANGE leaderboard 0 9 WITHSCORES— Когда: топ-N, очереди с приоритетом, time-index (`score = timestamp`).
— Хитрость: чистка старых данных —
ZREMRANGEBYSCORE.🧮 Bitmap
— Битовые флаги по смещению. Ультра-дешёвая памятью аналитика по дням.
— Примеры
SETBIT active:2025-09-10 42 1, BITCOUNT active:*— Когда: «приходил ли пользователь в день D», воронки по дням, календари активности.
📏 Bitfield
— Упакованные счётчики/флаги в одном ключе.
— Пример:
BITFIELD key INCRBY u8 10 1— Когда: компактные счётчики для ограниченного диапазона (экономия памяти).
🔢 HyperLogLog
— Приблизительное количество уникальных (distinct).
— Пример:
PFADD u:visits user42, PFCOUNT u:visits— Когда: уникальные посетители/поисковые запросы, где допустима погрешность.
📍 GEO (геоиндексы)
— Геопоиск по радиусу/полигону.
— Пример:
GEOADD places 13.405 52.52 berlin, GEOSEARCH places FROMLONLAT 13.4 52.5 BYRADIUS 5 km— Когда: «что рядом», ближайшие точки интереса.
📨 Streams
— Лог событий с потребительскими группами (Kafka-лайт).
— Пример:
XADD events * type=signup user=42, XREADGROUP GROUP g c COUNT 10 STREAMS events >— Когда: event sourcing, обработка событий с подтверждениями.
📣 Pub/Sub
— Эфемерные сообщения «здесь и сейчас».
— Пример:
PUBLISH chan msg, SUBSCRIBE chan— Когда: оповещения в реальном времени, без хранения истории (не путать со Streams).
🧾 RedisJSON (Redis 8+)
— Хранение JSON как дерево, выборка/патчи по путям.
— Пример:
JSON.SET user:42 $ '{"name":"Lev","age":33}', JSON.NUMINCRBY user:42 $.age 1— Когда: нужны частичные обновления и индексирование полей (с RediSearch).
— Альтернатива: String с сериализацией — просто, но без частичных апдейтов.
🧠 Итог
— В Redis выбор структуры = половина решения. Строка с JSON — ок для простого кэша, но для очередей, рейтингов, счётчиков и аналитики есть куда более точные инструменты.
#Redis #БД #Кэширование #Backend #Шпаргалка #DataEngineering
❤6👍5🔥2❤🔥1
Нашел прям лучший подход по видению ToDo.
То есть не просто пишешь, а потом в IDE контролируешь, а сразу завешиваешь задачу. Прям гениально и просто.
P. S. Понятно что все равно не гарантия исправления.
# TODO(DEV-12346): Надо поправить конфиг
То есть не просто пишешь, а потом в IDE контролируешь, а сразу завешиваешь задачу. Прям гениально и просто.
P. S. Понятно что все равно не гарантия исправления.
👍3🔥1