Разработка

Впервые про моделирование эволюции я прочитал в 13 лет в статье «Жить и умереть в компьютере» (Техника — Молодежи, №5 1993 год). Она произвела на меня столь неизгладимое впечатление, что я тут же загорелся идеей создать что-то подобное.

Однако никак не удавалось проработать законы мира. Как организмы будут «смотреть» на окружающий мир? Как общаться? Как атаковать? Как кушать друг друга? Наконец, как будет устроен их «мозг»? Реализовать виртуальную машину, как в статье из журнала, или использовать что-нибудь проще, типа конечного автомата или схемы из блоков И-НЕ?

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

Нет, это не шутка и не кликбейт. Такое действительно возможно — правда через небольшой хак.

Недавно я задался вопросом: а возможно ли написать для ARM нативную программу, которая будет бесшовно работать сразу на 4-х операционных системах без необходимости перекомпиляции для разных платформ и ABI. Мне очень хотелось реализовать возможность писать кроссплатформенные эльфы для мобильных телефонов из нулевых и попытаться портировать на них эмуляторы ретро-консолей. Погрузившись в документацию на исполняемые форматы, я пришёл к выводу, что да — это возможно и смог реализовать такую программу на практике без читерства по типу VM! Всех гиков приглашаю под кат!

Какие автомобильные компании Китая самые сильные и крупные? Какие марки самые популярные? Кто кого производит? Кто кем владеет? Кто с кем конкурирует? Раскладываем по полочкам, как устроена автомобильная индустрия Китая. После этой статьи у вас сложится цельная и понятная картинка.

tl;dr: как обойти внутреннюю цензуру «Шедеврума» и получить то, что хочешь. Описание реализованных состязательных атак с примерами реализации. Без глубокого раскрытия механизма почему так получается.

Эта статья описывает использование улучшенного социального подхода к программированию SOSAL в реальных проектах и ситуациях, а также содержит рекомендации для более эффективного применения этих принципов. Скорее под кат!

Я давно пользуюсь кодогенерацией. Ещё во времена Yii фреймворка мне нравилось, что одним кликом мышки можно было сгенерировать CRUD с бэкендом, таблицами и формами. Backbone.js сразу из коробки обеспечивал REST API запросы и другие фичи. Между тем временем и нынешним днём — целый пласт инструментов для автоматизации, бутстрапинга и шаблонизации разработки. Приходилось и хрюкать, и глотать. То, что всё это, мягко говоря, так себе — уже отдельная история. Местами стало даже хуже. Хуже, чем когда вы неделю возились с конфигом Webpack.

В этой статье мы рассмотрим вайбкодинг. В чистом виде так сказать.

Привет! Сегодня мы выложили в опенсорс Perforator — систему непрерывного профилирования (continuous profiling), которую используем внутри Яндекса для анализа производительности большинства сервисов.

В Github-репозитории доступен исходный код системы и инфраструктура для развёртывания своей инсталляции Perforator на кластере Kubernetes. Кроме того, Perforator можно использовать на своём компьютере как более простую замену perf record: профили получаются точнее, а оверхед меньше. Исходный код доступен под лицензией MIT (и GPL для eBPF-программ) и запускается под x86-64 Linux.

При помощи Perforator и прошлых подходов к задаче профилирования мы регулярно оптимизируем самые крупные сервисы в Яндексе, например Баннерную крутилку или Поиск, на десятки процентов. Кроме того, Perforator реализует недостающий в опенсорсе компонент профилирования для простой автоматической оптимизации программ с использованием profile-guided optimization. Наши тесты показывают, что использование PGO даёт ускорение около 10% в разных сценариях.

Под катом поговорим про профилирование под Linux, опишем вызовы и сложности, возникающие при профилировании, изучим, как устроен Perforator внутри, и обсудим, как можно использовать полученную систему.

C++ ISO Standards Group, организация, отвечающая за стандартизацию языка C++, так же известная как WG21, исключила из своих рядов longtime-контрибьютора после того, как тот использовал простое слово "question" ^{(рус. - "вопрос")} в названии одной из своих работ.

И да, это безумно ровно настолько же, насколько звучит.

CryEngine2 использовал класс собственный CString для реализации работы со строками и немного использовал строки из стандартной строковой библиотеки Windows. Насколько я помню, последняя версия CryEngine всё ещё использует те же самые CString, она кардинально поменялась внутри, но как дань истории название класса менять не стали, зато сильно расширили функционал. Я не на 100% уверен, применялся ли CString только в редакторе или в рантайме игры тоже, вы можете сами это посмотреть в исходниках, которые все еще доступны на гитхабе. Это один подход к работе со строками, довольно распространенный в мире игростроя - когда мы все нужное пишем сами, не оглядываясь... хотя, тут больше уместно слово поглядывая, на существующие реализации и утаскивая в проект все самое лучшее.

