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

• для разных языков нужны разные IDE и тулчейны;
• в разных проектах могут использоваться разные версии тулчейнов и библиотек.

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

Конфигурация на примере Ubuntu 20.04.

Размышления о вариантах и причинах приведены в конце статьи.

Введение

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

Содержимое mail.txt

Иванов Андрей;ia@example.com

Содержимое buhg.txt

Иванова Алла;маляр
Ёлкина Элла;крановщица
Иванов Андрей;слесарь
Абаканов Михаил;маляр

Для объединения файлы были отсортированы юниксовской командой sort и поданы на вход юниксовской программе join, которая неожиданно завершилась с ошибкой:

$> sort buhg.txt > buhg.srt
$> sort mail.txt > mail.srt
$> join buhg.srt mail.srt > result
join: buhg.srt:4: is not sorted: Иванов Андрей;слесарь

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

$> sort buhg.txt
Абаканов Михаил;маляр
Ёлкина Элла;крановщица
Иванова Алла;маляр
Иванов Андрей;слесарь

Выглядит как глюк сортировки в Юникоде или как проявление феминизма в алгоритме сортировки. Первое, конечно, правдоподобнее.

Решил задаться целью написать простой в использовании и при этом быстрый многопоточного TCP/IP сервера на C++ и при этом кроссплатформенный — как минимум чтобы работал на платформах Windows и Linux без требования как-либо изменять код за пределами самописной библиотеки. Ранее, на чистом C++ без библиотек вроде Qt, сетевым программировнием не занимался, и предвещал себе долгое время мучений с платформо-зависимостью. Но как оказалось всё гораздо проще чем казалось на первый взгляд, ведь в основном интерфейсы сокетов обоих систем похожи как две капли воды и различаются лишь в мелких деталях.

Как все начиналось

В данной статье я хочу описать свой опыт по доставке Graal Native Image конечным пользователям Mac OS и Linux в одну команду при помощи Travis CI.

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

Пожалуй начнем.

У меня есть:

• Java приложение со всеми конфигурациями для сборки native image.

Что хочу получить:

• Собрать native image при помощи Travis
• Собрать rpm и deb дистрибутивы, а также архив для mac версии
• Залить полученные пакеты на Bintray
• Дать пользователям возможность загрузить приложение через пакетный менеджер
• Максимально автоматизировать процесс.

Материал статьи взят с моего дзен-канала.

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

Отладка крафтовых фильтров

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

Для посторонних кажется удивительным тот факт, что компиляторы UNIX не выдают листинги: печать лучше осуществляется и более гибко настраивается с помощью отдельной программы.

# ┌───────────── минуты (0 - 59)
# │ ┌───────────── часы (0 - 23)
# │ │ ┌───────────── день (1 - 31)
# │ │ │ ┌───────────── месяц (1 - 12)
# │ │ │ │ ┌───────────── день недели (0 - 6)
# │ │ │ │ │
# * * * * * <задача или команда>