Привет! Я Егор Ерусланов, Qt-разработчик.

В Android-приложение 2ГИС мы добавили новый режим PiP (Picture-in-Picture, или «картинка в картинке»). С PiP наши пользователи смогут следить за маршрутом в маленьком плавающем окне на основном экране. Например, когда нужно быстро прочитать сообщение или включить подкаст и при этом сохранять фокус на навигации. Режим PiP — это не просто «приятная мелочь», а функциональность, которая подстраивается под новые требования пользователей навигатора. 

В этом посте поделюсь, как решал несколько трудностей, которые встретились при разработке этой функции.

Шёл 2025 год, а я задался вопросом: «Не пора ли нашей команде выбрать стандарт языка Си, на котором будет вестись основная часть разработки?» С одной стороны кажется, что этот вопрос давно должен быть решён, стандарт языка указан в code style, конечно, после «холиваров», череды обсуждений, обид, проклятий и прочих маленьких трагедий. А если нет? А если нет, то так ли это важно? Что там нового может быть в языке Си? Стоит ли этот вопрос вообще того, чтобы тратить время? В этой заметке поделюсь с уважаемым читателем тем интересным, что я узнал и вспомнил во время неспешного исследования этого вопроса, относительно холодными и тёмными вечерами.

Не так давно я проводил аудит кодовой базы на работе и заметил, что, несмотря на высокое качество кода, я очень быстро уставал умственно и с трудом мог работать с текстом кода продолжительное время.

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

Сегодня мы погрузимся в результаты этого исследования, то есть вместо того, чтобы визуализировать код, мы поговорим о визуальных паттернах кода - тех, которые буквально заставляют мой мозг болеть!

Предупреждение! Это туманная и плохо изученная область. В исследовании использовались различные источники: популярные метрики, научные статьи и практические мнения (включая мое собственное). Но в конце пути мы сведем всё ниже к 8 визуально различимым свойствам, которые помогут программистам любого языка улучшить читаемость кода.

По просьбе некоторых комментаторов "что-то написать самому и выложить на обозрение" - ну вот, написал и выкладываю:

Суть задачи: как, не имея установленного современного Desktop Environment, с Network Manager и systemd, управлять подключением к Wi-Fi сетям без особых проблем?
Усложнение: допустим, у нас к тому же несколько Wi-Fi адаптеров, для одновременного подключения к нескольким сетям.

Легко!
Но для начала - немного о том, "как это работает под капотом" (кому неинтересно - проскакиваем)

Недавно посмотрел на ютубе видео, в котором поднимается проблема того, что на место классических программистов‑кодеров приходят «программисты»‑prompt‑инженеры.

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

И рассуждения я начну с вопроса — «ну и в чем проблемы?»

Цель этого эссе — убедить вас в том, что мы не должны отправлять людей на Марс, по крайней мере, в ближайшее время. Высадка на Марс с существующими технологиями была бы разрушительным, расточительным трюком, единственным наследием которого был бы крах величайшего эксперимента по естественной истории в Солнечной системе. Она откроет новую эру космических полётов не больше, чем финикийский мореплаватель, пересёкший Атлантику в 500 году до нашей эры, открыл бы Новый Свет. И это даже не будет так весело.

Полёт на Марс будет похож не на «Аполлон», а на длинную серию полётов в никуда, типа полётов на МКС. Если ваша главная претензия к Международной космической станции заключается в том, что она слишком захватывающая, а вид на Землю из окна слишком отвлекает от работы, то вам понравится наблюдать за тем, как МКС-младшая дрейфует, исследуя поведение костей в глубоком космосе. Но если вы считаете, что ракеты, приключения, исследования и открытия интереснее, чем подсчёт опухолей у мышей, то медленная и боязливая марсианская программа разобьёт вам сердце.

Привет, Хабр!

Сегодня мы рассмотрим, как создать безопасные FFI-интерфейсы в Rust для интеграции с C/C++ библиотеками

Если говорить проще, FFI (foreign function interface — интерфейс вызова внешних функций) – это способ «позаимствовать» функциональность из другого языка. В контексте нашей статьи, с одной стороны у нас Rust, где каждый байт памяти охраняется компилятором, а на другой C++, где свобода обращения с памятью может обернуться утечками или, что еще хуже, непредсказуемым UB (англ. undefined behavior, в ряде источников непредсказуемое поведение). И наша задача – сделать так, чтобы эти два мира не конфликтовали, а работали в унисон.

Хабр, привет! Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT-отделом 8 и работаю в компании Софтонит. Мы разрабатываем ПО для автоматизации ИТ-отделов. Сегодня хочу поговорить про conventional commits и про свой личный опыт работы с коммитами. На самом деле это бездонная тема, о которую сломано много копий. Кто-то пишет и делает коммиты так, кто-то эдак. В посте попробую поразмышлять о том, как делать не надо и о придуманных на этот счет правилах и договоренностях.

