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

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

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

В первых трёх частях мы с вами рассматривали, что именно провоцирует переработки и прочую корпоративную шизу. 

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

Вы представляете себе, насколько разрушительны для общества современные медиа и СМИ?

Знаете ли вы, что консультанты настолько любят переработки, что буквально не приносят никакой долгосрочной пользы для бизнеса?

Что инфоцыгане провоцируют иррациональную веру в простые, быстрые и работающие техники?

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

Лонгрид, как обычно, на основе исследований и демонстрирующих логику историях.

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

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

В конце статьи бонус: подборка бесплатных онлайн-ресурсов, где можно найти ещё больше книг, журналов и комиксов для любого уровня.

В этой статье мы углубимся в реализацию шифрования (end-to-end) сообщений на стороне клиента с использованием JavaScript и Web Crypto API, разобрав практический пример, который будет в самом конце статьи.

Начнём с того, что если вы полный ноль в криптографии, то понять написанное здесь может быть непросто. Мне самому, несмотря на 10 лет опыта в разработке, пришлось поломать голову — всё, что здесь происходит, это чистая математика, о которой мы в этой статье говорить не будем :) Особо впечатлительные могут подумать, что это магия :)

Если вкратце, без сложных слов и терминов, попробую объяснить суть сквозного (end-to-end) шифрования

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

В этой статье рассмотрим, почему безобидная строчка await fetch() неожиданно превращается в тормоз, где именно она зарывает драгоценные миллисекунды — и что можно сделать с этим.

В программирование меня изначально привело желание делать игры, но как-то так получилось, что за 16 лет карьеры я успел позанимался чем угодно, но не ими. Десктоп, фуллстек-разработка, бэкенд, мобильные приложения, в создания которых я влюбился с головой… Но желание делать игры не пропадало, а просто ждало где-то в сторонке — и спустя столько лет таки дождалось своего часа! Демоверсия уже загружена в Steam, и меня прямо таки распирает от желания рассказать… нет, не о самой игре, а о набитых шишках и о том, как меняется игровой процесс после столкновения с первыми плейтестами.

На дворе 2025 год, а я всё ещё продолжаю делать видеоигры. Если верить archive.org, я начал заниматься этим двадцать лет назад! Достаточно долгий срок для одного увлечения...

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

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

Тут можно задаться вопросом, а зачем вообще использовать движок? Что он даёт? Зачем я позволяю инструменту потенциально препятствовать моей работе, когда его владельцы внезапно принимают неэтичные и ужасные бизнес-решения? Или выпускают обновление, которое требуется для запуска моей игры на консолях, но ломает всю систему в игре, заставляя переписывать её? Зачем я ежедневно борюсь с этим для работы с движком, пока я постепенно заменяю все его стандартные системы и он постепенно становится только загрузчиком ресурсов и фреймворком UI редактора?

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

Найденные варианты я собрал в табличку, актуальную на май 2025. ChatGPT o3 наврал в ответах, поэтому пришлось добавлять, фильтровать и перепроверять данные вручную. К сожалению, приходится сравнивать «яблоки с попугаями», потому что каждый Cloud провайдер рассчитывает стоимость хостинга немного «по‑своему» и включает в бесплатный тариф только часть функциональности.

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

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

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

Поскольку прошлая статья про «особенную» Java вызвала интерес, мы решили продолжить праздник. Настало время познакомить разработчиков С# с темной стороной любимой технологии — сегодня шатаем .NET!

Привет Хабр ! Это моя первая статья на тему процедурной генерации. Здесь я рассмотрю конкретную задачу по генерации, её решение и опишу ключевые использованные принципы. Пишу эту статью для того, чтобы поделиться идеями и опытом, которых мне не хватало, когда я взялся за дело две недели назад. Я не буду делать полный разбор проекта, а лишь опишу и визуализирую принцип.

Привет, Хабр! Меня зовут Данила Федюкин и я тимлид в X5 Digital. Руковожу командой, которая занимается рекомендациями и метчингом.

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

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

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

Привет, Хабр! Меня зовут Артём, и я 3D-моделлер, который много лет работает в 3ds Max. Недавно я решил освоить Unreal Engine через создание пет-проектов, и результатом стала игра Run Eternal Depths — roguelike с процедурной генерацией подземелий, которая уже доступна для добавления в вишлист в Steam. Релиз запланирован на 21 марта, и в этой статье я расскажу о технических аспектах разработки, включая мою реализацию генерации подземелий.

1. Идея и начало разработки

Изначально Run Eternal Depths задумывалась как тестовый проект для экспериментов с процедурной генерацией подземелий. Мне нужно было реализовать эту механику для другого проекта, но я решил сделать это в чистом проекте, чтобы не рисковать основным. Со временем идея переросла в полноценный roguelike с упором на исследование подземелий.

2. Технические аспекты разработки

Движок и инструменты