Есть и другой подход... Я работал в команде над некоторым проектом, который должен был выйти на консолях, и в какой‑то момент на проект пришел эффективный тимлид, который хорошо умел в красивые презентации, и продавил использование std::string из sdk. Все очень опытные программисты, синьоры и руководство важно кивали на совещании и согласились всё перевести на std::string… не такие уж они оказались опытные, как выяснилось. В итоге мы заменили большую часть CString на std::string. Не сказал бы, что это сильно повлияло на время компиляции — плюс‑минус минута к проекту, который собирается двадцать минут, особой погоды не делают, но это также превратило наш довольно понятный базовый код в запутанный кошмар. Возможно, для переносимости это было лучше, но ни наш проект, ни CryEngine2 Editor так и не были портированы ни на Linux, ни на какую‑либо другую платформу.

Прошло десять лет, я вижу ровно туже ситуацию на текущем проекте — новый тимлид решил перевести местный MySuperPupeString на std::string, уже предчувствуя «нижней чуйкой» последствия — запасаюсь попкорном и беру отпуск на следующий месяц после принятия решения. Но не это интересно, а то — какие вообще строки могут быть в вашем с++ коде.

Привет, друзья! Примерно раз в год я пишу большой пост о развитии проекта far2l — порта Far Manager под Linux, MacOS и BSD. И, должен сказать, 2025-й выдался невероятно продуктивным! Накопилось столько всего вкусного, что пора поделиться с вами очередным выпуском нашего дайджеста. Под катом — обзор двух больших и двух небольших, но очень ценных нововведений, которых мы все очень долго ждали.

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

Однажды моя команда закончила работу над довольно интересным проектом, который портировали больше двух лет на плойку. Движок старый, большой и мощный, но работа с памятью была ориентирована на ПК времен конца 2000-х, и что меня поразило, так это насколько сильно большая часть кодовой базы зависела от динамической памяти во время выполнения. На ограниченном железе (далеко не у всех есть PS5 pro) и в условиях жёстких требований к сертификации на консолях такие решения быстро превращаются в проблему.

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

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

IP сообщает, откуда пришёл запрос, и на этом всё. Он не сообщает, какой язык нужен пользователю, на каком языке он говорит и какой язык понимает. Подобная система постоянно ломается — VPN, путешествия, эмиграция, страны с несколькими официальными языками. Это не умное, а раздражающее решение.

Сегодня в очередной раз наткнулся на вакансию старшего инженера - схемотехника в Яндекс. Решил, что это знак и настало время разобрать их тестовое задание. Звучит оно следующим образом:

Надругательство над C#, C++ и HLSL, игрища с булками и буферами, тройная полиглотность, SIMD, пепекторы, DirectX, экономия 800 Тб ОЗУ, новая парадигма программирования, многопроцессность, быстрая степень и многое другое.

В этой части я расскажу, как делал софт на собственном фреймворке, который управляет ядерной подсветкой и механической видеостеной.

3 года назад я рассказывал как я делаю опенсорсную табличку "Я Занят". С тех пор проект полностью перешел внутрь Flipper Devices и его разрабатывает та же команда, что и Flipper Zero.

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

Речь пойдет о тайной, сугубо анонимной организации, следы которой начал замечать еще в 2018-ом, работая в Яндексе. О целях и мотивах организации можно только догадываться: некоторые считают это кибер-луддизмом, другие — техно-анархизмом. Ясно одно: организация существует, ее члены уничтожают кодовые базы десятилетиями, и говорить об этом не принято.

После каждой новой статьи с заголовком «ООП — это обман» хочется напомнить: ООП — это не набор шаблонов из книжек, а инженерный подход. Если проект страдает от наследования и DI, возможно, проблема не в ООП. А в том, как вы его применяете.

Привет, Хабр! Последнее время здесь появились очень интересные статьи по вакуумному и стеклодувному делу, вызывающие неподдельный интерес у публики. Как насчет двинуться дальше, и начать серию статей про изготовление микросхем на дому? Многолетнюю, разумеется. Я по другому не умею :)

Тут вам и легирование кремния, и фотолитография, и вакуумное магнетронное и термическое напыление металлов и оксидов на подложку.

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