На дворе март, в теле авитаминоз, в мире эпидемия CoV19, а тут ещё и дедлайны. Дедлайнам про наши тяжёлые жизненные обстоятельства не сообщили. Самое время вспомнить о здоровье. В том числе и психическом. В конце концов, чем работаешь, то и ломается, а работаем мы головой.

В октябре прошлого года я летал в Сибирь на TEDx Novosibirsk и в самолёте внезапно оказался рядом с другим спикером – Павлом Буковым. Он психотерапевт и собирался сделать доклад про профессиональное выгорание: как бы выгорать пореже и не дотла. Я, естественно, вспомнил, как год назад выгорел сам. Заодно вспомнил, сколько людей набивается в зал, когда на технологических конференция докладчик рассказывает про выгорание. В общем, пока мы летели в Сибирь, я записал с Павлом эпизод подкаста про стресс и выгорание и решил собрать из него статью.

Регулярно сталкиваюсь с ситуацией, когда многие разработчики искренне полагают, что индекс в PostgreSQL — это такой швейцарский нож, который универсально помогает с любой проблемой производительности запроса. Достаточно добавить какой-нибудь новый индекс на таблицу или включить поле куда-нибудь в уже существующий, а дальше (магия-магия!) все запросы будут эффективно таким индексом пользоваться.

Во-первых, конечно, или не будут, или не эффективно, или не все. Во-вторых, лишние индексы только добавят проблем с производительностью при записи.

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

Доработки происходят итеративно силами множества распределенных команд, которые бывают разнесены не только в пространстве, но и во времени. И тогда, не зная всей истории развития проекта или особенностей прикладного распределения данных в его БД, можно легко «напортачить» с индексами. Но соображения и проверочные запросы под катом позволяют заранее предсказывать и обнаруживать часть проблем:

• неиспользуемые индексы
• префиксные «клоны»
• timestamp «в середине»
• индексируемый boolean
• массивы в индексе
• NULL-мусор

Всем привет!

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

Подразделение, в котором я работаю, занимается разработкой и сопровождением единой фронт офисной системы Банка. Я отвечаю за ее сопровождение, мониторинг и DevOps.

Наша Система — это высоконагруженное приложение, ежедневно обслуживающее более 5 000 уникальных пользователей. На сегодняшний день — это «монолит» со всеми своими достоинствами и недостатками. Но сейчас активно идет процесс выноса функционала в микросервисы.

Ежедневно наша система генерирует более 130 ГБ «сырых» логов и, несмотря на то, что мы используем ENG стек (Elasticsearch Nxlog Graylog), файловые логи содержат гораздо больше информации (например, stack trace ошибок), поэтому требуют архивирования и хранения.

Так как место хранения ограничено, встаёт вопрос: «А какой архиватор лучше всего справится с этой задачей».

Для решения этого вопроса я написал скрипт на языке PowerShell, который произвел анализ за меня.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Functional PowerShell with Classes.
I promise it’s not an oxymoron" автора Christopher Kuech.

Объектно-ориентированная и функциональная парадигмы программирования могут казаться не в ладах друг с другом, но обе в равной мере поддерживаются в Powershell. Практически все программные языки, функциональные и нет, имеют средства расширенного связывания имён и значений; Классы, подобно struct-ам и record-ам, это всего лишь один подход. Если мы ограничим использование Классов связыванием имён и значений и станем избегать таких "тяжёлых" объектно-ориентированных программных концепций, как наследование, полиморфизм, или изменяемость (mutability), мы сможем использовать их преимущества, не усложняя наш код. Далее, добавляя неизменяемые (immutable) методы преобразования типов, мы можем обогатить Классами наш функциональный код.

Магия кастов

Касты одна из самых мощных фич в Powershell. Когда вы подвергаете значение касту, вы полагаетесь на добавляемую средой в ваше приложение возможность неявных инициализации и валидации. Например, простой каст строки в [xml] прогонит её через код парсера и сгенерирует полное дерево xml. Мы можем в своём коде использовать Классы с той же целью.