В первой декаде сентября без фанфар и шумихи вышел FreeType версии 2.7, и это событие, без сомнения, можно назвать праздником на улице пользователей Linux, FreeBSD, NetBSD, ReactOS и других товарищей. Попробуем разобраться, от чего у нас такое безудержное веселье.
FreeType — библиотека с открытым кодом на Си, которую используют для растеризации шрифтов и операций над ними. В новой версии по-умолчанию используется алгоритм обработки инструкций TrueType v40.

Это позволило добиться качественного субпиксельного сглаживания шрифтов, как в майкрософтовском DirectWrite/ClearType, но на самом деле никакого субпиксельного сглаживания не используется. Кроме того, алгоритм v40 рендерит быстрее Infinality, который использовался в предыдущем алгоритме v38, при этом конечный результат не хуже.

Регулярно возникает задача подключения USB-устройства к удаленному ПК через локальную сеть. Под катом изложена история моих поисков в этом направлении, и путь к готовому решению на базе open-source проекта USB/IP с описанием заботливо установленных различными людьми на этом пути препятствий, а также способов их обхода.

Доброго времени суток! Представляю вашему вниманию вольный перевод статьи от GDE (Google developer expert) Dmytro Danylyk. Собственно, вот оригинал. Статья описывает правильные подходы для работы со strings.xml и особенно полезно это будет разработчикам, которые разрабатывают мультиязыковые приложения. Прошу под кат.

(предыдущая статья)

В данной статье мы обсудим for циклы, а так же родственные понятия итераторов и «итерируемых объектов».

В зависимости от вашего предыдущего опыта с другими языками программирования данные концепции могут показаться очень знакомыми в плане синтаксиса и семантики, или же совершенно новыми и непонятными. Наиболее близкие их аналоги можно найти в Питоне, но, думаю, программисты на Java, C# или же (современном) C++ так же увидят много пересечений с тем что есть в их языках.

Вторая часть

С чего всё начиналось

Я работаю в небольшой фирме, которая разрабатывает и производит системы записи телефонных разговоров. Но в ряде случаев клиентам нужен аналоговый GSM шлюз как источник телефонной линии. Ранее его закупали и перепродавали. Но то что закупали было низкого качества и часто попадался брак — было принято решение самим разработать. Разработали мы вдвоём: схемотехник и я — программист, недавние выпускники без опыта разработок в аналоговой телефонии и без опыта внедрения в производства. Получилось, мягко говоря, не очень, хоть и была решена проблема брака и скорее «вопреки».

Но проблема в том, что для нас даже 1% брака недопустим: на каждый случай у тех поддержки и разработчиков уходило очень много времени на клиента. Да и для всех нас это недопустимо чисто из соображений профессиональной гордости. Мы хотели такой шлюз снять с производства, даже несмотря на то, что у нас была доля от каждого изделия. Это очень стыдно, когда дилеры про остальные изделия говорят: «у вас вообще брак бывает?», а про наши «мы боимся их продавать — у нас же потом ничего не купят».

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



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

C утилитой для ПК и платой — программатором,
с использованием SPL,
с полноценной системой команд и проверкой CRC32,
с гарантией доставки и переотправки сбойной или потерянной команды,
с проверками ошибок, отладочными сообщениями и урезанным printf'ом.
Оптимизирован под современные USB-UART преобразователи и потоковую передачу.

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

Моя работа связана с программированием микроконтроллеров, в частности STM32. Долгое время для работы с периферией я использовала STM32 Standard Peripheral Library, так как она предоставляется производителем и, соответственно, является наиболее полной. Однако работать с ней крайне неудобно: инициализирующие структуры зачастую избыточны, в функциях черт ногу сломит, в общем, очень скоро появляется непреодолимое желание слезть с этой библиотеки и перейти на что-нибудь более аккуратное, грамотно спроектированное и написанное «чистым кодом».

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

Одной из последних задач на работе было поднять USB MSD. Для решения задачи использовалась отладочная плата STM32F4-discovery и вот этот пример. Пример не завелся. Проблем было две:
1. Было невозможно зайти на диск и прочитать находящийся там файл.
2. Распознавание устройства как дискового занимало более 2-х минут.

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

