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

Данная статья — инструкция по прикручиванию базовой непрерывной интеграции (build-test-deploy) к гитхабовским C/C++ проектам с CMake сборкой — по непонятным причинам, на Хабре такого до сих пор не проскальзывало. Впрочем, если моё гугл-фу подвело меня, и таки проскальзывало — не беда. Лишний туториал, описывающий всё под несколько другим углом и предостерегающий от неповторимого набора набитых автором шишек, совершенно точно не повредит.

Под данным изречением-мемом, взятым с замечательной картинки Владимира Филонова, поставит свою подпись каждый человек, имеющий хотя бы отдалённое отношение к программированию. Весь вопрос, как? Как именно документировать-то?

Нижележащий текст преследует несколько целей:

1. Дать краткий обзор (читай — немного погундеть на тему) неудовлетворительного состояния инструментария, применимого к хтоническим чудовищам мира C/C++;
2. Предложить своё альтернативное решение (бесплатно-без-СМС-и-регистрации — проект некоммерческий и выложен на GitHub под MIT-лицензией);
3. Призвать сообщество пообщаться на тему и собрать идеи;
4. Пригласить присоединиться к разработке проекта на GitHub.

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

Что такое реактивное программирование? Статья в Википедии учит, что это — парадигма программирования, ориентированная на потоки данных и распространение изменений. Это определение, хоть и технически корректно (ещё бы!), даёт крайне размытое представление о том, что же за всем этим скрывается на самом деле. Между тем, концепция реактивности проста и естественна, и объяснять её лучше всего на следующем примере.

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

На хабре было уже немало статей на тему реактивного программирования (раз, два, три, четыре и другие) — в основном в них описывается реактивность в своей FRP-ипостаси в виде библиотек навроде bacon.js для JavaScript, JavaRx для Java и т.д. В данной статье пойдёт речь о реализации и применении реактивного программирования в языке Jancy. Материал будет интересен к прочтению даже если вы никогда не слышали о языке Jancy и не собираетесь на нём ничего писать — потому что далее мы продемонстрируем достаточно необычный подход к реактивности из императивного языка.

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

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

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

Обзор архитектуры плагинов

Как и в предыдущей, второй версии продукта, исполнимые файлы третьей версии IO Ninja содержат лишь фреймворк необходимых компонентов (включая UI виджеты, движок для логгирования и классы для работы с IO, такие как io.Socket, io.Serial, io.PCap и т.д.). Логика же работы с конкретными транспортами содержится в плагинах, написанных на языке Jancy. Эти плагины лежат в выделенной папке «scripts» в виде исходных кодов и доступны как для ознакомления, так и для редактирования пользователями.

Данная статья является продолжением предыдущей, вводной статьи, в которой речь шла о мотивации и истории создания терминала/сниффера IO Ninja, и было немного рассказано про встроенные возможности нашего продукта. Продолжим рассказ о том, что доступно «из коробки», но с более практическим уклоном.

IO Ninja изначально задумывалась как утилита типа «всё-в-одном», и в комплект поставки входит большое количество встроеных плагинов для работы со всеразличными транспортами в разных режимах. Однако вместо сухого перечисления списка плагинов и их возможностей я решил продемонстрировать маленькую выборку задач из жизни, с которыми в нашей компании сталкивались на практике, и с которыми общеизвестные терминалы и мониторы справляются хуже, чем IO Ninja (а чаще не справляются вообще).

Приветствую вас, уважаемые хабровчане!

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

Разговор пойдёт про программируемый терминал/сниффер IO Ninja (здесь и далее я буду опускать слово «эмулятор» и говорить просто «терминал»). Подозреваю, что само определение «терминал/сниффер» может выглядеть достаточно непривычно, если не сказать странно. Поэтому начнём с истории возникновения IO Ninja.