ROS (Robotic operation system) уверенно занимает лидирующие позиции в стандартах робототехники. Говоря словами известного политика, ею уже пользуются «не только лишь все».
В данной статье попробуем взглянуть на следующий этап развития ROS — систему ROS2, подходящую для более «рукастых» разработчиков. Сравним обе системы в общих чертах, а заодно установим ROS2 на систему Ubuntu 18.04.

UPD. Ссылка на новый репозиторий проекта с поддержкой развертывания в Kubernetes

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

Шаблон включает:

• Передачу параметров сервера через командную строку github.com/urfave/cli
• Настройка параметров сервера через конфигурационный файл github.com/sasbury/mini
• Настройка параметров TLS HTTP сервера
• Настройка роутера регистрация HTTP и prof-обработчиков github.com/gorilla/mux
• Настройка уровней логирования без остановки сервера github.com/hashicorp/logutils
• Настройка логирования HTTP трафика без остановки сервера
• Настройка логирования ошибок в HTTP response без остановки сервера
• HTTP Basic аутентификация
• MS AD аутентификация gopkg.in/korylprince/go-ad-auth.v2
• JSON Web Token github.com/dgrijalva/jwt-go
• Запуск сервера с ожиданием возврата в канал ошибок
• Использование контекста для корректной остановки сервера и связанных сервисов
• Настройка кастомной обработки ошибок github.com/pkg/errors
• Настройка кастомного логирования
• Сборка с внедрением версии, даты сборки и commit

Вторая часть посвящена прототипированию REST API.

Третья часть посвящена развертыванию шаблона в Docker, Docker Compose, Kubernetes (kustomize).

Пятая часть посвящена оптимизации Worker pool и особенностям его работы в составе микросервиса, развернутого в Kubernetes.

Ссылка на репозиторий проекта.

Особенности работы внутренних механизмов PostgreSQL позволяют ему быть очень быстрым в одних ситуация и «не очень» в других. Сегодня остановимся на классическом примере конфликта между тем, как работает СУБД и тем, что делает с ней разработчик — UPDATE vs принципы MVCC.

Кратко сюжет из отличной статьи:

Когда строка изменяется командой UPDATE, фактически выполняются две операции: DELETE и INSERT. В текущей версии строки устанавливается xmax, равный номеру транзакции, выполнившей UPDATE. Затем создается новая версия той же строки; значение xmin у нее совпадает с значением xmax предыдущей версии.

Через какое-то время после завершения этой транзакции старая или новая версии, в зависимости от COMMIT/ROOLBACK, будут признаны «мертвыми» (dead tuples) при проходе VACUUM по таблице и зачищены.



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

В PostgreSQL нет High Availability из коробки. Чтобы добиться HA, нужно что-то поставить, настроить — приложить усилия. Есть несколько инструментов, которые помогут повысить доступность PostgreSQL, и один из них — Patroni.

На первый взгляд, поставив Patroni в тестовой среде, можно увидеть, какой это прекрасный инструмент и как он легко обрабатывает наши попытки развалить кластер. Но на практике в production-среде не всегда всё происходит так красиво и элегантно. Data Egret начали использовать Patroni еще в конце 2018 года и накопили определенный опыт: как его диагностировать, настраивать, а когда вовсе не полагаться на автофейловер.

На HighLoad++ Алексей Лесовский обстоятельно, на примерах и с разбором логов рассказал о типовых проблемах, возникающих при работе с Patroni, и best practice для их преодоления.


В статье не будет: инструкций по установке Patroni и примеров конфигураций; проблем за пределами Patroni и PostgreSQL; историй, основанных на чужом опыте, а только те проблемы, с которыми в Data Egret разобрались сами.

Тем, кто стремится разобраться в сетях и протоколах, посвящается.

Алексей Найдёнов, CEO ITooLabs, рассказывает про разработку телекоммуникационной платформы для операторов связи на языке программирования Go (Golang). Алексей также делится опытом развертывания и эксплуатации платформы в одном из крупнейших азиатских операторов связи, который использовал платформу для оказания услуг голосовой почты (VoiceMail) и Виртуальной АТС (Cloud PBX).

Задался вопросом размещением массивов и слайсов на стеке, подобно std::array в C++ и массивам в Си. Про стек хорошо написал Vincent Blanchon в статье Go: How Does the Goroutine Stack Size Evolve?. Винсент рассказывает про изменения стека в горутинах. Резюмируя:

• минимальный размер стека 2 KB;
• максимальный размер зависит от архитектуры, на 64 битной архитектуре 1 GB;
• каждый раз размер стека увеличивается вдвое;
• стек как увеличивается, так и уменьшается.

Выясню сколько можно положить на стек и какой оверхед может с собой принести.

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

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

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

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

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

0: чего же хотел пользователь

[КДПВ отсюда]

Что вообще обычно подразумевает пользователь, когда говорит про «быстрый» поиск по названию? Почти никогда это не оказывается «честный» поиск по подстроке типа ... LIKE '%роза%' — ведь тогда в результат попадают не только 'Розалия' и 'Магазин Роза', но и 'Гроза' и даже 'Дом Деда Мороза'.

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

