В 1971 году английский физик-математик и лауреат Нобелевской премии Роджер Пенроуз предложил, как можно извлечь энергию из вращающейся чёрной дыры. Он утверждал, что это можно сделать, создав своего рода «упряжь» вокруг аккреционного диска чёрной дыры, где падающая материя разгоняется до скорости, близкой к скорости света, что приводит к выделению энергии в нескольких длинах волн. С тех пор многие исследователи предполагают, что продвинутые цивилизации могут использовать этот метод (процесс Пенроуза) для энергетической подпитки своей цивилизации и что это может быть явным технопризнаком – признаком работы внеземного разума — который мы можем засечь.

Автор оригинала Скотт Чакон — сооснователь GitHub и основатель нового клиента GitButler. Этот клиент ставит во главу угла рабочий процесс и удобство разработки, в том числе код-ревью, и не является просто очередной обёрткой над CLI git.

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

• условной конфигурации;
• git blame и git log с диапазонами строк;
• git blame с отслеживанием;
• git diff по словам вместо строк;
• запоминании разрешения конфликтов.

Представлена утилита-надзиратель, что последовательность определения static функций совпадает с последовательностью объявляения static функций.

Предисловие

Современные компиляторы обладают огромным количеством диагностик. И удивительно, что очень малая их часть включена по умолчанию.

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

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

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

Нередко при отладке ПО микроконтроллера возникает необходимость вывода отладочных сообщений, логов, захваченных данных и прочего на экран ПК. При этом хочется, чтобы и вывод был побыстрее, и чтобы строки отображались не где-нибудь, а прямо в IDE — не отходя от кода, так сказать. Собственно, об этом и статья — как я пытался printf() выводить и отображать внутри любимой, но не очень микроконтроллерной, среды Qt Creator.

Сегодня необычный для меня формат статьи: я скорее задаю вопрос залу, нежели делюсь готовым рецептом. Впрочем, для инициирования дискуссии рецепт тоже предлагаю. Итак, сегодня мы поговорим о чувстве прекрасного.

Я довольно давно пишу код, и так вышло, что практически всегда на C++. Даже и не могу прикинуть, сколько раз я написал подобную конструкцию:

for (int i=0; i<size; i++) {
    [...]
}

Хотя почему не могу, очень даже могу:

find . \( -name \*.h -o -name \*.cpp \) -exec grep -H "for (" {} \; | wc -l
43641

Наш текущий проект содержит 43 тысячи циклов. Проект пилю не я один, но команда маленькая и проект у меня не первый (и, надеюсь, не последний), так что в качестве грубой оценки пойдёт. А насколько такая запись цикла for хороша? Ведь на самом деле, важно даже не то количество раз, когда я цикл написал, а то количество раз, когда я цикл прочитал (см. отладка и code review). А тут речь очевидно идёт уже о миллионах.

На КПДВ узел под названием «совершенная петля» (perfection loop).

Так каков он, совершенный цикл?

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

В своём посте благодарности я хочу перечислить не имена людей, а интерфейсные и программные решения, которые здорово упростили мне (как и многим другим пользователям) жизнь в IT-мире. Впрочем, за каждой программой стоят её создатели. Поэтому мой список — это прежде всего выражение признательности тем прекрасным людям, которые смогли реализовать что-то действительно удобное и полезное.

Привет, любители старого «железа». Это Антон Комаров, и сегодня мы изучим ИТ-артефакт, одно из имен которого — Breadbox Ensemble. Это графическая оболочка для MS-DOS, которая значительно опередила свое время. К примеру, концепция меню «Пуск» в ней появилась на 2,5 года раньше, чем в Windows 95. Компанию-разработчика, Berkeley Softworks, пытались купить Microsoft, Apple Notebooks и Sun Microsystems. Но руководство не согласилось, решив продолжить самостоятельное «плавание». И оно было довольно успешным: последняя версия оболочки вышла аж в 2009 году.

Так что заваривайте себе чайку, доставайте печеньки и давайте посмотрим, ради чего в начале 90-х шла нешуточная борьба между крупнейшими софтверными корпорациями. И как Breadbox Ensemble повлияла на внешний облик операционных систем того времени. Приятного чтения.

Введение

После прочтения названия может возникнуть закономерный вопрос: зачем в наше время изучать программную реализацию low-speed USB, когда существует куча дешевых контроллеров с аппаратным модулем? Дело в том, что аппаратный модуль, скрывая уровень обмена логическими уровнями, превращает протокол USB в своеобразную магию. Для того же, чтобы прочувствовать как эта «магия» работает, нет ничего лучше, чем воспроизвести ее с нуля, начиная с самого низкого уровня.

С этой целью попробуем изготовить на основе контроллера ATmega8 устройство, прикидывающееся USB-HID'ом. В отличие от распространенной литературы, мы пойдем не от теории к практике, от самого нижнего уровня к верхнему, от логических напряжений на выводах, и закончим «изобретением» той самой vusb, после каждого шага проверяя, работает ли код как ожидалось. Отдельно отмечу, что не изобретаю альтернативу этой библиотеке, а напротив, последовательно воспроизвожу ее исходный код, максимально сохраняя оригинальную структуру и названия, поясняя, для чего служит тот или иной участок. Впрочем, привычный для меня стиль написания кода отличается от стиля авторов vusb. Сразу же честно признаюсь, что помимо альтруистического интереса (рассказать другим сложную тему) имею и корыстный — изучить тему самостоятельно и через объяснение выловить для себя максимум тонких моментов. Отсюда же следует, что какой-то важный момент может быть упущен, или какая-то тема не до конца раскрыта.

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

Также отмечу, что рассматривается только low-speed USB, даже без упоминания, чем отличаются более скоростные разновидности.

Одним погожим днём, я нашёл МК-52 и тут...