Программирование *

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

Меня зовут Катя Орешкова, и я работаю над Mailion — корпоративной почтовой системой от компании МойОфис. Основное ядро продукта написано на Go, но в целом технологический стек включает множество языков и технологий: Go, Java, Python, PHP, C++, C# (бэкенд), а также JavaScript/TypeScript с React (фронтенд). Продукт состоит из десятков модулей, предоставляет сотни функций и поддерживает до миллиона пользователей, что требует глубокой проработки архитектуры, разработки и интерфейсов.

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

В std::move никто никуда не двигается

В undefined behavior поведение вполне себе определено, просто крашит игру

В GameObject нет ни игры ни объекта, а только баги и куча антипаттернов

Memory leak detector сам протекает

В PhysicsEngine физики столько же, сколько в сказке про Колобка

Из 8 часов работы 6 уходят на попытку собрать билд после мержа со стейблом.

В ProfileMode тормозит всё кроме профайлера

В retrospective meeting обсуждают, почему всё плохо, но оставляют как есть.

В debug билде багов меньше чем в релизном и выше фпс

Привет, Хабр! Я Тимофей Милованов, ведущий Golang-разработчик в команде VoiceKit, где мы занимаемся голосовыми технологиями. Мы разрабатываем сервисы по распознаванию и синтезу голоса, преобразованию одного голоса в другой, а еще голосовой биометрией.

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

Для «движка», разработанного мной для моей игры, я использую карты высот пиксельной графики, чтобы реализовать различные крутые эффекты: динамическую высоту воды, пересекающуюся геометрию, декали, 3D-освещение и даже z-сортировку сцены.

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

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

О том, как в рамках кейса мы избавились от спагетти-зависимостей, поделили сервис на чёткие слои, упростили поддержку и масштабирование кода, — рассказываем под катом. Плюс делимся рекомендациями: кому и при каких сценариях связка «DDD Lite + микросервисы» может пригодиться.

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

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

Всем привет! Меня зовут Василий Куликов, я работаю ведущим разработчиком в Техплатформе Екома и Райдтеха Яндекса и последние пять лет разрабатываю фреймворк userver.

Это веб‑фреймворк, который позволяет создавать высоконагруженные отказоустойчивые сервисы на С++. Сегодня я расскажу, как написать на нём игрушечный, но рабочий сервис, который реализует функциональность pastebin.

Игра Rogue знаменита не только тем что породила и вдохновила огромное количество "потомков" - от визуально схожих Moria и NetHack до графически продвинутых вроде DIablo. Знаменита она ещё и тем что является одной из самых сложных игр для прохождения (в этом классе она гораздо интеллектуальнее чем Flappy Bird). Не уверен что вы найдете даже по форумам человека который скажет что проходил её (не читеря с файлами сохранения). А может такие есть среди вас?

Я заметил что современная опенсорсная версия (например доступная в пакетах для разных Linux и BSD) отличается от той, например, что была портирована коммерчески под ДОС где-то в 80е. Заметно отличаются монстры - чуть ли не со 2 уровня уже можно напороться на Ледяного Монстра который не только лишает подвижности но ещё и активно дамажит. Как будто и без того сложная игра стала ещё сложнее!

Дело в том что ранний код Rogue изначально не был доступен публично - кроме того авторы опенсорсной версии хотели избежать возможных нарушений прав (т.к. существовали уже коммерческие порты).

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

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

Идея статьи родилась после прочтения многочисленных источников в интернете по барьерам и моделям памяти.Так же, был просмотрены соответствующие видео с разъяснением. Много где в целом всё достаточно хорошо разжевано. Статья не претендует на исчерпывающий материал. Скорее, это обзорное описание на тему модели памяти в связке с RISC-V. Не рассчитана на entry level, рекомендуется сперва почитать что нибудь вводное.

Навряд ли кому то необходимо детальное знание внутренней архитектуры процессора на уровне RTL (register-transfer level), как и глубокого понимания принципов модели памяти, согласованности. Да и обычно вся эта информация берется из соответствующей литературе от производителя, других книгах по оптимизации. Предполагаю, что авторы в том или ином виде могу знать более глубокие вещи, чем представлены в открытых источниках. Возможно, они работали в компании производителя (Intel, например), общение, конференции, сообщества.

Но может ли быть источник лучший, чем исходники CPU? Навряд ли. Вы не найдете в открытом доступе исходники процессоров Intel, AMD и любых других. ARM за это денежки получает, продавая права на архитектуру и готовые спроектированные блоки. А вот для RISC-V такой источник есть - исходники полноценного суперскалярного out-of-order процессора от Berkley.

Не так давно был разработан язык Chisel на замену Verilog и аналогов. Он на базе Scala. А, так как это Scala, мы можем использовать IDE и внятную навигацию по исходникам. Но в исходники просто так не пойдешь, сперва надо приобрести необходимые фундаментальные знания, чтобы понимать в целом что такое разработка на уровне RTL. Неплохо бы разобраться с Verilog и с базовыми понятиями - всякие там защелки, регистры, мультиплексоры и тп. Это я и решил сделать и начал с книги “Паттерсон, Хеннесси: Архитектура компьютера и проектирование компьютерных систем”. Она безумно крутая и очень понятная. Затем прочитал несколько книг по FPGA и Verilog и даже купил учебную FPGA плату, но руки до неё так и не дошли. Это позволило сформировать для себя какую то необходимую картину того, как функционирует CPU, как происходит проектирование микроконтроллеров. 

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

Долго пытался сформулировать, почему мне нравится кругозор Claude и Gemini и умение рассуждать ChatGPT.

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

Интуиция не врёт.
(Юдковский перевернулся в гробу)

Последние пару-тройку лет на конференциях все чаще я слышу жалобы знакомых в игрострое о том, что текущий вектор развития "современного C++" не соответствует потребностям игровой разработки. Реальные полезные нововведения фактически закончились с выходом C++17, а попытки внедрить C++20 часто заканчиваются обнаружением множества "гейзенбагов" и существенным снижением производительности - критичные для нас на 10-15% от сборки к сборке. Пошатавшись по разным игровым студиям, блин, скоро будет 15 лет как я тут, у меня таки немножечко есть, что вам рассказать.

Все современные студии, что крупнее двух с половиной землекопов, пишущие игры на плюсах, шарпе или чем-то близком - используют Visual Studio или переходят со своих поделок на Unreal/Unity, который так-то тоже плюсы, хоть и со странностями. Так исторически сложилось, что винда и майки были, есть и в ближайшем будущем горизонта лет десяти останутся самым крупным рынком ПК-консольных игр, а сами консоли давно стали "ну совсем ПК", но чтобы не терять эксклюзивы (и шекели) вендоры в этом не признаются никогда.

Мобилки, как-бы отдельно, и там свои свои покемоны Mac с Android, но в Visual Studio в том или ином виде создаются, дебажатся и оптимайзятся 95% игр, остальное - погрешность. С момента начала золотой эры игростроя (где-то в конце 90-х), большинство игр писались с учетом того, что они будут выпущены на ПК, под ПК понимается - под винду. И наследие многих A+-студий так или иначе связано с Microsoft, даже для не-Microsoft консолей и мобилок.

Первая часть: Ethernet, ARP, IPv4 и ICMPv4

Вторая часть: основы TCP и Handshake

В прошлом посте мы узнали о заголовках TCP и о том, как устанавливается соединение между двумя сторонами.

В этом посте мы изучим передачу данных по TCP и способ управления ею.

Также мы создадим интерфейс сетевого стека, который приложения смогут использовать для передачи данных по сети. Потом этот Socket API мы применим, чтобы наш пример приложения смог отправить простой HTTP-запрос веб-сайту.