Я уверен, что многим программистам знакома формула:


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

Вычисляет она относительную яркость цвета (relative luminance или в некоторых контекстах luma; не путать с lightness и brightness) и широко применяется для преобразования цветного RGB-изображения в Grayscale и связанных с этим задач.

Формула растиражирована и процитирована в тысячах статей, форумных обсуждений и ответов на StackOverflow… Но дело в том, что единственно-правильное её место — на свалке истории. Использовать её нельзя. Однако же используют.

Но почему нельзя? И откуда же взялись именно такие коэффициенты?

Трудно недооценить роль GPIO, особенно в мире встраиваемых систем ARM. Помимо того, что это крайне популярный материал для всех руководств для начинающих, GPIO обеспечивают способ для управления многими периферийными устройствами, выступают в качестве источника ценных прерываний, или даже могут быть единственным доступным способом общения с миром для SOC.

Основываясь на собственном скромном опыте, могу сказать, что прерывания далеко не самая освященная тема в сообществе Linux. Из-за своих особенностей, а так же сильной привязки к аппаратной части, все обучающие материалы посвященные прерываниям лишены реального и легко воспроизводимого примера. Данный факт мешает пониманию того, что очень часто прерывания и GPIO неразделимы, особенно в области встраиваемого Linux. Многие начинают верить, что GPIO это очень простая и скучная вещь (которая кстати и стала таковой благодаря подсистеме sysfs).

Недавно мне понадобилось написать 2-3-дерево и я начал искать информацию в русскоязычном интернете. К сожалению, ни на хабре, ни на других ресурсах я не смог найти достаточно полную информацию на русском языке. На всех ресурсах было одно и то же: свойства дерева, как вставляются ключи в дерево, поиск в дереве и иногда простой пример, как удаляется ключ из дерева; не было реализации.

Поэтому, после того, как я сделал то, что мне нужно, решил написать данную статью. Думаю, кому-нибудь будет полезна в образовательных целях, так как на практике обычно реализуют эквивалент 2-3- и 2-3-4-деревьев — красно-черное дерево.

Маргарет Гамильтон стоит рядом с написанным ей исходным кодом бортового компьютера «Аполлона»

Лаборатория реактивного движения (Jet Propulsion Laboratory) — научно-исследовательский центр НАСА, ответственный за большинство беспилотных космических кораблей США. Там пишут много кода, и права на ошибку у них намного меньше, чем у обычных программистов.

В JPL пишут на Си, и на их сайте есть документ "JPL Institutional Coding Standard", описывающий жесткие стандарты кодирования внутри организации. Они напоминают правила программирования для встроенных (embedded) систем и систем реального времени, с ограниченными ресурсами. Но многие из правил эти просто принципы хорошего программирования. Ограничение сложности, максимальное упрощение для последующего чтения кода и отладки, отсутствие побочных эффектов. Мы в Хекслете постоянно говорим об этом в вебинарах и, конечно, в самих курсах. Мы считаем очень важным как можно раньше поднимать эти темы, поэтому про функции и побочные эффекты начинаем говорить в самом первом курсе «Основы программирования», который рассчитан на новичков. Это бесплатный курс, кстати, и в нем есть практика на языке JavaScript.

Спасибо хабраюзеру Boletus за важную поправку и дополнение:
В 2006 году Gerard Holzmann с коллективом сформулировал 10 основных правил для JPL в документе «The Power of 10: Rules for Developing Safety-Critical Code». Они вошли в основу нынешнего стандарта, наряду с MISRA C и другими дополнениями. Статья в Википедии.

Вот перевод этого списка.

С системой RDS (Radio Data System) сталкивался хоть раз каждый, кто видел в автомагнитоле название станции вроде «Дорожное радио». Помимо названия, могут отображаться дополнительные данные — название воспроизводимой песни, температура, частота вещания и т.д.


