Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

От переводчика: Джефф Прешинг (Jeff Preshing) — канадский разработчик программного обеспечения, последние 12 лет работающий в Ubisoft Montreal. Он приложил руку к созданию таких известных франшиз как Rainbow Six, Child of Light и Assassin’s Creed. У себя в блоге он часто пишет об интересных аспектах параллельного программирования, особенно применительно к Game Dev. Сегодня я бы хотел представить на суд общественности перевод одной из статей Джеффа.

Поток должен ждать. Ждать до тех пор, пока не удастся получить эксклюзивный доступ к ресурсу или пока не появятся задачи для исполнения. Один из механизмов ожидания, при котором поток не ставится на исполнение планировщиком ядра ОС, реализуется при помощи семафора.

Раньше я думал, что семафоры давно устарели. В 1960‑х, когда еще мало кто писал многопоточные программы, или любые другие программы, Эдсгер Дейкстра предложил идею нового механизма синхронизации — семафор. Я знал, что при помощи семафоров можно вести учет числа доступных ресурсов или создать неуклюжий аналог мьютекса, но этим, как я считал, область их применения ограничивается.

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

• как устроена флэш память
• к каким проблемам приводит выключение питания в момент записи или стирания
• как эти проблемы решаются

Для желающих применить на практике — работающий код под STM32F4

Наличие USB порта в современных микроконтроллерах открывает широкие возможности для самостоятельного изготовления разнообразных управляемых с компьютера устройств. На практике, однако, выясняется, что поставляемые производителем библиотеки для работы с USB нуждаются в доработке. Если вам интересен опыт подобной доработки для двух популярных семейств МК — добро пожаловать под кат.

Предисловие переводчика

С сегодняшнего дня начинаю публикацию переведенных мною с английского языка отрывков из произведения Роберта Хайнлайна «Заберите себе правительство» («Take Back Your Government») – руководства для начинающих политиков, написанного Хайнлайном в конце 40-х годов. Часть этого материала уже опубликована мною в ЖЖ, но, думаю, начинать читать хорошую книгу сразу с середины — неправильно, поэтому начинаю публиковать с начала.

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

И, надеюсь, ее прочитают люди, подобные комментаторам статье Про открытую бухгалтерию в украинском Минобрнауки, считающие, что обычных людей нельзя подпускать к процессу принятия важных решений, ибо, как сказал Уинстон Черчилль,— «Демократия несовершенна, но ничего лучше человечество пока не придумало».

В этой статье я расскажу о том, как можно захватывать аналоговый черно-белый видеосигнал с помощью платы STM32F4-DISCOVERY, и об особенностях передачи его на компьютер при помощи USB.

Приветствую вас, уважаемый хабрачеловек!
Предлагаю вашему вниманию бесплатно серияю видеоуроков в котрых рассмотренно базовые понятия разработки под Android.

Желание написать об C++ API у меня возникло давно, и вот наконец выдался спокойный вечер. По роду деятельности я и мои ребята пишем код на C++ для программистов на C++ и Python, общее ядро функционала, который используется во всех продуктах нашей компании. Разумеется это подразумевает, что код должен иметь интуитивно понятный API, с общей логикой как для низкоуровневого C++, так и для высокоуровневого Python, вне зависимости от разночтения в языках некоторых базовых конструкций. Об объединении C++ и Python я много писал ранее в статьях про Boost.Python, сейчас я очень благодарен архитектуре и логике языка Python, я многое понял и перенял в С++ именно благодаря опыту построения общего API для этих двух таких разных языков, но сейчас речь пойдёт только и исключительно о C++, про API и про то, что такой зверский гибкий язык позволяет сделать с интерфейсом вашей замечательной библиотеки, если не учитывать ряд важных особенностей языка C++.

Проблемы и требования к драйверу

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

1. Отсутствие структуры драйвера. Решение данной проблемы позволить лучше ориентироваться по драйверу, следовательно, отладка становится проще.
   
2. Отсутствие общности драйвера. То есть интерфейс драйвера должен быть одинаковый, для, хотя бы, линейки процессоров, и в идеале для аналогичных процессоров разных фирм. Это позволит переносить код, завязанный на драйвер, без изменений или с минимальными изменениями.
   
3. Сохранение эффективности по скорости выполнения драйвера.
   
4. Оптимальное использование памяти.
   

В данном посте я покажу, как можно ликвидировать эти проблемы и сделать процесс написания драйвера более приятной задачей на примере двух драйверов UART и DMA реализованных на языке С++. Для этого я сформулировал требования, для драйвера: