Всем привет!

Компания Netсracker уже много лет разрабатывает и поставляет enterprise-приложения для мирового рынка операторов связи. Разработка таких решений достаточно сложна: в проектах участвуют сотни людей, а количество активных проектов исчисляется десятками.

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

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

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

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

Итак, наше приложение будет иметь две основные части: клиентская и серверная. (Какой сейчас год?). Серверная часть будет на Go, а клиентская — на JS. Давайте сначала поговорим о серверной части.

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

В этой части я попытаюсь кратко пройтись по пропущенным местам нашего очень упрощенного веб-приложения на Go.

Грядущий релиз версии 1.11 языка программирования Go принесет экспериментальную поддержку модулей — новую систему управления зависимостями для Go. (прим.перев.: релиз состоялся)

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

Итак, вот, что мы будем делать: создадим новый пакет и потом сделаем несколько релизов, чтобы посмотреть, как это работает.

Скоро начинается второй день Слёрма.

Темы дня

9:00-11:00 Ceph, настройка кластера и особенности работы в продакшен
Устройство ceph
Установка кластера
Создание пользователей, настройка секретов, подключение RBD к подам

11:00-15:00 Пауза

15:00-16:15 Введение в Helm. Разбор чарта на примере stable/* — 1 час

17:30 Траблшутинг кластера, какие проблемы и как мы решали, подводные камни

Мероприятие живое. Расписание может плавать.

Ссылка на трансляцию:

Наверное каждый, кто хоть раз озадачивался поиском высокопроизводительного software-defiined хранилища рано или поздно слышал про DRBD, а может даже и имел дело с ним.

Правда на пике популярности Ceph и GlusterFS, которые работают в принципе неплохо, а главное сразу и из коробки, все просто немного подзабыли про него. Тем более что предыдущая версия не поддерживала репликацию более чем на два узла, и из-за чего часто встречались проблемы со split-brain, что явно не добавило ему популярности.

Решение и правда не новое, но вполне конкурентоспособное. При относительно небольших затратах на CPU и RAM, DRBD предоставляет реально быструю и безопасную синхронизацию на уровне блочного устройства. За все это время LINBIT — разработчики DRBD не стоят на месте и постоянно дорабатывают его. Начиная с версии DRBD9 перестает быть просто сетевым зеркалом и становится чем-то бОльшим.

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

Например DRBD9 поддерживает до 32 реплик, RDMA, diskless-ноды, а новые инструменты оркестрации позволяют использовать снапшоты, online-миграцию и много чего другого.

Несмотря на то что DRBD9 имеет инструменты интеграции с Proxmox, Kubernetes, OpenStack и OpenNebula, на данный момент они находится в некотором переходном режиме, когда новые инструменты еще не везде поддерживаются, а старые уже очень скоро будут объявлены как deprecated. Речь идет о DRBDmanage и Linstor.

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

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

Сегодня в программе:

• auto
• nullptr
• range-based циклы
• override и final
• строго-типизированный enum
• интеллектуальные указатели
• лямбды
• non-member begin() и end()
• static_assert и классы свойств
• семантика перемещения

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

С помощью всего пары скриптов, один из который необходимо положить на сервер, а второй раскидать по клиентам, можно сделать низкоуровневое авто-обнаружение nginx, mongod, rabbitmq, mysql, postgresql и любого другого сервиса.

Введение

Я — системный аналитик, и моя работа заключается в том, чтобы проектировать автоматизированные информационные системы. Впрочем, нет, она заключается в том, чтобы писать и писать документы. Третий раз слово «писать» повторять не буду — все-таки, не «Илиада». Но занудность формы чем-то определенно роднит проектную документацию с древнегреческой поэмой, особенно если речь идет о работе с государственным заказчиком.

Диаграммы — глоток творчества в этом море текста. О диаграммах и пойдет речь в данной статье. Если точнее — о PlantUML — с моей точки зрения, наиболее адекватном инструменте их создания на текущий момент.

По зову сердца и работе в Digital Design в качестве системного инженера, мне часто приходится сталкиваться с переусложненными программными продуктами и архитектурными конструкциями. Это вызывает страстное желание минимизации и упрощения всего, что попадается под руку, и приводит к восторгу от человеческих решений, просто делающих свою работу, без регистрации и смс.

Так я и познакомился с Alpine Linux.

Этот дистрибутив может вам понравиться по следующим причинам:

• Если вы любите минимализм и инструменты, ориентированные на выполнение поставленной задачи без лишних свистелок и украшений;
• Если вы заметили, что имеющиеся «мэйнстримные» дистрибутивы немного (?) раздуты и избыточны;
• Если вы захотели решить имеющуюся задачу простым способом.

Под «мэйнстримом» я подразумеваю тройку CentOS — Debian — Ubuntu (конечно же, ими мир не заканчивается), да простят меня все верующие в эти замечательные дистрибутивы. При их использовании, периодически, на границе восприятия, возникает колкая мысль – «а может быть можно проще?».

Автор статьи, перевод которой мы публикуем сегодня, полагает, что в мире существует ещё много программистов, которые, когда им нужно разработать простое веб-приложение, обращаются к jQuery. Обычно это случается тогда, когда некую страницу нужно оснастить простыми интерактивными возможностями, но использование для этого какого-нибудь JavaScript-фреймворка кажется явным перебором. Ведь это — килобайты ненужного кода, шаблоны, инструменты для сборки проектов, средства для упаковки модулей… При этом подключить к странице jQuery, воспользовавшись CDN-ресурсом, проще простого.



В этом материале речь пойдёт о том, как перевести проект, созданный с использованием jQuery, на Vue.js. Этот проект будет создан на jQuery, а потом переработан с применением Vue. Автор материала хочет продемонстрировать всем желающим то, что использование Vue, даже в сравнительно небольших проектах, не обязательно означает чрезмерное увеличение размера кода таких проектов и большую дополнительную нагрузку на программиста. Это, наоборот, при практически тех же размерах вспомогательного кода, что и при использовании jQuery, позволяет повысить производительность труда и улучшить качество приложений.

Всем привет! Прошлая статья про прозрачное проксирование HTTPS с помощью Squid'a была вполне успешной. Приходило по почте множество отзывов об успешной установке данной системы. Но также и поступали письма с просьбами о помощи. Проблемы были вполне решаемыми. Но не так давно обратилась ко мне одна коллега с просьбой о помощи в установке этой системы на х64 архитектуре (Debian). Тут мы озадачились. Во-первых, оказалось, что прошлая статья непригодна для этого по причине отсутствия нужных исходников в репозитории Debian (там теперь 3.5.10). Найти нужные в первой статье Debian'овские исходники не удалось, а checkinstall выдавал странные ошибки. Во-вторых, хотелось более универсального решения, которое бы без проблем работало и на х64, и на х86, и (по-возможности) на других дистрибутивах. Решение было найдено. Получилось небольшое дополнение к предыдущей статье + некоторые уточнения. Данная инструкция позволяет скомпилировать как х86, так и х64 версии Squid'a и создать соответствующие пакеты. Инструкция будет разбита на несколько пунктов и подпунктов. Если интересно, идем под кат:

Предисловие

Какой Shell использовать

Bash единственный язык shell скриптов, который разрешается использовать для исполняемых файлов.

Скрипты должны начинаться с #!/bin/bash с минимальным набором флагов. Используйте set для установки shell опций, что бы вызов вашего скрипта как bash <script_name> не нарушил его функциональности.

Ограничение всех shell скриптов до bash, дает нам согласованный shell язык, который установлен на всех наших машинах.

Единственное исключение составляет если вы ограничены условиями того под что вы программируете. Одним из примеров могут стать пакеты Solaris SVR4, для которых требуется использование обычного Bourne shell для любых скриптов.

Когда использовать Shell

Shell следует использовать только для небольших утилит или простых скрптов-оберток.

Хотя shell-скриптинг не является языком разработки, он используется для написания различных утилит во всем Google. Это руководство по стилю является скорее признанием его использования, а не предложением использовать его в широком применении.

Недавно я создал небольшой проект на языке Go. После нескольких лет работы с Java я был сильно удивлён тем, как вяло внедрение зависимостей (Dependency Injection, DI) применяется в экосистеме Go. Для своего проекта я решил использовать библиотеку dig от компании Uber, и она меня по-настоящему впечатлила.

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

В этой статье я расскажу об основах внедрения зависимостей, а также покажу пример приложения до и после применения этого механизма (посредством библиотеки dig).

Представьте, вы за два дня полностью реализовали новую фичу. Код написан, он работает и все классно. Ваш менеджер говорит, что можно сразу в релиз. «А как же тесты?» — воскликнет какой-нибудь дотошный коллега. «А зачем?» — ответите вы в один голос с менеджером. Зачем нам писать тесты? Как объяснять их необходимость другим? Зачем вовлекать тестировщиков, аналитиков и других участников? В этом посте я расскажу, как объяснить пользу тестов любому участнику проекта, а также зачем стоит тесты автоматизировать. И подкрепим все это серьезными исследованиями.

Конспект первой лекции по программированию современных микроконтроллеров на примере STM32 и операционной системы RIOT. Лекции читаются в Институте информационных технологий МИРЭА по субботам, с 12:50 в актовом зале на 4 этаже корпуса Д. В занятиях отводится 1,5 часа на саму лекцию и 3 часа на практические занятия в лаборатории IoT Академии Samsung по теме лекции.

Привет, Гиктаймс! Как мы и обещали, начинаем публикацию конспектов лекций, которые сейчас читаются в Институте ИТ МИРЭА. По результатам первой, вводной лекции мы решили немного изменить структуру курса — вместо планировавшихся двух потоков по 5 занятий будет один поток на 7 занятий. Это позволит в более спокойном темпе разобрать ряд вспомогательных вопросов, а также статьи с конспектом будут появляться на GT каждую неделю в течение всего марта и апреля, а не через неделю, как планировалось раньше.

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

Курс рассчитан на студентов второго и третьего курсов, знакомых с языком C и базовыми понятиями электроники и электротехники. Предварительное знакомство с микроконтроллерами не требуется.

Цель курса — освоение навыков, позволяющих свободно работать с микроконтроллерами на ядре ARM Cortex-M на современном уровне и, при наличии такого желания, двигаться в сторону дальнейшего углубления своих знаний.



Сегодняшняя лекция — первая, поэтому на ней будут разбираться общие понятия: что такое вообще микроконтроллер и зачем он нужен, что такое прошивка и как она получается, зачем нам нужна операционная система, и наконец — как работать с git. Результат практического занятия — собственный репозитарий на GitHub с исходными кодами ОС, а также успешно настроенная среда сборки на локальном компьютере.

Описать понятие прокрастинации можно этим максимально простым изображением. У вас есть ряд определенных задач и есть выделенное время на их выполнение. Прокрастинаторы решают свалить все задачи в кучу и оставить на самый последний момент.

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



Есть даже исследование, которое доказывает, что жизнь прокрастинатора короче, чем жизнь человека, который делает все вовремя, потому что он прокрастинирует даже визиты к врачам.

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

Под катом рассказ Петра Людвига на конференции Aletheia Business 2017 о том, как положить конец прокрастинации используя три простых инструмента. Как только вы внедрите их в свою жизнь, вы сразу заметите разницу. Вы будете более продуктивны, почувствуете себя счастливее и у вас появится больше энергии.

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

Вместе с большим количеством кода появляется и старая, знакомая проблема: страх изменений. Люди не желают вносить изменения в «чужую» роль, опасаясь испортить её, вместо этого создают собственную копию. Рефакторинг кода не производится, если код прямо сейчас не находится в фокусе разработки, из-за опасения, что внесённые проблемы могут быть обнаружены спустя слишком большое время. Итог: плохой код растёт как снежный ком.