Пользователь
Привет, Хабр!
Это третья часть в серии статей "Учимся разворачивать микросервисы", и сегодня речь пойдет о Helm 3. В прошлой части мы создали Kubernetes конфигурацию для учебного проекта из 2 микросервисов (бекенда и шлюза) и задеплоили все это в Google Kubernetes Engine. В этой статье мы напишем Helm-чарт для нашей системы, создадим для него репозиторий на основе GitHub Pages и задеплоим проект в GKE с помощью Helm.
35 вопросов для быстрой оценки качества IT проекта
Привет, дорогие читатели! Хочу поделиться с вами моим чек-листом для проверки состояния IT проекта (преимущественно web, но адаптируется и под другие). Особенно пригодится предпринимателям и управленцам, которые попали на новый проект. После проверки вы получите результат по 100-балльной системе!
Одно время, приходилось много работать с логами. Они могли быть большими и находиться на разных серверах. Требовалось не найти что-то конкретное, а понять почему система ведёт себя не так как надо. По некоторым причинам, лог-агрегатора не было.
Хотелось иметь просмотрщик логов, позволяющий, в любой момент, открыть любой файл, без скачивания на локальную машину, как команда less в linux консоли. Но при этом, должна быть удобная подсветка текста, как в IDE, и фильтрация событий по различным параметрам. Фильтрация и поиск должны работать по событиям в логе, а не по строкам, как grep, это важно когда есть многострочные записи, например ошибки со стектрейсами. Так же должна быть возможность просматривать записи сразу из нескольких файлов на одной странице, смёржив их по таймстемпу, даже если файлы находятся на разных нодах.
Когда ты молод, ты «бессмертен» и не задумываешься о старости. Есть просто уверенность, что если много и хорошо работать, то твоя карьера и доходы будут неуклонно расти. Следуя этой стратегии, ты развиваешься в профессии уже 15, 20, 30 лет. За эти годы уже получил огромный опыт и, наверное, он обязательно поможет безбедно и интересно прожить остаток дней. Но все не так просто. Да, ты уже давно работаешь в хорошей компании, занимаешься интересными проектами, получаешь за это достойную зарплату, но в будущем уже не так уверен, как раньше. Профессиональный возраст приходит с массой вопросов, на которые нужно ответь стратегически.
Эта статья родилась на основе обсуждения горячей темы «Олды в ИТ», которую 4 января 2021 г. мы записали для подкаста Linkmeup. Обязательно послушайте запись здесь или в любимом подкаст-приложении.
Решил я что то сделать полезное. Был проект в котором мы должны были вместо старого сервиса сделать новый, но лучше. Сервис большой получился, 10к строк бизнесс-правил+код на джаве 15к строк. Сейчас уже раза в два больше. Но так как логики много и никто толком уже многого не помнит (за тем нас и призвали, что бы были тесты, доки и минимум багов) надо было сравнить старый сервис и новый. Что бы наши тестеры не умерли от старости, пытаясь все проверить я подумал и написал сервис, который дергал апи старого и нового, сравнивал и сливал разницу ответов в базу, что бы тестеры проверили и мы пофиксили разницу. Но вот проблема, на входе у нас много параметров и возможных их значений, это же миллиарды комбинаций будут, проверять несколько месяцев с полной нагрузкой, да и похожих много.
В итоге сначала была рождена идея взять и сократить возможные изменения параметров и вообще выкинуть некоторые из перебора, а потом была взята на вооружение Pairwise testing теория и она позволила закинуть все параметры и все значенеия и все проверить целиком.
events, а у нее поле ts — ровно то самое время, по которому мы хотим эти записи упорядоченно показывать:CREATE TABLE events(
id
serial
PRIMARY KEY
, ts
timestamp
, data
json
);
CREATE INDEX ON events(ts DESC);cur.execute("SELECT * FROM events;")
rows = cur.fetchall();
rows.sort(key=lambda row: row.ts, reverse=True);
limit = 26
print(rows[offset:offset+limit]);
Идемпотентность — звучит сложно, говорят о ней редко, но это касается всех приложений, использующих API в своей работе.
Меня зовут Денис Исаев, и я руковожу одной из бэкенд групп в Яндекс.Такси. Сегодня я поделюсь с читателями Хабра описанием проблем, которые могут возникнуть, если не учитывать идемпотентность распределенных систем в своем проекте. Для этого я выбрал формат вымышленных историй о стажёре Васе, который только-только учится работать с API. Так будет нагляднее и полезнее. Поехали.
— Андрей, вы знакомы с трудами Michael Feathers, например, «Working Effectively with Legacy Code»? В книге акцентируется внимание на важности тестирования и выделяется одно из ключевых отличий legacy от не legacy-кода — это наличие тестов. Вы согласны с этим мнением? 
Пост расcчитан на начинающих, на людей незнакомых с технологией Apache Lucene. В нем нет материала о том, как устроен Apache Lucene внутри, какие алгоритмы, структуры данных и методы использовались для создания фреймворка. Пост является обучающим материалом-тизером, написанным для того, чтобы показать, как организовать простейший нечёткий поиск по тексту. 
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
Sort (cost=146.63..148.65 rows=808 width=138) (actual time=55.009..55.012 rows=71 loops=1)
Sort Key: n.nspname, p.proname, (pg_get_function_arguments(p.oid))
Sort Method: quicksort Memory: 43kB
-> Hash Join (cost=1.14..107.61 rows=808 width=138) (actual time=42.495..54.854 rows=71 loops=1)
Hash Cond: (p.pronamespace = n.oid)
-> Seq Scan on pg_proc p (cost=0.00..89.30 rows=808 width=78) (actual time=0.052..53.465 rows=2402 loops=1)
Filter: pg_function_is_visible(oid)
-> Hash (cost=1.09..1.09 rows=4 width=68) (actual time=0.011..0.011 rows=4 loops=1)
Buckets: 1024 Batches: 1 Memory Usage: 1kB
-> Seq Scan on pg_namespace n (cost=0.00..1.09 rows=4 width=68) (actual time=0.005..0.007 rows=4 loops=1)
Filter: ((nspname <> 'pg_catalog'::name) AND (nspname <> 'information_schema'::name))