Но как это работает? Т.к. моим хобби является радио и цифровая обработка сигналов, разобраться было интересно. Как оказалось, полной информации о RDS в рунете практически нет (да и в англоязычном тоже негусто), надеюсь, эта публикация восполнит этот пробел.

Продолжение под катом (осторожно много картинок).

В этом году на PHDays был представлен новый конкурс, где любой желающий мог перехватить управление квадрокоптером Syma X5C. Производители часто полагают, что если они используют не IP-технологии, а какой-нибудь другой беспроводной стандарт, то можно не думать о защищенности. Как будто хакеры махнут рукой, решив, что разбираться с чем-то, кроме IP, — это слишком долго, сложно и дорого.

Но на самом деле, как мы уже много раз упоминали, SDR (software-defined radio) — отличный инструмент для доступа в мир IoT, где уровень вхождения определяется уровнем добросовестности производителя IoT-решений. Однако даже не имея SDR можно творить чудеса, пусть и в ограниченном пространстве частот и протоколов.

Цель — перехватить управление дроном.

Входные данные:

• диапазон управления дроном: 2,4 ГГц ISM,
• управление осуществляется модулем nRF24L01+ (на самом деле — его клоном BK2423).

Средства (выдавались желающим): Arduino Nano, nRF24L01+.

Результат — угонщик получил Syma X8C в подарок.

Так как среди желающих угнать наш дрон оказались уже подготовленные люди, имеющие в арсенале HackRF, BladeRF и другие серьезные игрушки, мы опишем два метода — SDR и непосредственно nRF24L01+.

От переводчика:
Предлагаю вам перевод поста из блога Мэтта Стэнклиффа (Matt Stancliff), автора нашумевшей на хабре статьи Советы о том, как писать на С в 2016 году.
Здесь Мэтт делится знаниями о квалификаторе типа const. Несмотря на вызывающий заголовок, возможно, многое из того что здесь описывается будет вам известно, но, надеюсь, и что-нибудь новое тоже найдется.
Приятного чтения.

Думаете, что вы знаете все правила использования const для С? Подумайте еще раз.

Введение

В этой статье я расскажу, как профилировать и оптимизировать приложения на языке Go с использованием встроенных и общих инструментов, доступных в ОС Linux.

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

Я привел такое определение, чтобы сразу отсечь вопросы некорректной работы приложения. В этой статье мы не будем говорить о проблемах мультитредового программирования, о дата-рейсах (англ. data race), о поиске ошибок (англ. debugging). Для всего этого в Go есть свои утилиты и подходы, но оставим эту тему на будущее.

Преамбула

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

Как обычно, я стараюсь разжевать математику по максимуму, чтобы материал был доступен заинтересованному школьнику. Я глубоко убеждён, что использование математики по-хорошему должно бы быть платным: любая формула должна быть использована только тогда, когда она призвана облегчить понимание, а не для того, чтобы выпендриваться.

Итак, это уже четвёртая статья, для лучшего понимания происходящего неплохо бы прочитать предыдущие три:

• 1. Методы наименьших квадратов
• 2. Линейно-квадратичный регулятор, вводная
• 3. Управление двигателем постоянного тока при помощи линейно-квадратичного регулятора

Вот фотография системы (кликабельно):

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

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

Про Go часто говорят, что он хорош для серверов: здесь есть статические бинарники (static binaries), развитый concurrency, высокая производительность. В этой статье мы поговорим о двух последних пунктах: о том, как язык и среда выполнения (runtime) ненавязчиво позволяют Go-программистам создавать легко масштабируемые серверы и не беспокоиться из-за управления потоками (thread) или блокирующих операций ввода/вывода.

Разработка приложений на Kotlin под Android набирает популярность среди разработчиков, однако статей в русскоязычном сегменте Интернета довольно мало. Я решил немного подправить ситуацию, и написать туториал по разработке приложения на Kotlin. Мы напишем полноценное приложение с использованием всех трендовых библиотек (кроме RxJava) в мире Android-разработки. В конце у нас должно получиться расширяемое и легко тестируемое приложение (сами тесты мы писать не будем).