Я думаю, не стоит никому объяснять, что такое выгорание, большинство периодически ходят по краю, рискуя упасть и окунуться в это состояние с головой. В двух словах выгорание — это поломка системы восстановления энергии в условиях продолжительного стресса.

Dhall — программируемый язык для создания конфигурационных файлов различного назначения. Это Open Source-проект, первый публичный релиз которого состоялся в 2018 году.

Как и всякий новый язык для генерации конфигурационных файлов, Dhall призван решить проблему ограниченной функциональности YAML, JSON, TOML, XML и других форматов конфигурации, но при этом оставаться достаточно простым. Язык распространяется всё шире. В 2020-м году представили его bindings, сделанные специально для Kubernetes.

В 2018-м году, работая в Akvelon Inc., я собеседовал одного человека. Перед интервью мне дали на проверку его тестовое задание: небольшое web-приложение по типу записной книжки или todo-списка – React\TypeScript, C# на бэке и MS SQL Server в качестве персистентного хранилища. Приложение было модное: с обилием unit-тестов на mock’ах, упакованное в docker-образ – видно, что человек старался. И у этого решения был всего один недостаток – оно не работало. Совсем. Падало при попытке сохранить новую строку в базу данных.

Этот случай мне очень хорошо запомнился, поскольку подсветил сразу несколько типовых проблем.

Первая из них – ложная уверенность от модульных тестов. Даже 100% покрытие кода тестами не гарантирует, что в нём нет ошибок.

И вторая – отсутствие функциональных тестов. Если ваше приложение работает с СУБД, то вы обязательно должны покрыть эту часть кода реальными тестами с реальной базой данных. И здесь есть очень важное условие: проверять нужно именно на той версии СУБД, которая работает у вас в production’е. Думаю, очень многие разработчики под Oracle, прогоняющие свои тесты на H2\HSQLDB, сталкивались с ситуацией, когда тесты проходят, а production не работает (boolean, group by и другие чудеса).

Сейчас я работаю в основном с PostgreSQL и мигрирую наши микросервисы с 10-й версии на 11-ую. В процессе миграции (и разработки вообще) я столкнулся с несколькими нюансами, о которых хотелось бы рассказать.

Энтузиаст состоит в различных чатах в Telegram и как-то недавно наткнулся на канал по процессорам Loongson и ему удалось провести различные тесты данного процессора.

Последние пару лет я помогаю клиентам нашего облака внедрять DevOps-практики и делюсь своим опытом инженера DevOps. К сожалению, вопросы про информационную безопасность возникают у клиентов зачастую тогда, когда уже что-то произошло. У меня как у любителя киберзащиты постепенно накопилась целая подборка ИБ-кейсов, которыми хочется поделиться. 

В статье собрал правила безопасности контейнеров, о которых часто забывают, но потом снова вспоминают на поучительных примерах.

#!/bin/bash
exec > my_image.ppm    # Все инструкции echo будут писать в этот файл
echo "P3 250 250 255"  # формат, ширина, высота, максимальное значение цвета
for ((y=0; y<250; y++)) {
  for ((x=0; x<250; x++)) {
    echo "$((x^y)) $((x^y)) $((x|y))" # r, g, b
  }
}

Terraformer — консольный инструмент для генерации кода и стейта в форматах HCL и json для уже существующей инфраструктуры.

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

Ссылки на предыдущие статьи: 

Выгорание — норма? Часть 1. (Вводная)

Выгорание — норма? Часть 2. Подробно про фазы и «Что делать?»

Напоминаю, что выгорание — это часть реакции на стресс; состояние, в которое приводит продолжительный стресс средней и даже малой интенсивности. Стресс либо незаметный, вытесненный за пределы внимания, либо мы его терпим по какой-то причине, но результат в итоге один: в мозге ломается реакция на раздражители, и система мотивации / поощрения. 

В моём случае стресс копился годами и слоями, но был вытеснен в кладовую подсознания. Обнаружила я это только тогда, когда сдалась врачам, и мы стали копать от симптомов к первопричине, попутно отпаивая меня таблеточками в стационаре.

Но обо всём по порядку.