Начинающие (а иногда этим грешат и опытные) разработчики, не до конца понимают принципы создания и работы над коммитами в git. Тут имеется ввиду не механика и команды типа “git commit …”, а общие и глобальные вещи. Например:

1. А когда делать коммиты?
2. Что в них писать?
3. Есть ли какие-то общие правила для их создания?
4. Как не надо коммитить?

Если ты начинающий разработчик, то эта статья точно тебе пригодится. А если у тебя огромный опыт и ты думаешь, что тебя уже ничем не удивить, то… Не будем торопиться… Давай проверим?

Чтобы показать, что это вообще возможно, пришлось взять в качестве отправной точки (универсальный) прикладной пример

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

Система сборки CMake имеет в арсенале достаточно мощный инструмент - пресеты, шаблоны, называйте как угодно. В данной статье будет рассмотрено применение пресетов на примере модульной библиотеки реализующей функционал engine-а для OpenSSL и описано как перенести опции для кросскомпиляции в пресеты.

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

Дистанционная фотоплетизмография (ДФПГ, rPPG) — это метод измерения пульса по видеозаписи. Он потенциально применим в телемедицине, а также для оценки эмоционального состояния людей, например водителей и пилотов, но пока не получил широкого распространения из-за чувствительности к различным искажениям. 

Метод базируется на регистрации едва заметных изменений цвета кожи при увеличении объёма кровеносных сосудов после каждого сокращения (систолы) левого желудочка сердца. 

Существующие системы ДФПГ достаточно надёжны только в идеальных условиях. Если же человек использует макияж, частично закрывает лицо, движется, или в кадре меняется освещённость, то частота его сердечных сокращений определяется неверно. 

В отделе перспективных исследований компании «Криптонит» предложили использовать для ДФПГ новый метод, который устраняет эти недостатки за счёт более эффективного подхода к регистрации и анализу видеосигнала. Вместо привычного цветового пространства RGB используется CIELAB, поскольку в нём светимость выделена в отдельный канал. Это позволило отсечь артефакты, связанные с изменениями освещения в кадре. 

Для записи видео в эксперименте использовалась недорогая веб-камера Logitech 720p, из которой был удалён инфракрасный (ИК) фильтр. Это было сделано для того, чтобы исключить влияние макияжа на измерения, так как длинноволновое излучение лучше проникает через него. 

Системы типов помогают разработчикам создавать надежные и безопасные программы. Однако такие термины, как «субструктурные типы» или «владение», нередко кажутся сложными и трудными для понимания, особенно для тех, кто не сталкивался с теорией типов в академической среде.

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

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

Традиционные подходы к тестированию на многих уровнях уже не успевают за реалиями разработки: ручное тестирование становится слишком трудоёмким, а написание unit- или end-to-end-тестов не всегда позволяет отследить именно визуальные изменения. И здесь на помощь приходит методология скриншотного тестирования — мощный инструмент для выявления визуальных багов, появляющихся в интерфейсе. Он позволяет убедиться в том, что ваш продукт отображается так, как задумано, и избавляет команду от многих сюрпризов.

В первой статье мы разобрали, что такое платформа в целом. Теперь между нами есть контекст и можем задаться вопросом «Как начать строить такую платформу в своей компании?». Собрать «снизу», как энтузиасты-разработчики, или спустить директиву «сверху», как решило руководство? Давайте разберёмся, какие бывают варианты

Или почему все хотят стать «платформой», даже если не знают, как это работает

Вы замечали, что сегодня все компании — от гигантов типа Netflix до маленького стартапа по записи калорий и БЖУ — вдруг стали «платформами»? Это не просто хайп. Платформенная инженерия — как кислород для цифрового бизнеса: незаметно, но критично. Но что это такое, и почему без нее теперь как без рук? Давайте разбираться без заумных терминов.

Если коротко, то платформенная инженерия - это когда решив, что у вас есть гениальная идея, которая нанесёт непоправимую пользу компании, вы занимаетесь только ею, а не погибаете на этапе логирования, мониторинга, авторизации пользователей и прочих функций, который часто ctrl+c ctrl+v из проекта куда у вас есть доступ.

Если чуть дольше, то...

Современное производство программного обеспечения — сложный процесс, от разработчика требуется не только писать код, но и справляться с целым комплексом сопутствующих задач: отслеживать изменения, проводить тестирование, соблюдать стилистические правила и внутренние стандарты, учитывать безопасность и применять best practices по обеспечению ИБ уже во время написания кода.

Но есть и хорошие новости. Разработчику доступно большое число инструментов, которые упрощают труд: от линтеров до анализаторов и систем автоматизированного тестирования — все они встраиваются в среду разработки и помогают решать сложные задачи, не отвлекаясь от творческой части работы. В этой статье я, Евгений Иляхин, архитектор процессов безопасной разработки в Positive Technologies, как раз расскажу о крайне полезных инструментах, которые автоматизируют рутину и повышают качество кода, позволяя программисту сосредоточиться на разработке новой фичи или поиске оптимального решения.