В марте мы собирались на митапе по С++ в Санкт-Петербурге. Для всех, кто не смог присоединиться к встрече, подготовили записи докладов и дискуссии с экспертами из YADRO, VK и Kaspersky, а также создателем Sphinx Андреем Аксёновым. Почему стоит сохранить подборку в закладки:

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

• Эксперт из PVS-Studio покажет, почему линтеры не всегда подходят для поиска ошибок и какое решение использовать вместо них, чтобы не навредить безопасности сервиса.

• Инженеры с многолетним опытом работы на С++ поделятся опытом проведения код-ревью — возможно, вы найдете в их практиках что-то полезное или просто посмеетесь вместе с участниками дискуссии.

Привет, Хабр! Меня зовут Николай, я разработчик С++ в SimbirSoft. В этой статье я хочу поделиться своим опытом применения алгоритмов. 

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

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

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

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

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

Так, на днях искал материалы про JIT компиляцию C++ в рантайме с помощью clang/llvm и поиск мне выдал мою же собственную статью трехгодичной давности: Динамическая JIT компиляция С/С++ в LLVM с помощью Clang / Хабр. В результате появилась уже эта новая статья про JIT компиляцию C/С++.

Стоит только коснуться производственной специфики, как стандартные подходы разваливаются на куски — даже если у вас уже есть огромная дизайн-система на основе популярной методологии Material Design. Я — Аня Труфанова, делаю дизайн для MES (manufacturing execution system). Нам пришлось взять дизайн-систему и наполнить ее уникальными фичами и кастомными компонентами, адаптированными под нестандартные условия. Сейчас я поделюсь, что именно мы переосмыслили и какие фичи добавили.

Всем привет. В рамках проекта от компании Acronis со студентами Университета Иннополис (подробнее о проекте мы уже описали это тут и тут) мы изучали последовательность загрузки операционной системы Windows. Появилась идея исполнять логику даже до загрузки самой ОС. Следовательно, мы попробовали написать что-нибудь для общего развития, для плавного погружения в UEFI. В этой статье мы пройдем по теории и попрактикуемся с чтением и записью на диск в pre-OS среде.

Написать этот материал меня побудило... отсутствие хороших статей по корутинам в C++ в русскоязычном интернете, как бы странно это не звучало. Ну серьезно, C++20 существует уже несколько лет как, но до сих пор почти все статьи про корутины, что встречаются в рунете, относятся к одному из двух типов. Или обзор начинается с самых глубин и мелочей, пересказывая cppreference, а потом автор выдыхается и все сводится к "ну а дальше все понятно, возьмите и примените это в своем коде", что напоминает известную картинку с совой. Либо иногда в статьях рассматривается применение корутин на примере генераторов, и этим все и ограничивается. Но, давайте будем честны, генераторы — это замечательно, но за все время моей многолетней карьеры разработчика я, вероятно, делал что‑то подобное генераторам разве что разок, в то время как асинхронный ввод‑вывод приходится использовать почти в каждом проекте. И поэтому меня гораздо больше интересует реализация асинхронного ввода‑вывода с использованием корутин, а не генераторы. Поэтому пришлось разбираться во всем самому.

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

Сделали простой и понятный чек‑лист, который поможет вам подготовиться к интервью с подрядчиком и объяснить, чего вы ждете от будущего сайта.

Эти советы универсальны, они никак не касаются типа разработки. Чек‑лист скорее направлен на сбор информации и материалов, которые позволят создать конверсионный ресурс и отразить в нем необходимые ценности и миссии бренда. Теперь обо всем по порядку.

Получилось отследить довольно интересные тренды: как размер стажа в индустрии коррелирует с отношением к выдумыванию опыта в резюме, как в IT-среде на самом деле относятся к выпускникам школ в стиле «стань айтишником за год», а также рейтинг самых ненавидимых и респектуемых в среде профи школ.

Привет, Хабр! Я Владимир Хрыпун, руководитель центра компетенций по развитию BPM-систем в Первой грузовой компании. Сегодня разберем с вами, чем бизнес-аналитик отличается от системного и почему для проектов цифровой трансформации вам нужно два специалиста. Статья будет полезна менеджерам, продуктам, руководителям проекта. Всем кому надо объяснять, или кто сам хочет разобраться, в чем отличие бизнес и системных аналитиков. 

Часто всем участникам проекта хочется оптимизировать трудозатраты и бюджет. И очень светлая мысль, которая возникает у каждого второго продукта или РП: “А давайте у нас будет один аналитик, который сделает всё!”. У руководителей более высокого уровня, топов и собственников это идея возникает в 9 случаев из 10. В результате сроки сорваны, бюджет превысили в два раза. Почему так происходит и будет происходить разберем ниже. 

Основную идею этой статьи донесу через аналогию, а затем разберемся предметно. 

Представьте, вы участвуете в соревнованиях по многоборью. Надо преодолеть дистанцию за максимально короткое время. И вам как менеджеру команды можно набрать любое количество спортсменов, которое может позволить бюджет. Вы заранее знаете, какую местность надо преодолеть. Допустим, это будет, равнина, озеро и отвесная скала. 

С отвесной скалой все понятно. Точнее понятно, что ничего не понятно – нужны подготовленные спецы, которые быстро заберутся наверх и при этом не разобьются в лепешку. Поэтому профессионального скалолаза берем в команду 100%. А вот с равниной и озером не все однозначно – ведь плавать и бегать все умеют. Есть большой соблазн взять в команду одного спортсмена, а на сэкономленные деньги и время еще и интерфейс в синий покрасить. Вот так и формируются команды разработки, где есть выделенные разработчики (скалолазы) и аналитики (бизнес и системный анализ в одном флаконе). 

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

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

Всем привет! Меня зовут Сергей Бережной, я работаю в Яндексе уже 18 лет: в 2005 году пришёл разработчиком интерфейсов, потом руководил подразделениями разного размера, а сейчас я директор по взаимодействию с разработчиками. Ещё я много занимаюсь обучением: в рамках наших сезонных школ и в Практикуме (где я работал над курсом «Управление командой разработки»).

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

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

Привет! Меня зовут Грановский Олег, я эксперт по внедрению таких систем автоматизации, как АРС и МПА (описание инструментов на рис.1 и ниже). Раннее на habr уже говорили о таких инструментах, как АРС и RTO (1, 2). Эта статья является продолжением серии обсуждения цифровых систем автоматизации производственных процессов и раскрывает их место в концепции «цифрового завода». Мы постараемся разобраться в одном из его элементов – МПА (Модульная Процедурная Автоматизация).