Неожиданно статья про мой опыт автоматизации однокомнатной квартиры площадью 41 кв. м. в новостройке, опубликованная две недели назад, стала популярна и на 10 марта её добавил в закладки 781 человек, просмотрели 123 921 раз и Хабр даже запилил рекламный блок в разделе «Рекомендуем» с пометкой «Интересно».


1500 метров проложенных кабелей после окончания ремонта не видны. На фото спальня

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

Алексей Найдёнов, CEO ITooLabs, рассказывает про разработку телекоммуникационной платформы для операторов связи на языке программирования Go (Golang). Алексей также делится опытом развертывания и эксплуатации платформы в одном из крупнейших азиатских операторов связи, который использовал платформу для оказания услуг голосовой почты (VoiceMail) и Виртуальной АТС (Cloud PBX).

Прим. перев.: Новая статья с критикой полюбившейся многим Git Flow получила столь заметное внимание, что даже оригинальный автор модели обновил публикацию 10-летней давности, актуализировав свой взгляд на её применение сегодня. Публикуем перевод как самой критики, так и официальной реакции.



Git-flow — это методология ветвления и слияния, сильно популяризированная заметкой 2010 года под названием «A Successful Git branching model» (была переведена на хабре как «Удачная модель ветвления для Git» — прим. перев.).

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

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

На этом можно заканчивать, так? Ну, не совсем. Наверняка некоторые из вас скептически отнеслись к моей цепочке рассуждений, поэтому давайте копнем поглубже и попытаемся понять, почему модель ветвления Git-flow должна поджариться на медленном огне.

Под катом вы найдете перевод статьи ознакомительного характера, в которой сравниваются три системы непрерывной интеграции: CircleCI, Travis CI и Jenkins.

Доброго времени суток.

Хотел обратить внимание сообщества на характерную особенность Linux при работе с несколькими NVMe SSD в одной системе. Особенно актуально будет для тех кто любит делать из NVMe программные RAID массивы.

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

Привет!

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

Год назад компания Axelos представила четвёртую версию ITIL, библиотеки лучших практик управления ИТ-услугами. Один из ключевых её разделов посвящён руководящим принципам ITIL 4 (The ITIL guiding principles).



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

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

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

Как раз в «Основах», первой из семи книг новой библиотеки, подробно изложены руководящие принципы ITIL 4. Базируются они на известных методиках: Agile, Lean, DevOps и т. п. То есть guiding principles помогают интегрировать лучшие практики в единый подход к управлению ИТ-услугами.

Финляндия — это Нокия, сауны, хоккей, лыжи, тяжёлый металл, Angry Birds. И ещё самые счастливые люди на планете на 2018 по WHR (это, скорее, экономические показатели, чем желание радостно смотреть ковёр всё время).

Краткая история: сначала была просто земля с местными народами, потом территория вошла в состав Швеции надолго, в 1809 году перешла в состав Российской Империи (но получила нехилую независимость, даже собственная марка ходила), а сразу после прихода большевиков ко власти стала отдельной страной с разрешения Ленина. То есть жители некогда части Империи пропустили весь сюжет с девяностыми и с СССР. Точнее, видели часть его в перекрестье снайперского прицела во время войн 39-44 годов.

У нас опять пятничный урбанизм, и я хочу рассказать про город Хельсинки. Главное ощущение города — прилив окситоцина. Это гормон, который, среди прочего, отвечает за долговременную любовь мужчины к женщине, родителя к ребёнку и человека к собаке. Выражается он в физическом ощущении счастья в виде спокойствия и безопасности. В Хельсинки хватает и того, и другого.

Начнём с того, что это самый безопасный город мира на случай ядерной войны. Потому что лет 60 назад тут начали с азартом копать туннели и выкопали почти второй подземный город в скале.

Есть архив и нужно извлечь содержимое, а пароль забыт. Можно погуглить и довериться разным программам (раз, два, три и четыре), но

Единственный способ взлома архива RAR – брутфорс.

Helmfile — обёртка для helm, которая позволяет в одном месте описывать множество helm релизов, параметризовать их чарты для нескольких окружений, а также задавать порядок их деплоя.

О самом helmfile и примерах его использования можно почитать в readme и best practices guide.

Upd. 10/06/2022: Со временем довёл до ума этот подход и получилось гораздо лучше и удобнее, чем описано в статье. При возможности напишу отдельный пост, а пока с примерами улучшенного варианта можно ознакомиться здесь и здесь.

Мы же познакомимся с неочевидными способами описать релизы в helmfile

Допустим, у нас есть пачка helm-чартов (для примера пусть будет postgres и некое backend приложение) и несколько окружений (несколько kubernetes кластеров, несколько namespace'ов или несколько и того, и другого). Берём helmfile, читаем документацию и начинаем описывать наши окружения и релизы:

    .
    ├── envs
    │   ├── devel
    │   │   └── values
    │   │       ├── backend.yaml
    │   │       └── postgres.yaml
    │   └── production
    │       └── values
    │           ├── backend.yaml
    │           └── postgres.yaml
    └── helmfile.yaml

Queue (очередь) — структура данных на диске или в оперативной памяти, которая хранит ссылки на сообщения и отдает их копии consumers (потребителям). Queue представляет собой Erlang-процесс с состоянием (где могут кэшироваться и сами сообщения). 1 тысяча очередей может занимать порядка 80Mb.

Binding (привязка) — правило, которое сообщает обменнику в какую из очередей должны попадать сообщения.