Предыстория

CLion — это среда для разработки на С/С++, близкий родственник IntelliJ IDEA и, соответственно, Android Studio.

Я представляю вниманию сообщества перевод моего блог поста, в котором по шагам описано, как использовать эту IDE для написания прошивок микроконтроллеров.

Данная статья служит одной простой цели: помочь человеку, который вдруг решил разработать свою операционную систему (в частности, ядро) для архитектуры x86, выйти на тот этап, где он сможет просто добавлять свой функционал, не беспокоясь о сборке, запуске и прочих слабо относящихся к самой разработке деталей. В интернете и на хабре в частности уже есть материалы по данной теме, но довольно трудно написать хотя бы “Hello world”-ядро, не открывая десятков вкладок, что я и попытаюсь исправить. Примеры кода будут по большей части на языке C, но многие другие языки тоже можно адаптировать для OSDev. Давно желавшим и только что осознавшим желание разработать свою операционную систему с нуля — добро пожаловать под кат.

В свободное и не свободное время[1] я развиваю несколько своих проектов на github, а также, по мере сил, участвую в жизни интересных для меня, как программиста, проектах.

Недавно один из коллег попросил консультацию: как выложить разработанную им библиотеку на github. Библиотека никак не связана с бизнес-логикой приложения компании, по сути это адаптер к некоему API, реализующему определённый стандарт. Помогая ему, я понял что вещи, интуитивно понятные и давно очевидные для меня, в этой области, совершенно неизвестны человеку делающему это впервые и далёкому от Open Source.

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

Так что из себя представляет стильный, модный, молодёжный Open Source проект в 201* году?

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

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

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

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

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

Долго меня мучала идея из старенького RPI сделать принт-сервер (удаленная печать и сканирование) и наконец я до этого добрался.

Исходим из того, что у нас есть набор из RPI, флешки с Raspbian, Wi-Fi адаптера, принтера HP LaserJet Pro 1102, МФУ HP Deskjet F2180 и usb-хаба. Основная машина (ББ), которая будет использовать принт-сервер живет на Linux (впрочем, отличия в использовании для Windows будут минимальны).

Когда мы полтора года назад внедряли у себя генератор документаций Sphinx, перед нами стояла задача генерировать PDF. Дело оказалось весьма непростое. Готовых инструкций “бери и делай” на ресурсах не было. Мы пошли методом проб и ошибок. Через 3 дня мучений мы умели генерить PDF с нужным нам оформлением.

Сделали и забыли — работает же. Пока не случилась проблема со шрифтами. Снова намучились и снова решили. Но что примечательно — с тех пор готовой инструкции по генерации в PDF на просторах интернета не появилось. Поэтому выкладываю нашу. Внутри алгоритм с комментариями и файлами шаблона, особенностями ReST для LaTeX, которые мы собрали опытным путём.



Статья для тех, кто уже использует Sphinx, но имеет проблемы с LaTeX или PDF. Если вы только рассматривает Sphinx как инструмент документирования, будет полезно представлять, как готовить и подавать документацию в этих форматах.

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

Недавно, в попытках разобраться с nlp, мне пришла идея написать простого telegram бота, который будет разговаривать, как дерзкий гопник. То есть:

• давать ответ по слову-триггеру, как "хочу", "короче", "нет" и т.д.;
• отвечать дерзким вопросом на вопрос;
• отвечать нецензурной рифмой;
• если ничего не подходит и бот в замешательстве, отвечать злой фразой.

Для имплементации был выбран JavaScript с ES6 и Flow. Возможно, Python подошёл бы лучше, так как под него существует больше стабильных и проверенных библиотек для nlp. Но для JS есть Az.js, которого вполне хватило.

Для работы с Telegram API был использован node-telegram-bot-api.

TLDR: бот, исходный код

Осторожно, под катом присутствует нецензурная речь и детали реализации!

Я хотел рассказать про своё открытие afuse — автомонтирование файловых систем по требованию, автоматически. Разве не здорово просто сделать:

ls /mnt/remote/web.example.com/var/lib/www/

И сразу увидеть файлы web-сервера, никак не устанавливая с ним соединение специально? Я этим пользуюсь уже давно, а главное:

• Это работает из любого источника: Не важно, делаете вы указанный вывод в консоли, сохранили ссылку в MC или переходите из favorites вашего любимого менеджера такого как nautilus или dolphin
• Вы можете переходить на любой хост, куда у вас есть доступ по ключам (настроить запрос пароля тоже можно, но это не интересно)
• Вы можете запросто указать под каким пользователем входить на сервер, используя @:
  
  

  cd /mnt/remote/apache@web.example.com/var/lib/www/
  

В далекие времена, для IT-индустрии это 70-е годы прошлого века, ученые-математики (так раньше назывались программисты) сражались как Дон-Кихоты в неравном бою с компьютерами, которые тогда были размером с маленькие ветряные мельницы. Задачи ставились серьезные: поиск вражеских подлодок в океане по снимкам с орбиты, расчет баллистики ракет дальнего действия, и прочее. Для их решения компьютер должен оперировать действительными числами, которых, как известно, континуум, тогда как память конечна. Поэтому приходится отображать этот континуум на конечное множество нулей и единиц. В поисках компромисса между скоростью, размером и точностью представления ученые предложили числа с плавающей запятой (или плавающей точкой, если по-буржуйски).

Арифметика с плавающей запятой почему-то считается экзотической областью компьютерных наук, учитывая, что соответствующие типы данных присутствуют в каждом языке программирования. Я сам, если честно, никогда не придавал особого значения компьютерной арифметике, пока решая одну и ту же задачу на CPU и GPU получил разный результат. Оказалось, что в потайных углах этой области скрываются очень любопытные и странные явления: некоммутативность и неассоциативность арифметических операций, ноль со знаком, разность неравных чисел дает ноль, и прочее. Корни этого айсберга уходят глубоко в математику, а я под катом постараюсь обрисовать лишь то, что лежит на поверхности.