Публикую перевод моей статьи из блога ГитЛаба про то как начать использовать CI. Остальные переводы гитлабовских постов можно найти в блоге компании Softmart.

---

Представим на секунду, что вы не знаете ничего о концепции непрерывной интеграции (Continuous Integration — CI) и для чего она нужна. Или вы всё это забыли. В любом случае, начнем с основ.

Представьте, что вы работаете над проектом, в котором вся кодовая база состоит из двух текстовых файлов. Более того, очень важно, чтобы при конкатенации этих файлов в результате всегда получалась фраза "Hello world." Если это условие не выполняется, вся команда лишается месячной зарплаты. Да, все настолько серьезно.

Введение

Отдыхая на новогодних праздниках, я загорелся идеей создания «Умного дома». Среди «народных» экосистем наиболее популярным в силу дешевизны и обилия всевозможных подключаемых устройств мне сразу показалось решение от Xiaomi. Сразу отказавшись от управления своим домом через китайские сервера (возможные задержки, безопасность и привязка к устройствам одного производителя), я принялся изучать всевозможные системы управления умным домом и подбирать для них совместимое оборудование.

После часов поисков я решил, что мне подходит Home Assistant. Строить всё на начальном этапе я решил с использованием Raspberry Pi 4 Model B (2GB) и датчиков от Xiaomi. Купив шлюз (нужна версия с артикулом DGNWG02LM) и включив протокол связи локальной сети, я столкнулся с тем, что порты 4321 и 9898, необходимые для интеграции в Home Assistant, по-прежнему остались закрытыми.

Под катом небольшое и простое руководство, в котором показано, как использовать Docker Compose для настройки и запуска приложения Elixir/Phoenix + PostgreSQL.

Прим. перев.: это перевод статьи из инженерного блога компании Preply о том, как можно использовать конфигурацию как код для такого популярного CI/CD инструмента как Jenkins.

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

Кроме того, в данной статье мы попробуем найти ответы на такие вопросы как:

• Стал ли наш Jenkins стабильнее?
• Можем ли мы делать частые изменения в конфигурацию сервера и джоб?
• Является ли обновление Jenkins для нас все еще болью?
• Можем ли мы контролировать все наши изменения?
• Можем ли мы быстро восстановить Jenkins в случае факапа?

От переводчика: «Elixir и Phoenix — прекрасный пример того, куда движется современная веб-разработка. Уже сейчас эти инструменты предоставляют качественный доступ к технологиям реального времени для веб-приложений. Сайты с повышенной интерактивностью, многопользовательские браузерные игры, микросервисы — те направления, в которых данные технологии сослужат хорошую службу. Далее представлен перевод серии из 11 статей, подробно описывающих аспекты разработки на фреймворке Феникс казалось бы такой тривиальной вещи, как блоговый движок. Но не спешите кукситься, будет действительно интересно, особенно если статьи побудят вас обратить внимание на Эликсир либо стать его последователями».

Известный провайдер heroku поддерживает манифест, который называется «12-факторное приложение» (Twelve-Factor App). Это набор лучших практик для разработки современных веб приложений на любой платформе. Практики описывают приложения, которые готовы:

• к горизонтальному масштабированию;
• к непрерывному развертыванию;
• к современным облачным хостингам.

Можно считать, что манифест отчасти рекламный — 12-факторные приложения удобней всего разворачивать на heroku. Но поскольку, манифест становиться все популярней, то часть облачных провайдеров включают лучшие практики в свое окружение, и эти практики будут полезны как разработчикам, так и тем, кто разворачивает и администрирует приложения.

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

От А0 до B2 за год

Чуть больше года назад я был полностью монолингвом, говорящем только на английском, с нулевыми познаниями во французском языке. А спустя двенадцать месяцев, я с лёгкостью сдал международный экзамен DELF B2. Если вы не знаете, что значит «В2», посмотрите шкалу CEFR.

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

Стоит отметить, что мой темп обучения был несколько агрессивным, поскольку за последний год я посвятил изучению французского много времени, однако, это всё ещё значительно меньше, чем фултайм обучение.

Не могу сказать, что полностью свободно говорю, но чтобы вы лучше понимали, каких результатов удалось достичь, приведу список того, что больше не вызывает у меня проблем:

• Беседа на французском в течение нескольких часов;
• Понимание различных видов французских СМИ (например, новости и видео на YouTube);
• Чтение статей, написанных для носителей французского языка;
• Построение мыслей на французском;

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

Приветствую.

Так уж сложилось, что по долгу работы мне приходится много времени уделять логам. Это и участие в выработке правил и политик сбора/хранения/использования логов, это и разбор разных инцидентов и обнаружение аномалий. За сутки наши программы, сервисы и серверы генерируют ОЧЕНЬ большое количество логов. И потребность копания в логах растёт постоянно.
Мне довелось поработать с коммерческими лог-менеджмент продуктами типа ArcSight, RSA Envision, Q1 Labs. У этих продуктов есть как плюсы, так и минусы. Но в статье речь пойдёт не о них.
Речь будет о Logstash.

Что же такое Logstash? Зачем он нужен? Что он умеет?

Существует ли в мире очень большая и крупная база данных, которая время от времени не страдает от проблем с производительностью? Держу пари, что их не так уж много. Поэтому каждый DBA (администратор базы данных), отвечающий за PostgreSQL, должен знать, как отслеживать потенциальные проблемы производительности, чтобы выяснить, что на самом деле происходит.

