Dear Habr, I am writing to share my experience... ой, кажется, я переобучилась на вариантах части Writing. В общем, я пишу эту небольшую статью, чтобы поделиться личным способом сдачи международного экзамена по английскому языку, рассказать о подготовке, мотивации и издержках.

Мое наблюдение состоит в том, что мы — разработчики и продукты, сильно переусложняем, осознанно или нет, но всякие «„Архитектурные комитеты“, „Планирования“, „Апрувы у 50 отделов“ и деплои в 2-часовые окна, простыни текста сопровождающие простейшие фичи — это просто какой‑то бич современной разработки. Умные дяди с 20 летним опытом за плечами, с невозмутимыми лицами сутки напролет на созвонах обсасывают простейшие вещи вроде замены кнопки. Что это? Следствие усложнения программного обеспечения или засилие не тех людей не на тех местах? Или следствие входа в индустрию новичков, стремящихся простое сделать сложным?

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

Хотел написать продолжение к статье Что почитать игровому программисту? про использование С++ в игровых движках, но размышления свернули куда-то не туда.

Завороженно смотрю как и какими темпами идет развитие языка в последние годы, и понимаю, что получить и особенно применить возможности С++20/3 в разработке игр и движков получится хорошо, если с опозданием лет эдак в пять, как раз на следующее поколение консолей, если вообще получится. Сейчас плюсы в игрострое зависли где-то между 14 и 17 стандартом, Сони только-только выкатила свою версию компилятора с полной поддержкой 17 стандарта, а учитывая реактивность игровых студий в изменении кор пайплайнов, что-то новое начнут только в новых проектах. Менять коня, т.е. компилятор посреди разработки игры равносильно стрельбе не только по ногам себе, но и соседям программистам: работает - не чини.

Если смена компилятора и стандарта не даст гарантированного прироста скорости работы больше 5%, то бюджет и людей я не одобрю. (с)

Знакомство с кодовой базой больших движков дает понимание уровня и объёмов кода в продакшене и в тулзах, и ситуация вырисовывается такая, что эти объемы стали в индустрии, что называется "too big to fall", т.е. написать что-то новое, уровня движков вроде Unity/Unreal/Dagor на другом языке, будь он хоть в тысячу раз безопаснее и в десять раз быстрее не получится, но попытки конечно делаются. И чем дальше продолжается поддержка существующих проектов на плюсах, тем меньше возможности выбора остается.

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

Небольшое введение в технологии MPC и мультиподписей.

Краткое описание набора протоколов и используемой реализации мультиподписи.

Прочитал её давно, и могу с уверенностью сказать, что эта книга, которая, точно себя многократно окупила. Недавно перечитал и актуализировал для себя 5 самых ценных, с моей точки зрения, советов:

1) Не стесняться предлагать свои условия. Твердо установленных цен не существует, всегда есть пространство для переговоров.

2) Менять не цену, а пакетное предложение. Например, если тебя просят снизить цену, то сделать это можно, но только вместе с изменением других условий (состава работ, сроков выполнения, сроков платежей и др.). Слово “ЕСЛИ” в переговорах намного более полезно, чем слово “НЕТ”. Можно идти на уступки, но никогда нельзя это делать в одностороннем (тем более превентивном) порядке. 

3) Стараться не выставлять себя финальным ЛПР, а иметь за спиной, пусть даже придуманного, но “принципала”, на которого можно сослаться для изменения условий

4) С другой стороны —  всегда стараться самому вести переговоры именно с тем, кто фактически принимает решения.

5) Выявлять и учитывать позиции и интересы другой стороны (позиция —  то, что мы хотим, интересы —  почему именно). Помнить и ориентироваться на свои интересы. 

6) При любом соглашении заранее продумывать возможные “что мы будем делать, если …”

7) Фокусировать переговоры на возможных (и выгодных для каждой из сторон) решениях, а не обсуждении прошлого, в том числе заботиться, в первую очередь, об “ошибках других”, а о средствах их исправления с учетом ваших интересов.

Другие книги в тему: Фишер. Переговоры без поражений; Кемп. Сначала скажи “Нет”, Ури. Договорись с собой и другими достойными оппонентами; Паттерсон. Трудные диалоги (конспект по ссылке) и Розенберг. Язык жизни. Ненасильственное общение (конспект по ссылке)

Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Это шестая статья из серии, список предыдущих статей приведен в конце в разделе 7. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Данная статья посвящена объявлению и инициализации переменных.

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

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

Автор статьи Жерар Галлан известен как автор книги “WebAssembly in Action”, выпущенной Manning в 2018 году. Существует перевод его книги на русский “WebAssembly в действии” (Питер, 2022). Предыдущий обзор Состояние WebAssembly в 2022-23 годах опубликован автором в январе 2023 года. — Прим. переводчика.

Добро пожаловать в 2024 год и в нашу статью о текущем состоянии WebAssembly (Wasm)! В этой статье я займусь тем, что посмотрю, что произошло в 2023 году. Затем я выскажу свои мысли о том, что может произойти в текущем году.