Здравствуйте! Сегодня мы напишем Slack Scrum покер бота на языке Go. Писать будем по возможности без фреймворков и внешних библиотек, так как наша цель – разобраться с языком программирования Go и проверить, насколько этот язык удобен для разработки подобных проектов. Прошу под кат!

Вы вряд ли найдете в интернете что-то про разработку ботов, кроме документаций к библиотекам, историй "как я создал такого-то бота" и туториалов вроде "как создать бота, который будет говорить hello world". При этом многие неочевидные моменты просто нигде не описаны.

Как вообще устроены боты? Как они взаимодействуют с пользователями? Что с их помощью можно реализовать, а что нельзя?

Подробный гайд о том, как работать с ботами — под катом.

Kubernetes сейчас называют стандартом для оркестрации контейнеров. Он лежит в основе многих облачных платформ контейнеризации: например, мы давно развиваем наш Kubernetes aaS на платформе Mail.ru Cloud Solutions.

Однако Kubernetes далеко не первый подобный инструмент на рынке: некоторые из систем-предшественников продолжают активно использовать и вроде бы даже успешно.

Почему так происходит, несмотря на то, что Kubernetes, можно сказать, одержал победу в своем классе и мы видим много примеров, когда он приходит на смену другим решениям? Например, не так давно разработчики Mesosphere DC/OS, в основе которой лежал Apache Mesos, прекратили ее развитие и сфокусировались на другой своей платформе — D2iQ Kubernetes (DKP). Думаю, что стоит разобраться, всегда ли хорош Kubernetes, когда оправдано использовать другие оркестраторы и о каких подводных камнях стоит знать.

Я Дмитрий Лазаренко, директор по продуктам облачной платформы Mail.ru Cloud Solutions (MCS). В этой статье расскажу об устройстве ряда оркестраторов-предшественников, сравню их с Kubernetes, посмотрю на его преимущества и недостатки по сравнению с ними.

Прежде чем начать я бы хотел отметить, что это всего лишь небольшой туториал по быстрому старту для тех кто, как и я, ни разу не использовал Kafka на практике

Продолжаем цикл материалов с обзорами составляющих домашней студии. Ранее мы поговорили о «мониторных» наушниках, колонках для мультимедиа и акустике для работы со звуком. После этого остановились на наушниках со встроенными микрофонами [раз, два].

Сегодня начнем разбираться с универсальными конденсаторными USB-микрофонами. Если говорить простыми словами, они позволяют захватывать намного больше деталей в высоком качестве, по сравнению с динамическими моделями данного ценового сегмента. Однако в квартире или частном доме это преимущество быстро превращается в недостаток, если микрофон записывает не только голос или инструменты, но и отражения от стен, плюс — посторонние звуки из других комнат. Для минимизации подобных эффектов разработчики выбирают определенную диаграмму направленности — пространство, где микрофон оказывается наиболее чувствительным к звуку. Например, исходя из расположения спикера, музыканта или стримера. В данном сегменте наибольшее распространение получила кардиоида, поэтому все микрофоны в этой подборке имеют кардиоидную диаграмму направленности.

Оценки напрочь оторвались от фундаментального анализа, мультипликаторы находятся на исторических максимумах, скорость эмиссии ценных бумаг зашкаливает — и всё это сопровождается безумно спекулятивным поведением инвесторов. Большой кризис неизбежен.

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

Мониторинг очень важен для современных приложений, современные приложения по своей природе сильно распределены и имеют разные зависимости, такие как база данных, службы, кеширование и многое другое. Поэтому все более важны отслеживание и мониторинг этих служб, чтобы приложение придерживалось условий SLA ( Service Level Agreement). SLA — это соглашение между клиентом и поставщиком услуг, в нем учитываются надежность, скорость отклика и другие показатели уровня обслуживания.

Мы всегда стараемся не нарушать никаких SLA, нарушение любой части SLA может иметь множество последствий. Если услуга не соответствует условиям, определенным в SLA, она можкт нанести ущерб репутации бренда и привести к потери дохода. Хуже всего то, что компания может потерять клиента в пользу конкурента из-за своей неспособности удовлетворить требования клиента к уровню обслуживания.