Redisearch vs Elasticsearch
Недавно мне коллега сказал: "Смотри, есть реализация эластика на редисе". Я заинтригованно полез разбираться, и вот краткое сравнение.
🔹 Скорость - Redisearch живёт прямо в памяти Redis, поэтому поиск и фильтрация там работают в миллисекунды. На ограниченных объёмах данных (до пары миллионов документов) он часто быстрее Elasticsearch.
🔹 Масштаб - Elasticsearch изначально распределённый, работает с терабайтами данных и десятками узлов без костылей. Redisearch масштабировать сложнее, особенно в open-source варианте, и он упирается в доступную RAM.
🔹 Функциональность - у Redisearch есть полнотекст, фильтры, базовые агрегации, гео и даже векторный поиск. Но Elastic гибче: тонкие настройки анализа текста, сложные агрегации, nested-объекты и аналитика из коробки.
🔹 Интеграция в Go - Redisearch прост: подключил модуль к Redis и работаешь через лёгкий Go-клиент. Elastic требует поднять отдельный сервис и работать по REST, но возможностей у него больше.
Вывод: Redisearch это отличное решение, если нужен сверхбыстрый поиск по данным, которые уже в Redis, и объёмы укладываются в память. Но область применения узкая: для больших и сложных поисковых задач Elasticsearch остаётся более универсальным выбором. Однако сделано конечно интересно, для расширения кругозора думаю стоит изучить технологию.
Недавно мне коллега сказал: "Смотри, есть реализация эластика на редисе". Я заинтригованно полез разбираться, и вот краткое сравнение.
🔹 Скорость - Redisearch живёт прямо в памяти Redis, поэтому поиск и фильтрация там работают в миллисекунды. На ограниченных объёмах данных (до пары миллионов документов) он часто быстрее Elasticsearch.
🔹 Масштаб - Elasticsearch изначально распределённый, работает с терабайтами данных и десятками узлов без костылей. Redisearch масштабировать сложнее, особенно в open-source варианте, и он упирается в доступную RAM.
🔹 Функциональность - у Redisearch есть полнотекст, фильтры, базовые агрегации, гео и даже векторный поиск. Но Elastic гибче: тонкие настройки анализа текста, сложные агрегации, nested-объекты и аналитика из коробки.
🔹 Интеграция в Go - Redisearch прост: подключил модуль к Redis и работаешь через лёгкий Go-клиент. Elastic требует поднять отдельный сервис и работать по REST, но возможностей у него больше.
Вывод: Redisearch это отличное решение, если нужен сверхбыстрый поиск по данным, которые уже в Redis, и объёмы укладываются в память. Но область применения узкая: для больших и сложных поисковых задач Elasticsearch остаётся более универсальным выбором. Однако сделано конечно интересно, для расширения кругозора думаю стоит изучить технологию.
❤4⚡2
Отпуск завершился.
Планы были амбициозные - сделал не всё, зато появился понятный проект для комьюнити.
Готовлю бесплатный курс по Go на YouTube. За 17 коротких уроков соберём веб-сервис по мотивам Тамагочи 90х 🐣. Начнем с простого CRUD и пойдем к продакшн уровню. Каждая серия должна закрыть реальную полезную тему, без воды.
По срокам ничего сказать не могу, начинаю потихоньку записывать скринкасты. Буду нет-нет писать о ходе работ над курсом в этом канале.
Предварительный план уроков
1. Запуск базового REST сервера
2. Middleware
3. Подключение фреймворка chi
4. Конфигурация сервиса
5. Настройка REST клиента
6. Логирование
7. Сжатие запросов и ответов
8. Контекст
9. Рефакторингговно-кода на слоистую архитектуру
10. Тестирование
11. Обработка ошибок
12. Подключение базы данных PostgreSQL
13. Метрики и мониторинг
14. gRPC
15. Трассировка
16. Профилирование и оптимизация
17. Кэширование
Чего может не хватать чтобы курс закрывал больше боевых кейсов в проде? Напишите свои идеи в комментариях, попробую добавить их в план курса.
Планы были амбициозные - сделал не всё, зато появился понятный проект для комьюнити.
Готовлю бесплатный курс по Go на YouTube. За 17 коротких уроков соберём веб-сервис по мотивам Тамагочи 90х 🐣. Начнем с простого CRUD и пойдем к продакшн уровню. Каждая серия должна закрыть реальную полезную тему, без воды.
По срокам ничего сказать не могу, начинаю потихоньку записывать скринкасты. Буду нет-нет писать о ходе работ над курсом в этом канале.
Предварительный план уроков
1. Запуск базового REST сервера
2. Middleware
3. Подключение фреймворка chi
4. Конфигурация сервиса
5. Настройка REST клиента
6. Логирование
7. Сжатие запросов и ответов
8. Контекст
9. Рефакторинг
10. Тестирование
11. Обработка ошибок
12. Подключение базы данных PostgreSQL
13. Метрики и мониторинг
14. gRPC
15. Трассировка
16. Профилирование и оптимизация
17. Кэширование
Чего может не хватать чтобы курс закрывал больше боевых кейсов в проде? Напишите свои идеи в комментариях, попробую добавить их в план курса.
⚡3🔥3❤1
🚀 Вышел Go 1.25!
Главное в обновлении: Go стал умнее в контейнерах. Теперь сам ограничивает потоки под лимиты CPU (больше никаких 20 goroutines на 0.5 CPU в Kubernetes 😅).
Завезли супер-быстрый JSON v2 (пока экспериментально). Обещают куда шустрое распарсивание JSON и новые удобные API для маршалинга.
Появился экспериментальный GC "Green Tea", который в тестах на 10-40% снижает накладные расходы сборщика мусора.
Из мелочей: добавили метод
Мне больше всего понравилась авто-настройка GOMAXPROCS и новый JSON - я уже побежали бенчмаркать его в своих сервисах.
А вот что немного раскритиковали - так это отсутствие шагов по сокращению шаблона
Впрочем, релиз получился очень полезным: быстрее, безопаснее, удобнее. Лично мне не терпится включить JSON/v2 и "зелёный" GC в парочке проектов и посмотреть на результат.
Попробуйте и вы, поделитесь впечатлениями! 😉
Главное в обновлении: Go стал умнее в контейнерах. Теперь сам ограничивает потоки под лимиты CPU (больше никаких 20 goroutines на 0.5 CPU в Kubernetes 😅).
Завезли супер-быстрый JSON v2 (пока экспериментально). Обещают куда шустрое распарсивание JSON и новые удобные API для маршалинга.
Появился экспериментальный GC "Green Tea", который в тестах на 10-40% снижает накладные расходы сборщика мусора.
Из мелочей: добавили метод
WaitGroup.Go (минус шаблон Add(1)+go+Done, ура удобству!), пакет testing/synctest для тестов с синтетическим временем (прощай time.Sleep в тестах 🎉), новый net/http-защитник от CSRF и пачку оптимизаций в crypto (прощай SHA-1).Мне больше всего понравилась авто-настройка GOMAXPROCS и новый JSON - я уже побежали бенчмаркать его в своих сервисах.
А вот что немного раскритиковали - так это отсутствие шагов по сокращению шаблона
if err != nil 🙈 (Go как был консервативен в error handling, так и остался). Впрочем, релиз получился очень полезным: быстрее, безопаснее, удобнее. Лично мне не терпится включить JSON/v2 и "зелёный" GC в парочке проектов и посмотреть на результат.
Попробуйте и вы, поделитесь впечатлениями! 😉
🔥5
Кажется, уже совсем взрослый, хотя ощущается это не всегда 🙂
Топ мыслей, которые приходят в голову, когда смотришь назад:
- Люби и цени родителей. Время с ними бесценно и конечно.
- Релизить в пятницу вечером нельзя, даже если очень сильно хочется.
- Стройность тела уходит - думай о питании.
- Не думай о деньгах, они придут если развиваться.
- Волосы уходят - лучше вообще много не думай...
Коллеги в этом году порадовали подарком: майка CI/CD PIPELINE TO HELL. Разговаривали о ней почти полтора года и вот она у меня. На конвертах написано "Дорогому дедушке" и "Любимой Бабушке". Люблю свою команду. Креативные они у меня 😊
В общем и целом я свой день рождения не праздную, по личным причинам. Мне сложно этот день воспринимать как "праздник", но в прошлом году решил посидеть с коллегами в караоке. И в целом было довольно неплохо.
Может, и в этом году стоит выйти в свет?
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8🔥2🏆1💋1
Почему зарплаты редко пишут в вакансиях
Официальный ответ HR: "всё зависит от кандидата".
Неофициальный: "не хотим раскрывать карты конкурентам".
Для разработчика выглядит забавно. Ты проходишь несколько этапов собеса, тратишь кучу времени, и только в конце выясняется, что условия не совпадают с ожиданиями.
Самое смешное, что рынок и так прозрачен. Пара разговоров с коллегами за кофе дают картину честнее, чем любая вакансия.
Может когда-нибудь у нас тоже будут указывать вилки в открытую. Но пока живём в реальности "обсудим ближе к офферу".
P.S. на постере какой-то лысый парень с бородой держит карточки, которые просвечивают с обратной стороны. Задумайтесь...
Официальный ответ HR: "всё зависит от кандидата".
Неофициальный: "не хотим раскрывать карты конкурентам".
Для разработчика выглядит забавно. Ты проходишь несколько этапов собеса, тратишь кучу времени, и только в конце выясняется, что условия не совпадают с ожиданиями.
Самое смешное, что рынок и так прозрачен. Пара разговоров с коллегами за кофе дают картину честнее, чем любая вакансия.
Может когда-нибудь у нас тоже будут указывать вилки в открытую. Но пока живём в реальности "обсудим ближе к офферу".
P.S. на постере какой-то лысый парень с бородой держит карточки, которые просвечивают с обратной стороны. Задумайтесь...
👍2💯1
Преимущества работы удалённо
Удалённая работа многим кажется мечтой: проснулся, включил ноутбук и ты уже "в офисе". Но на самом деле всё не так просто. Эффективность дома напрямую зависит от того, насколько ты умеешь выстраивать рамки и дисциплину.
Если относиться к удалёнке как к полноценной работе, то уровень фокуса может быть даже выше, чем в офисе. Никто не отвлекает вопросами за спиной, можно погрузиться в задачу и держать концентрацию часами. У меня именно в такие дни получается делать самый качественный код и закрывать сложные технические вопросы, которые требуют максимальной глубины.
Ещё одно преимущество - возможность настроить рабочее пространство под себя. Техника, освещение, стул, клавиатура, кальян - всё то, что реально влияет на продуктивность (кроме наверное кальяна) и комфорт, дома легко организовать под себя. В офисе так не всегда получается (с кальяном не получается никогда).
Но есть и обратная сторона. Чтобы что-то обсудить, нужно вылавливать людей в чате или ждать созвона. Иногда это превращается в длинную переписку, которая убивает весь выигрыш по времени. Коммуникация становится сложнее, а решения, которые в офисе занимают 5 минут, могут растянуться на часы.
Плюс дома всегда есть риск стереть границы между работой и личной жизнью. Часто на удалёнке ты овертаймишь, из-за этого удалёнка превращается не в свободу, а в постоянное ощущение, что работа не заканчивается.
Для меня удалёнка - это инструмент. Она позволяет сосредоточиться на своих задачах и сделать работу глубже. Но без зрелости процессов и культуры труда легко оказаться в ловушке: вроде сидишь дома и работаешь, а работа всё никак не заканчивается.
Удалённая работа многим кажется мечтой: проснулся, включил ноутбук и ты уже "в офисе". Но на самом деле всё не так просто. Эффективность дома напрямую зависит от того, насколько ты умеешь выстраивать рамки и дисциплину.
Если относиться к удалёнке как к полноценной работе, то уровень фокуса может быть даже выше, чем в офисе. Никто не отвлекает вопросами за спиной, можно погрузиться в задачу и держать концентрацию часами. У меня именно в такие дни получается делать самый качественный код и закрывать сложные технические вопросы, которые требуют максимальной глубины.
Ещё одно преимущество - возможность настроить рабочее пространство под себя. Техника, освещение, стул, клавиатура, кальян - всё то, что реально влияет на продуктивность (кроме наверное кальяна) и комфорт, дома легко организовать под себя. В офисе так не всегда получается (с кальяном не получается никогда).
Но есть и обратная сторона. Чтобы что-то обсудить, нужно вылавливать людей в чате или ждать созвона. Иногда это превращается в длинную переписку, которая убивает весь выигрыш по времени. Коммуникация становится сложнее, а решения, которые в офисе занимают 5 минут, могут растянуться на часы.
Плюс дома всегда есть риск стереть границы между работой и личной жизнью. Часто на удалёнке ты овертаймишь, из-за этого удалёнка превращается не в свободу, а в постоянное ощущение, что работа не заканчивается.
Для меня удалёнка - это инструмент. Она позволяет сосредоточиться на своих задачах и сделать работу глубже. Но без зрелости процессов и культуры труда легко оказаться в ловушке: вроде сидишь дома и работаешь, а работа всё никак не заканчивается.
💯4
This media is not supported in your browser
VIEW IN TELEGRAM
Преимущества работы в офисе Uzinfocom
Работа в офисе это про энергию команды. Когда рядом коллеги, многие задачи решаются быстрее. Не нужно писать длинные сообщения или ждать, пока кто-то освободится на звонок. Достаточно подойти, обсудить пару минут - и можно сразу продолжать работу. В итоге проекты двигаются заметно быстрее.
Есть и нематериальные плюсы. Офис создаёт ощущение ритма: ты видишь, как команда включается в задачи, и сам быстрее настраиваешься на рабочую волну. Это как в спорте - когда тренируешься один, результат есть, но в команде прогресс ощущается сильнее. Живое общение, быстрые обсуждения, общие шутки - всё это формирует атмосферу, которую трудно воспроизвести удалённо.
Отдельный момент, сам офис Uzinfocom. Тут реально приятно находиться: удобные рабочие места, хороший свет, комфортная атмосфера, гитара, родные лица которые на ней играют и т.д.
Конечно, у офиса есть и обратная сторона. Когда людей много и работа кипит, переключений контекста становится больше. Иногда только погрузился в задачу - и вот кто-то подошел о чем-то спросить или рассказать и ты снова потерял мысль. В такие моменты глубокая работа даётся сложнее. Приходится выстраивать границы и сознательно планировать время для задач, требующих максимальной концентрации (спойлер, у меня это до сих пор не выходит).
Что касается дороги. Для многих время потраченное в дороге это минус, но для меня это скорее бонус. Она занимает не так много времени, и я слушаю профильные подкасты. Получается, что дорога это возможность переключиться и настроиться на рабочий день.
В итоге офис для меня это драйв, командная энергия и быстрые решения. А шум и отвлечения - вопрос привычки и дисциплины.
P.S. На видео пытался простым языком объяснить как работают сложные фильтры терминологических ресурсов FHIR для отдела аналитики и части разработчиков.
Работа в офисе это про энергию команды. Когда рядом коллеги, многие задачи решаются быстрее. Не нужно писать длинные сообщения или ждать, пока кто-то освободится на звонок. Достаточно подойти, обсудить пару минут - и можно сразу продолжать работу. В итоге проекты двигаются заметно быстрее.
Есть и нематериальные плюсы. Офис создаёт ощущение ритма: ты видишь, как команда включается в задачи, и сам быстрее настраиваешься на рабочую волну. Это как в спорте - когда тренируешься один, результат есть, но в команде прогресс ощущается сильнее. Живое общение, быстрые обсуждения, общие шутки - всё это формирует атмосферу, которую трудно воспроизвести удалённо.
Отдельный момент, сам офис Uzinfocom. Тут реально приятно находиться: удобные рабочие места, хороший свет, комфортная атмосфера, гитара, родные лица которые на ней играют и т.д.
Конечно, у офиса есть и обратная сторона. Когда людей много и работа кипит, переключений контекста становится больше. Иногда только погрузился в задачу - и вот кто-то подошел о чем-то спросить или рассказать и ты снова потерял мысль. В такие моменты глубокая работа даётся сложнее. Приходится выстраивать границы и сознательно планировать время для задач, требующих максимальной концентрации (спойлер, у меня это до сих пор не выходит).
Что касается дороги. Для многих время потраченное в дороге это минус, но для меня это скорее бонус. Она занимает не так много времени, и я слушаю профильные подкасты. Получается, что дорога это возможность переключиться и настроиться на рабочий день.
В итоге офис для меня это драйв, командная энергия и быстрые решения. А шум и отвлечения - вопрос привычки и дисциплины.
P.S. На видео пытался простым языком объяснить как работают сложные фильтры терминологических ресурсов FHIR для отдела аналитики и части разработчиков.
🔥2
Офис или удалёнка? Мой выбор - гибрид
После пары постов про плюсы и минусы офисной и удалённой работы хочу подвести итог.
Правда в том, что нет универсального лучшего формата. Всё зависит от самого человека, его задач и культуры команды.
Офис даёт энергию коллектива. Там решения принимаются быстрее, проще оставаться в контексте и чувствовать себя частью общего движения. Но при этом приходится мириться с постоянными переключениями контекста и шумом.
Удалёнка, наоборот, даёт максимальный фокус. Дома проще закрывать сложные задачи, которые требуют глубокой концентрации. Но цена за это - более тяжёлая коммуникация и риск размыть границы между работой и личной жизнью.
Лично для меня лучший формат это гибрид. Большую часть недели я провожу в офисе: включаюсь в командный ритм, обсуждаю идеи, ловлю энергию коллег. Но оставляю время и на удалённую работу, чтобы сосредоточиться на своих задачах без лишних отвлечений. Такой баланс позволяет и быть в потоке команды, и при этом не терять глубину.
Интересно узнать какой формат эффективнее именно для вас и почему?
После пары постов про плюсы и минусы офисной и удалённой работы хочу подвести итог.
Правда в том, что нет универсального лучшего формата. Всё зависит от самого человека, его задач и культуры команды.
Офис даёт энергию коллектива. Там решения принимаются быстрее, проще оставаться в контексте и чувствовать себя частью общего движения. Но при этом приходится мириться с постоянными переключениями контекста и шумом.
Удалёнка, наоборот, даёт максимальный фокус. Дома проще закрывать сложные задачи, которые требуют глубокой концентрации. Но цена за это - более тяжёлая коммуникация и риск размыть границы между работой и личной жизнью.
Лично для меня лучший формат это гибрид. Большую часть недели я провожу в офисе: включаюсь в командный ритм, обсуждаю идеи, ловлю энергию коллег. Но оставляю время и на удалённую работу, чтобы сосредоточиться на своих задачах без лишних отвлечений. Такой баланс позволяет и быть в потоке команды, и при этом не терять глубину.
Интересно узнать какой формат эффективнее именно для вас и почему?
🔥3❤1👍1
Самодисциплина - это не про армейский режим, а про простые договорённости с самим собой.
Помните, я писал про утренние тренировки в 7 утра? Эксперимент продолжается - и держится он не на мотивации, а именно на дисциплине. Мотивация встаёт редко, а привычка - каждый день.
То же самое было с блогом. В начале тяжело - "о чём писать?", "кому это нужно?". Но я решил: хотя бы раз в неделю будет пост. И вот уже идёт второй месяц, а писать стало легче, чем не писать.
Вывод: дисциплина сначала кажется ограничением, а потом превращается в свободу. Потому что не нужно каждый раз принимать решение, оно уже принято, один раз.
P.S. На постере какой-то лысый парень с бородой и в очках делает то, о чем мы все так мечтаем... Утренняя пробежка...
Помните, я писал про утренние тренировки в 7 утра? Эксперимент продолжается - и держится он не на мотивации, а именно на дисциплине. Мотивация встаёт редко, а привычка - каждый день.
То же самое было с блогом. В начале тяжело - "о чём писать?", "кому это нужно?". Но я решил: хотя бы раз в неделю будет пост. И вот уже идёт второй месяц, а писать стало легче, чем не писать.
Вывод: дисциплина сначала кажется ограничением, а потом превращается в свободу. Потому что не нужно каждый раз принимать решение, оно уже принято, один раз.
P.S. На постере какой-то лысый парень с бородой и в очках делает то, о чем мы все так мечтаем... Утренняя пробежка...
🔥4
BASCODE
Это я в очередном походе, чуть не вырубился от усталости. Сейчас уже дома лежу и плачу…
Последний пост был месяц назад. Там говорилось о том, что я чуть не вырубился от усталости.
Нет я не умер. Все со мной хорошо )
Мы сдаем 1 wave и сейчас вся ментальная энергия уходит на проект.
Нет я не умер. Все со мной хорошо )
Мы сдаем 1 wave и сейчас вся ментальная энергия уходит на проект.
👍6
Как Go написан на Go, или История одного парадокса.
Сегодня коллега задал вопрос, который заставил меня улыбнуться: "Как вообще может быть, что Go написан на Go?" И правда, звучит парадоксально, но за этим стоит красивая инженерная история.
Изначально компилятор Go был написан на C. Кен Томпсон и команда начали именно так в 2007 году, используя yacc для парсера. Это логично... Нужно же было с чего-то начать. Первые версии Go (с 1.0 до 1.4) компилировались именно C-компилятором. Но у команды был план.
В 2013 году началась большая работа по переписыванию компилятора на сам Go. Процесс был хитрый: сначала написали транслятор, который автоматически переводил C-код в Go-код, затем постепенно рефакторили и переписывали части вручную. К версии 1.5 (август 2015) компилятор Go полностью стал self-hosted, то есть написан на том же языке, который компилирует.
Зачем это было нужно? Во-первых, dogfooding. Команда Go теперь сама использует свой язык для самых критичных компонентов, что заставляет делать его лучше. Во-вторых, барьер входа для контрибьюторов резко снизился, не нужно знать C, чтобы улучшать компилятор Go. В-третьих, все оптимизации и улучшения языка автоматически ускоряют и сам компилятор.
Я регулярно заглядываю в исходники компилятора, чтобы понять, как работают сложные вещи и как пишут код лучшие умы. И знаете что? Код там удивительно читаемый! Это отличный пример того, как писать на Go правильно, просто, понятно и эффективно.
P.S. Кстати, процесс, когда компилятор языка написан на самом языке, называется bootstrapping. И да, для первой компиляции нового компилятора Go вам всё ещё нужна предыдущая версия Go. Вот такая рекурсия 🔄
Сегодня коллега задал вопрос, который заставил меня улыбнуться: "Как вообще может быть, что Go написан на Go?" И правда, звучит парадоксально, но за этим стоит красивая инженерная история.
Изначально компилятор Go был написан на C. Кен Томпсон и команда начали именно так в 2007 году, используя yacc для парсера. Это логично... Нужно же было с чего-то начать. Первые версии Go (с 1.0 до 1.4) компилировались именно C-компилятором. Но у команды был план.
В 2013 году началась большая работа по переписыванию компилятора на сам Go. Процесс был хитрый: сначала написали транслятор, который автоматически переводил C-код в Go-код, затем постепенно рефакторили и переписывали части вручную. К версии 1.5 (август 2015) компилятор Go полностью стал self-hosted, то есть написан на том же языке, который компилирует.
Зачем это было нужно? Во-первых, dogfooding. Команда Go теперь сама использует свой язык для самых критичных компонентов, что заставляет делать его лучше. Во-вторых, барьер входа для контрибьюторов резко снизился, не нужно знать C, чтобы улучшать компилятор Go. В-третьих, все оптимизации и улучшения языка автоматически ускоряют и сам компилятор.
Я регулярно заглядываю в исходники компилятора, чтобы понять, как работают сложные вещи и как пишут код лучшие умы. И знаете что? Код там удивительно читаемый! Это отличный пример того, как писать на Go правильно, просто, понятно и эффективно.
P.S. Кстати, процесс, когда компилятор языка написан на самом языке, называется bootstrapping. И да, для первой компиляции нового компилятора Go вам всё ещё нужна предыдущая версия Go. Вот такая рекурсия 🔄
🔥4
Почему я больше не читаю книги по программированию.
Тяну с постами, знаю. Вся ментальная энергия уходит на проект. Цифровизация медицины целой страны всё-таки кроет личный бренд.
Идея поста не моя, а навеянная коллегой @nebeskkkore. Нн попросил составить топ книг по программированию. Придётся его расстроить... В 2025 году читать техническую литературу это как изучать карту метро по фотографиям 80-х.
Индустрия развивается с около-световой скоростью. Пока книга проходит путь от идеи до печати, технология успевает выпустить три мажорные версии и признать половину подходов устаревшими. ИМХО: изданная книга уже легаси.
Мой подход к изучению простой и, возможно, экстремальный.
- Нужна глубина? Читаю исходники. Лучшей школы программирования не найти. Там код от людей, которые понимают, что делают.
- Нужна ширина? Подкасты в дороге, конференции, хабр за кофе или на унитазе.
Но всё же есть книги-нетленки, которые стоит прочитать:
1. Клеппман "Высоконагруженные приложения" - база для понимания того, как вообще работают распределённые системы, база данных, кэш и т.д. Эта книга не устареет, пока у нас есть сети и базы данных.
2. Бхаргава "Грокаем алгоритмы" - максимально простое объяснение базовых концепций. После неё хотя бы понимаешь, почему твой код работает за O(n²) и почему это плохо.
3. "Паттерны проектирования" банды четырёх - классика, хотя refactoring.guru с примерами на Go удобнее.
В следующем посте расскажу про подкасты, которые случаю ежедневно.
Еще один вброс: там, где авторы книг только планируют главу, подкастеры уже обсуждают production-опыт.
Тяну с постами, знаю. Вся ментальная энергия уходит на проект. Цифровизация медицины целой страны всё-таки кроет личный бренд.
Идея поста не моя, а навеянная коллегой @nebeskkkore. Нн попросил составить топ книг по программированию. Придётся его расстроить... В 2025 году читать техническую литературу это как изучать карту метро по фотографиям 80-х.
Индустрия развивается с около-световой скоростью. Пока книга проходит путь от идеи до печати, технология успевает выпустить три мажорные версии и признать половину подходов устаревшими. ИМХО: изданная книга уже легаси.
Мой подход к изучению простой и, возможно, экстремальный.
- Нужна глубина? Читаю исходники. Лучшей школы программирования не найти. Там код от людей, которые понимают, что делают.
- Нужна ширина? Подкасты в дороге, конференции, хабр за кофе или на унитазе.
Но всё же есть книги-нетленки, которые стоит прочитать:
1. Клеппман "Высоконагруженные приложения" - база для понимания того, как вообще работают распределённые системы, база данных, кэш и т.д. Эта книга не устареет, пока у нас есть сети и базы данных.
2. Бхаргава "Грокаем алгоритмы" - максимально простое объяснение базовых концепций. После неё хотя бы понимаешь, почему твой код работает за O(n²) и почему это плохо.
3. "Паттерны проектирования" банды четырёх - классика, хотя refactoring.guru с примерами на Go удобнее.
В следующем посте расскажу про подкасты, которые случаю ежедневно.
Еще один вброс: там, где авторы книг только планируют главу, подкастеры уже обсуждают production-опыт.
👍6❤1🔥1
Подкасты, которые держат меня в тонусе
В прошлом посте обещал рассказать про подкасты. Выполняю обещание 🎧
Дорога на работу - это не потерянное время, а возможность включить мозг еще до того, как сяду за код. 40 минут в пути превращаются в мини-тренировку для головы. К моменту, когда открываю Jira, GitLab или IDE, я уже в рабочем ритме.
Что в ротации сейчас
Радио-Т - мой главный подкаст уже много лет. Не пропустил ни одного выпуска. Бобук, если читаешь - мы все ждем твоего возвращения. Серьезно. Лучшего подкаста для того чтобы быть в курсе последних мировых новостей в IT просто не придумать.
Три тимлида заходят в бар - про менеджмент, но с IT-уклоном. Полезно, когда нужно понять, что творится по ту сторону баррикад. Лид команды без понимания менеджмента это как фронтендер без знания CSS.
Организованное программирование - подкаст от Кирилла Мокевнина, CEO Хекслета. Структурированно, без воды. Ровно то, что нужно, когда хочется систематизировать хаос в голове.
Go Get Podcast - жаль, что редко выходит. Когда выходит - слушаю обязательно. Чистый Go-контент в русскоязычном сегменте - дефицит.
Что осталось в памяти
Мы обречены - до сих пор выходят, но мне почему-то стало сложно их слушать. Для меня стало слишком много зумерского... Много нытья и философии безделья.
BeardyCast - в связи с СВО пропал из инфополя. Скучаю по ребятам.
Фронтенд Юность - настоящие рок-звезды. Хоть я уже далек от фронта, до сих пор жалко, что они перестали выпускать выпуски. Энергетика была космическая.
Понимаю, что на первый взгляд может показаться что подкастов не много, но даже этого достаточно для того чтобы выбирать какие выпуски слушать, а какие можно пропустить. Разумеется кроме Радио-Т, тут нельзя пропускать.
Подкасты - это не развлечение, а инвестиция в профессиональный рост. Пока другие листают ленту в дороге, ты можешь прокачивать экспертизу. Главное - найти свой формат и держать регулярность.
В прошлом посте обещал рассказать про подкасты. Выполняю обещание 🎧
Дорога на работу - это не потерянное время, а возможность включить мозг еще до того, как сяду за код. 40 минут в пути превращаются в мини-тренировку для головы. К моменту, когда открываю Jira, GitLab или IDE, я уже в рабочем ритме.
Что в ротации сейчас
Радио-Т - мой главный подкаст уже много лет. Не пропустил ни одного выпуска. Бобук, если читаешь - мы все ждем твоего возвращения. Серьезно. Лучшего подкаста для того чтобы быть в курсе последних мировых новостей в IT просто не придумать.
Три тимлида заходят в бар - про менеджмент, но с IT-уклоном. Полезно, когда нужно понять, что творится по ту сторону баррикад. Лид команды без понимания менеджмента это как фронтендер без знания CSS.
Организованное программирование - подкаст от Кирилла Мокевнина, CEO Хекслета. Структурированно, без воды. Ровно то, что нужно, когда хочется систематизировать хаос в голове.
Go Get Podcast - жаль, что редко выходит. Когда выходит - слушаю обязательно. Чистый Go-контент в русскоязычном сегменте - дефицит.
Что осталось в памяти
Мы обречены - до сих пор выходят, но мне почему-то стало сложно их слушать. Для меня стало слишком много зумерского... Много нытья и философии безделья.
BeardyCast - в связи с СВО пропал из инфополя. Скучаю по ребятам.
Фронтенд Юность - настоящие рок-звезды. Хоть я уже далек от фронта, до сих пор жалко, что они перестали выпускать выпуски. Энергетика была космическая.
Понимаю, что на первый взгляд может показаться что подкастов не много, но даже этого достаточно для того чтобы выбирать какие выпуски слушать, а какие можно пропустить. Разумеется кроме Радио-Т, тут нельзя пропускать.
Подкасты - это не развлечение, а инвестиция в профессиональный рост. Пока другие листают ленту в дороге, ты можешь прокачивать экспертизу. Главное - найти свой формат и держать регулярность.
❤1👍1
Про выгорание, с усталым видом и без пафоса.
Да, об этом говорят часто. И правильно делают... Умалчивание не работает!
Для меня выгорание это не "слабость", а естественный результат, если долго жить только задачами. У любого ресурса есть предел.
Важно не ждать, пока силы кончатся. Важно строить систему, которая помогает держать баланс:
- делать паузы, даже когда "очень надо доделать"
- следить за телом, а не только за кодом
- выбирать приоритеты, а не разбрасываться на всё подряд
Нет универсального рецепта. Каждый находит свой способ восстанавливаться. Но главное признать, что это нормально и что этим стоит управлять.
Я вот например чувствую что начинаю гореть, после двух недель жесточайшего овертайма. Вчера заметил за собой, что проводя дейли, мне безразличен его результат. Это уже сигнал и требуется немного притормозить.
По этому пишу пост, как один из способов саморефлексии.
Сейчас мы делаем рефакторинг SSO системы, и утром меня посетила мысль "В коде мы регулярно делаем рефакторинг. Почему бы с собой поступать так же?".
Да, об этом говорят часто. И правильно делают... Умалчивание не работает!
Для меня выгорание это не "слабость", а естественный результат, если долго жить только задачами. У любого ресурса есть предел.
Важно не ждать, пока силы кончатся. Важно строить систему, которая помогает держать баланс:
- делать паузы, даже когда "очень надо доделать"
- следить за телом, а не только за кодом
- выбирать приоритеты, а не разбрасываться на всё подряд
Нет универсального рецепта. Каждый находит свой способ восстанавливаться. Но главное признать, что это нормально и что этим стоит управлять.
Я вот например чувствую что начинаю гореть, после двух недель жесточайшего овертайма. Вчера заметил за собой, что проводя дейли, мне безразличен его результат. Это уже сигнал и требуется немного притормозить.
По этому пишу пост, как один из способов саморефлексии.
Сейчас мы делаем рефакторинг SSO системы, и утром меня посетила мысль "В коде мы регулярно делаем рефакторинг. Почему бы с собой поступать так же?".
❤9🔥1
Доверяй, но сверяйся с реальностью
Сейчас будет много саморефлексии, обещаю что про технологи посты пойдут дальше.
Есть один урок, который я периодически переучиваю заново. Казалось бы, простая истина, но почему-то каждый раз приходится набивать шишку. Доверие штука хорошая. Без него невозможно строить команду, делегировать, расти. Но есть тонкая грань между "я тебе доверяю" и "я закрыл глаза и надеюсь на лучшее". Первое - это осознанный выбор. Второе - это лень проверять свои ощущения фактами.
Горящие глаза, правильные слова, энтузиазм на старте? всё это здорово. Но единственное, что реально показывает человека - это результаты. Не обещания, не объяснения, не "вот-вот разберусь". Результаты.
Если их нет месяц - это повод задать вопросы. Если их нет три месяца - это уже ответ.
Мысль-напоминание самому себе: Вера в человека - это аванс. Но любой аванс рано или поздно нужно закрывать делами.
Сейчас будет много саморефлексии, обещаю что про технологи посты пойдут дальше.
Есть один урок, который я периодически переучиваю заново. Казалось бы, простая истина, но почему-то каждый раз приходится набивать шишку. Доверие штука хорошая. Без него невозможно строить команду, делегировать, расти. Но есть тонкая грань между "я тебе доверяю" и "я закрыл глаза и надеюсь на лучшее". Первое - это осознанный выбор. Второе - это лень проверять свои ощущения фактами.
Горящие глаза, правильные слова, энтузиазм на старте? всё это здорово. Но единственное, что реально показывает человека - это результаты. Не обещания, не объяснения, не "вот-вот разберусь". Результаты.
Если их нет месяц - это повод задать вопросы. Если их нет три месяца - это уже ответ.
Мысль-напоминание самому себе: Вера в человека - это аванс. Но любой аванс рано или поздно нужно закрывать делами.
❤5👍4🥰1
Как и обещал, пишу пост технический. Надеюсь лично для тебя полезный. Сначала хотел коротко описать в ТГ как это реализовать, но в итоге все так раздулось, что пришлось выложить в качестве статьи. Ну так вот, написал статью на Хабр о том, как организую SQL-запросы в Go-проектах.
Если коротко: все запросы одной сущности храню в одном
В статье разобрал:
* Реализацию парсера на регулярках
* Сравнение с Query Builder, inline SQL и подходом "файл на запрос"
* Когда этот паттерн уместен, а когда лучше взять что-то другое
Это не претензия на серебрянную пулю, просто один из подходов, который хорошо работает для типовых CRUD-операций. Для динамических отчётов по-прежнему беру squirrel или другой sql билдер.
https://habr.com/ru/articles/978974/
Если коротко: все запросы одной сущности храню в одном
.sql файле с маркерами -- name: QueryName. Загружаю через go:embed, получаю по имени через геттер. Репозиторий остаётся чистым, SQL с нормальной подсветкой в IDE.В статье разобрал:
* Реализацию парсера на регулярках
* Сравнение с Query Builder, inline SQL и подходом "файл на запрос"
* Когда этот паттерн уместен, а когда лучше взять что-то другое
Это не претензия на серебрянную пулю, просто один из подходов, который хорошо работает для типовых CRUD-операций. Для динамических отчётов по-прежнему беру squirrel или другой sql билдер.
https://habr.com/ru/articles/978974/
👍10❤1🔥1