Если вы не провели последние два года на ферме в Сибири, вы, вероятно, слышали о Stable Diffusion или пробовали генерировать изображения с помощью моделей, вроде Dall-e или Midjourney. Они становятся все лучше каждый день, и по качеству уже сравнимы с людьми, а во многих аспектах даже лучше (например, им не нужно платить).

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

Открываю с утра новости, а там – ни разу не было и вот опять:

Нехватку (высококвалифицированных низкооплачиваемых) специалистов выявили благодаря опросу Института экономической политики им. Гайдара (ИЭП), с результатами исследования ознакомился РБК.

Население при этом: ну да ну да.

Весной 2023 года только 2% сообщили, что в связи с СВО у них выросла зарплата, за последний год материальное положение в той или иной степени улучшилось у 15%, тогда как ухудшилось у 33%, поскольку увеличились текущие расходы (39%), а некоторые (7%) потеряли часть сбережений и/или доходов. Савин, Институт социологии РАН. «Вестник РУДН. Серия: Социология», №4, 2023

Эта статья посвящена уязвимости, которую мне удалось обнаружить в браузере Google Chrome в конце прошлого года, а также рассказывает об истории её возникновения. Уязвимость существовала в течение продолжительного периода и была устранена 31 октября 2023 года. Компания Google оценила её в 16000$

Должен признаться: на протяжении очень долгого времени я испытывал страх перед Unicode. Когда была необходимость в работе с Unicode, я предпочитал искать альтернативные пути решения, поскольку не совсем понимал, что делаю.

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

Приложив определенные усилия, прочитав кучу статей — я постепенно начал понимать что к чему, и это оказалось не так уж трудно. Хотя, некоторые статьи приходилось перечитывать раза по 3.

Как оказалось, Unicode — это универсальный и удобный стандарт, но работать с ним может быть непросто из-за множества абстрактных терминов.

Если у вас есть пробелы в понимании Unicode, то сейчас самое подходящее время их заполнить! Заварите себе вкусный чай или кофе ☕. И давайте погрузимся в удивительный мир абстракций, символов, астралов (astrals) и суррогатов (surrogates).

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

Вы также узнаете, как JavaScript взаимодействует с Unicode и какие трудности могут возникнуть на этом пути.

А также, каким образом новые функции из ECMAScript 2015 могут помочь в решении этих проблем.

Готовы? Давайте начнем!

Многие из вас, я уверен, слышали о теории игр в какой-то момент своей жизни. Если вы хотите выглядеть умным и произвести впечатление на свою девушку — просто упомяните «игру с нулевой суммой» или «эволюционную стратегию», и ваши шансы отвести её домой сегодня вечером только что подскочили на 50%. Или вы можете использовать теорию игр, чтобы принимать решения в инвестировании своих денег (чтобы их полностью потерять и разориться) или, например решая, на какой девушке жениться (что также очень вероятно вас разорит). Как видите, это очень полезная теория.

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

С++ видится мне огромным франкенштейном: очень уж много разнообразных способов описать свои намерения. В добавок к этому язык пропагандирует политику zero-cost abstractions, из которой следует (помимо прочего), что программист в ответе за все свои действия. Однако, работая с большими кодовыми базами, становится крайне тяжело держать в уме различные тонкости языка, которые держать в уме нужно — иначе Undefined Behavior.

В данной статье хочу рассказать о трех интересных случаях UB, с которыми столкнулся при разработке на С++. Не думаю, что опытным разработчикам примеры из статьи будут полезны, но, полагаю, что начинающим разработчикам смогу показать на своем примере, как не стоит писать код на C++.

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

В C и C++ есть особенности, о которых вас вряд ли спросят на собеседовании (вернее, не спросили бы до этого момента). Почему не спросят? Потому что такие аспекты имеют мало практического значения в повседневной работе или попросту малоизвестны.

Целью статьи является не освещение какой-то конкретной особенности языка или подготовка к собеседованиям, и уж тем более нет цели рассказать все потайные смыслы языка, т. к. для этого не хватит одной статьи и даже книги. Напротив, статья нужна для того, чтобы показать малоизвестные и странные решения, принятые в языках C и C++. Своего рода солянка из фактов. Вопрос “что делать с этими знаниями?” я оставляю читателю.

Если вы, как и я, любите и интересуетесь C/C++, и эти языки являются неотъемлемой частью вашей жизни, в том числе и его углубленного изучения, то эта статья для вас. По большей части я надеюсь, что эта статья сможет развлечь и заставить поработать головой. И если получится, рассказать что-то, чего вы, возможно, еще не знали.

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

Делюсь своими лайфхаками, наработанными 10 годами опыта.

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

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

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

Поэтому я решил изучить эту идею проверки чётности числа при помощи одних сравнений, чтобы понять, насколько хорошо она работает в реальных ситуациях. Я сторонник высокопроизводительного кода, поэтому решил реализовать это на языке программирования C, потому что он и сегодня остаётся самым быстрым языком в мире с большим отрывом от других (благодаря гению Денниса Ричи).