Повышение производительности PostgreSQL после настройки параметров

Многие думают, что изменение параметров в postgresql.conf — это реальный путь к успеху. Однако это не всегда так. Конечно, чаще всего хорошие параметры конфигурации базы данных очень полезны. Тем не менее, во многих случаях реальные проблемы будут возникать из-за странного запроса, скрытого глубоко в некоторой логике приложения. Даже вполне вероятно, что запросы, вызывающие реальные проблемы, не являются теми, на которые вы обратили внимание. Возникает естественный вопрос: как мы можем отследить эти запросы и выяснить, что на самом деле происходит? Мой любимый инструмент для этого — pg_stat_statements, который всегда должен быть включен по моему мнению, если вы используете PostgreSQL 9.2 или выше (пожалуйста, не используйте его в более старых версиях).

Любому системному администратору в своей повседневной деятельности приходится иметь дело со сбором и анализом логов. Собранные логи нужно хранить — они могут понадобиться для самых разных целей: для отладки программ, для разбора инцидентов, в качестве подспорья для службы техподдержки и т.п. Кроме того, необходимо обеспечить возможность поиска по всему массиву данных.

«Подготовленный человек тоже наступает на грабли.
Но с другой стороны — там, где ручка.»

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

Jupyter Notebook – это крайне удобный инструмент для создания красивых аналитических отчетов, так как он позволяет хранить вместе код, изображения, комментарии, формулы и графики:



Ниже мы расскажем о некоторых фишках, которые делают Jupyter очень крутым. О них можно прочитать и в других местах, но если специально не задаваться этим вопросом, то никогда и не прочитаешь.

Эта статья основана на моём выступлении на ITSubbotnik, прошедшем в Рязани 14 октября 2017 года. На русском пока что довольно мало материала на эту тему, надеюсь что статья будет вам полезна.

Disclaimer: Автор не является экспертом ни в WebAssembly, ни в JavaScript. Данная статья есть компиляция мыслей и идей, полученных из выступлений других людей на данную тему, плюс эпизодического опыта изучения WebAssembly в течение нескольких месяцев.

Перевод обзорного руководства с сайта Tensorflow.org. Это руководство даст вам основы для начала работы с Keras. Чтение займет 10 минут.

Всем привет. Ниже представлена расшифровка доклада с Big Monitoring Meetup 4.

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

В докладе будет сравнение Thanos и VictoriaMetrics — проектов для долгосрочного хранения метрик Prometheus.

В октябре Github запустил actions, которые позволяют выполнять CI, не отходя от кассы, в которой этот самый код хранится. Это действительно очень удобно. Как только кто-то отправляет pull request, или просто загружает новые изменения на сервер, или что-то еще специальное (список событий, к которым можно прикрутить actions может быть найден в официальной документации), сборка запускается. Также поддерживаются запланированные повторяющиеся задачи (по принципу cron).

Можно создавать конвейеры действий, названные рабочими процессами (workflows). И все это прекрасно, и смахивает на светлое будущее — за исключением документации.

Иногда возникает задача «склеить» внутри SQL-запроса из переданных в качестве параметров линейных массивов целостную выборку с теми же данными «по столбцам».

Привет, Хабр!

На KotlinConf мы представили наш новый продукт Space и открыли программу раннего доступа. В этом посте мы расскажем, что умеет Space, над чем мы работаем сейчас, а также о задачах и проблемах, которые он решает. Посмотреть запись презентации можно в видео ниже.

Все хорошие стартапы либо быстро умирают, либо дорастают до необходимости масштабироваться. Мы смоделируем такой стартап, который сначала про фичи, а потом про перфоманс. Перфоманс будем улучшать с MongoDB — это популярное NoSQL-решение для хранения данных. С MongoDB легко стартовать, и многие проблемы имеют решения «из коробки». Однако, когда нагрузка растет, вылезают грабли, о которых вас заранее никто не предупреждал… до сегодняшнего дня!



Моделирование проводит Сергей Загурский, который отвечает за инфраструктуру бэкенда вообще, и MongoDB в частности, в Joom. Также был замечен в серверной части разработки MMORPG Skyforge. Как сам себя описывает Сергей — «профессиональный набиватель шишек собственным лбом и граблями». Под микроскопом — проект, который использует стратегию накопления для управления техническими долгом. В этой текстовой версии доклада на HighLoad++ будем двигаться в хронологическом порядке от возникновения проблемы до решения с помощью MongoDB.

Лет 10 назад веб-проекты по большей части были статическими, а технологический процесс порой — прост до безобразия. Теперь грань между веб-приложениями и настольными приложениями стирается, функциональная сложность веб-проектов растет. Это диктует новые требования к веб-разработке. Обычная ситуация нынче, в эпоху «удиви меня 2.0», — когда проект долгосрочный, в нем задействовано множество специалистов (и не специалистов также), щедро орошающих многострадальный product backlog новыми идеями и целями, как до начала разработки, так и после. Как вы понимаете, цели и истории мутируют, а вместе с ними и задачи. Предварительная оценка по времени теряет свою целесообразность. И т.д. и т.п. Очевидно, нужна специальная методология разработки. Можно попробовать приобщиться к Rational Unified Process (RUP) или Process Mentor. Однако, не стоит. Среди столь популярных ныне Agile методик имеется то, что нам надо — Feature Driven Development (FDD).