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

С появлением ИИ у бизнеса появилась возможность собирать MVP, фичи и рефакторинги за недели, а не за кварталы. И оказалось, что подавляющая часть этих MVP - никому не нужна. И это вызвало вопрос: "А действительно ли бутылочное горлышко было в разработке?". Ведь очевидно, если мы генерим MVP достаточно быстро, но эти MVP не находят востребованность, то проблема в нем, а не скорости разработки.

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

Если запустить множество таких случайных систем и позволить им мутировать и взаимодействовать друг с другом, возникнут ли в итоге “жизнеподобные”, самовоспроизводящиеся программы? Новая статья Блеза Агуэра-и-Аркаса и его соавторов показывает, что ответ, по-видимому, положительный. Это поднимает интересный вопрос: не является ли вычисление аттрактором в пространстве соответствующих динамических процессов? Если это так, последствия могут быть весьма существенными для нашего понимания происхождения жизни и того, насколько широко она распространена во Вселенной.

Блез Агуэра-и-Аркас получил степень бакалавра физики в Принстонском университете. В настоящее время он занимает должность вице-президента по инженерным разработкам в Google, руководит командой Cerebra и входит в команду Paradigms of Intelligence. Он автор книг Ubi Sunt и Who Are We Now?, а также готовящейся к выходу книги What Is Intelligence?

Вступление

ведущий (Шон Кэрролл): Всем привет и добро пожаловать в подкаст Mindscape. Сегодня у нас ситуация из разряда “есть хорошая новость и плохая”. Плохая новость в том, что в этом выпуске будет нецензурная лексика. Не потому, что мы вдруг решили особенно грубо выражаться или ругаться, а потому, что будем обсуждать компьютерные симуляции, написанные и запущенные на языке под названием Brainfuck. Прошу прощения у тех, кого может задеть такое название, но это вполне реальный язык программирования, и он действительно называется Brainfuck. Поэтому слово Brainfuck нам сегодня придется повторять снова и снова. Собственно, поэтому я произношу его уже сейчас - чтобы вы успели привыкнуть и знали, чего ожидать.

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

Часто задаюсь таким вопросами:

• что будет с моими активами через 5 лет, если взять квартиру в ипотеку?

• стану ли я богаче или же беднее от этого?

• смогу ли я выплатить вообще с текущими доходами и расходами всю ипотеку?

• а если не смогу, в какой момент получу кассовый разрыв?

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

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

• снимать квартиру и параллельно гасить ипотеку

• или взять жильё на миллион дороже, сразу заехать и отправлять сэкономленную аренду в досрочное погашение.

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

Считать стоимость использования DeepSeek становится всё менее просто. Токены DeepSeek не одинаково полезны стоят сильно по-разному. В пиковые часы цена в два раза дороже.

Сначала пиковые часы были каждый день с 01:00 до 04:00 и с 06:00 до 10:00 UTC. Желающие экономить научились переводить UTC в MSK. Позже выходные дни стали непиковыми целиком. “Экономисты” выучили, когда начинается суббота по UTC. И когда заканчивается воскресенье.

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

Мне давно было любопытно разобраться, как в RTB (Real Time Bidding — аукционная закупка рекламы в реальном времени) устроена хайлоад часть. Задача выглядит сложной: от площадок идет поток запросов на покупку рекламы (бид-реквестов), на стороне рекламного движка есть каталог рекламных объектов (кампаний и баннеров в них) со своими таргетингами, и на каждый входящий запрос надо успеть найти подходящие объекты, посчитать ставку и ответить. На весь обмен с биржей дается порядка ста миллисекунд, и в них должно поместиться все сразу — сеть в обе стороны, разбор запроса, подбор объекта, расчет ставки, сборка ответа. То есть на сам подбор остается еще меньше времени.

А еще такая система должна быть подвижной в обе стороны по нагрузке. Трафик у поставщиков не постоянен, он гуляет и в течение суток, и от поставщика к поставщику, так что держать максимальный конфиг под пиковую нагрузку круглосуточно нет смысла. Значит нужна возможность добавлять и убирать мощности, понимая при этом, сколько пропускной способности дает каждая добавленная единица. Спроектировать такое — интересная инженерная работа. Ну это я, как продакт работающий в этой сфере, так считаю :-)

В каждой компании где я работал с рекламными движками (DSP – Demand Side Platform) были свои кастомные решения, свое легаси – не везде можно найти обоснование каждому решению, поэтому мне всегда было интересно, как это устроено у других. Так что я решил разобраться, какие вообще бывают решения — чтобы лучше понимать возможности и ограничения, с которыми имеют дело мои разработчики. Это важно, потому что от выбора хранилища напрямую зависит сколько трафика мы физически способны обработать не отъехав, и что случится (а точнее что мы можем быстро сделать), если завтра нужно будет попросить у поставщика (в рекламе он называется SSP - Supply Side Platform) вдвое больше.

В предыдущей статье я писал про [5 вещей, которые не следует делать в LibGDX].

Поэтому логично продолжить тему и поговорить о вещах, которые, наоборот, стоит использовать при разработке 2D-игры на LibGDX.

Сразу оговорюсь: это не статья про архитектуру, паттерны проектирования, ECS, оптимизацию кода или правильную организацию проекта.

Здесь всё гораздо проще.

Я хочу поговорить о нескольких технических инструментах, которые способны относительно небольшими усилиями заметно улучшить визуальное восприятие игры:

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

В статье разберём типовую архитектуру современного AI PoC на примере моего пет-проекта и ответим на вопрос: если AI умеет писать код, зачем все еще нужен инженер?

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

Вот на тему стыка человек — ии я хотел бы и подумать.

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

Почему одинаковые данные могут давать разные p-value? На простом примере с монетой разбираю, как правило остановки меняет частотный вывод, а затем связываю это с подглядыванием в A/B-тесты и повторными проверками значимости. Заодно становится понятнее, что именно ломается при peeking и почему проблема не в самом просмотре данных, а в том, как промежуточные результаты влияют на решение остановить эксперимент.

Всем привет! Этой весной я искал работу, и в какой-то момент пришел к тому, что на сами отклики у меня уходит минут тридцать, а весь остальной вечер я трачу на то, чтобы просто обойти площадки и посмотреть, не появилось ли чего нового. То есть я не работу искал, я вкладки открывал.

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

Надоело, и в июне я написал себе скрипт. В июле из него вырос сервис, который с тех пор работает каждый день. Сейчас в базе больше 16 000 активных вакансий, и последние месяцы я смотрю на рынок не по ощущениям, а по своим же данным. Ощущения, между тем, мне врали.

Далее две части. Сначала про рынок и про то, что видно из базы, когда вакансии можно посчитать. Потом техническая кухня: что ломалось, что я чинил и какие места, по-моему, полезно знать заранее. Я разработчик, но парсинг, нормализация данных, Postgres, эмбеддинги и инфраструктура были для меня новыми, так что граблей набралось прилично.

И сразу заранее: все цифры ниже про мою базу, а не про рынок целиком. Спорить с ними можно и даже нужно :-)

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

Знать принцип 80/20 в такой ситуации недостаточно. Сложность начинается в тот момент, когда нужно применить его к реальной бизнес-задаче: определить, какие действия действительно сильнее других влияют на результат, сформулировать их конкретно и договориться, на чём стоит сосредоточиться.

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

В России 2026 года нейросетями пользуется каждый четвёртый житель — это примерно 35 миллионов человек, что выше среднемирового показателя. При этом 58% активных пользователей обращаются к ИИ минимум раз в неделю. Но вот парадокс: чем больше моделей появляется, тем сложнее выбрать «ту самую».

В 2026 появилось множество новых нейросетей и ИИ-моделей: GPT-5, Claude Fable, DeepSeek, GLM, Qwen, и интернет уже не ограничен исключительно ChatGPT от OpenAI. Некоторые из них уже создали фурор своими способностями и мощностью интеллекта, некоторые стали популярными за счёт интегрированности и доступности, третьи — за счёт бесплатности и безлимитного общения. Мы поговорим и о глобальных флагманах, и о менее известных нейросетях, и о российских нейросетях.

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

На разработку ушло 16 выходных дней и примерно 250$

Решил я значит разработать свое приложение, начитавшись материалов про ИИ и вайбкодинг, захотелось попробовать самому. Так как я являюсь UX/UI дизайнером, который занимается разработкой дизайна для приложений, я поставил себе несколько целей, которые должны были закрыться в процессе разработки аппы...

Однажды заказчик, которому я разворачивал офисную телефонию спросил меня: "А можно нашим сотрудникам поставить на телефоны SIP клиенты, чтобы их разговоры с клиентами проходили через офис, попадали в CRM и записывались?"

Мысль заказчика понятна: Почему бы просто не поставить софтфон на мобильник и не настроить его на свой сервер?

Но есть несколько причин, почему это работает откровенно плохо.

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

Иногда мне нужно быстро проверить свой VPS: посмотреть нагрузку, глянуть логи или перезапустить сервис. Каждый раз открывать ноутбук и подключаться по SSH ради пары команд было неудобно, поэтому я решил сделать Telegram‑бота. Сначала думал, что всё будет довольно просто: Telegram → SSH → сервер. Но по ходу разработки выяснилось, что само SSH‑подключение — как раз самая простая часть. В статье расскажу, с какими проблемами я столкнулся и как в итоге их решил.

Возвращаюсь со своим еженедельным дайджестом для мобильных разработчиков. В этом выпуске адаптация приложений под iPhone Duo и Shared Transition как требования дизайнеров, прозрачный Яндекс.Навигатор и нативная разработка в Shopify, фронтенд без готового бэкенда, путь к Chaos As A Service, ошибка после оформления подписки, которая приводит к оттоку и многое другое. Заходите!

По всей территории Аппалачей и «Ржавого пояса» в США, в том числе в Питтсбурге, бывшие промышленные площадки превращаются в новые жилые районы, исследовательские центры и технологические кластеры. Однако на протяжении десятилетий в этих местах происходили и другие процессы преобразования.

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

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

Я микробиолог, и этой темой я заинтересовался благодаря браунфилду, который находится практически у меня на заднем дворе. Моя лаборатория в Университете Карнеги — Меллона расположена всего в 3 километрах от Hazelwood Green, бывшей промышленной территории площадью 72 гектара на берегу реки Мононгахила в Питтсбурге.

Более ста лет здесь находились сталелитейные предприятия, в том числе Jones & Laughlin Steel Co. На пике производства на этой площадке работали тысячи человек, и она внесла свой вклад в репутацию Питтсбурга как Стального города.

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

В прошлой статье я представил свою библиотеку для парсинга JSON. Краткое содержание - мы используем новые инструменты стандарта С++26 (в основном, рефлексию) для автоматической генерации оптимизированных парсеров для конкретных JSON, что позволило нам обогнать simdjson в несколько раз.

Здесь мы рассмотрим, как можно генерировать целевые структуры для объектов JSON напрямую из JSON схем при помощи других трюков из стандарта 26.

Это эссе я задумал сразу после выхода книги Элиезера Юдковского и Нейта Соареса «If Anyone Builds It, Everyone Dies». Потом книгу неожиданно перевели, и мне казалось, что пост уже потерял изрядную долю актуальности для русскоязычной аудитории.

За то время как переводили книгу LLM начали решать задачи Эрдёша. Затем вышла Mythos 5, из-за которой даже разразился политический скандал, но я всё равно считал, что пока мы находимся в состоянии, когда размышления о скором конце света представляют собой скорее развлечение, сродни чтению художественного романа. Потом наступило лето.

В июле рой агентов сам спланировал и провёл атаку на сервера Hugging Face, а вскоре начали появляться расследования о других диких сообществах LLM-агентов. Не успели толком разобраться, что именно произошло, как OpenAI заявила, что её агенты решили одну из задач тысячелетия, связанную с уравнениями Навье - Стокса. Я понял, что уже мне самому нужен этот текст - хотя бы как имитация разумной деятельности в тот момент, когда мир вот-вот опрокинется в бездну (или вершину) сингулярности.

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

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

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

В феврале этого года проект с красивым именем Polaris незаметно стал полноценным проектом фонда Apache. Новость прошла как-то мимо, ну стал и стал, мало ли. Между тем это одна из тех новостей, которые лет через пять, возможно, будут называть поворотной точкой. Потому что Polaris — это каталог. А каталог в мире Iceberg — то самое место, где на самом деле лежит власть над вашими данными.

Звучит громко, понимаю. Поясню, откуда такая уверенность.

Последние несколько лет хранилища данных строят по новой схеме: файлы лежат в объектном хранилище, поверх них открытый формат в виде метаданных, движки обработки живут отдельно в виде федеративного обработчика и ходят за данными. Схему назвали лейкхаусом (Data LakeHouse), а формат в ней почти везде один и тот же — Apache Iceberg. Вендоры за него отвоевались, открыли и согласовали, и все выдохнули. Данные наконец-то ничьи (формат parquet): лежат у вас, читаются чем угодно, никакой платформы-хозяина.

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

Начнём даже не с каталогов, а на шаг раньше — с того, что такое вообще Iceberg, вокруг которого последний год прыгают все вендоры.

В прошлый раз мы отследили путь возникновения схемы, которая легла в основу работы «номерных радиостанций». Мощные коротковолновые станции позволили передавать радиосигнал через океаны и континенты, а шифры Вернама обеспечили при строгом соблюдении процедуры принципиальную недешифруемость сообщений. Соответственно, «центр» или работавшие при посольствах сотрудники спецслужб теперь могли передавать даже сверхсекретные сведения и указания в открытый эфир — и быть почти на 100% уверенными, что расшифровать послания никто не сможет даже при очень большом желании. До ума эта система была доведена к началу Второй мировой войны — и одним из пионеров в её применении стала советская стратегическая разведка. Ещё до разгрома стран Оси на территории США и Британии развернулось незримое для непосвящённых, но масштабное сражение советских и западных спецслужб. Разведчики СССР и их агенты, в том числе высокопоставленные, собирали всю возможную информацию о ядерных разработках Манхэттенского проекта и пересылали её в Москву в основном посредством шифров Вернама. Американские контрразведчики и криптографы, в свою очередь, пытались расшифровать их сообщения, несмотря на применение системы абсолютной криптоаналитической устойчивости, — и «вскрыть» советскую разведывательную сеть, о реальных масштабах которой они поначалу даже не подозревали.

Систематизация и автоматизация дисциплинарного учета в организации путем доработки ЗУП 3.1 "Базовая". Описание архитектуры и функционала разработанного решения.

«Мгновенно» — слово сильное, я к нему ещё вернусь и отниму примерно всё. Но начну с факта, который в этой истории главный.

В 1956 году в NASA делали пилотажный тренажёр для X-15 — того самого ракетоплана, который летал на семи махах и забирался на 100 километров. Тренажёр должен был считать динамику полёта в реальном времени, потому что за креслом сидел живой пилот. Ни один цифровой компьютер тогда этого не умел. Взяли три аналоговые машины EAI PACE 231R: 380 операционных усилителей, 101 функциональный генератор, 32 сервоусилителя, 5 множительных устройств. Диапазон модели — от 0,2 до 7 махов и от уровня моря до 1 056 000 футов, это примерно 322 км.

То есть человека готовили к полёту на край атмосферы на машине, в которой не было ни одной нулевой или единичной цифры.

Дальше обычно идёт текст про то, что аналоговые машины были в тысячи раз быстрее, что их зря похоронили, и что вот сейчас они возвращаются в виде чипов для нейросетей. Я такой текст читала много раз, и каждый раз спотыкалась в одном и том же месте: рядом со словами «в тысячи раз быстрее» всегда стоит строчка «точность порядка 0,1%», и никто никогда не показывает, что эти две цифры означают вместе.

Ну я и полезла считать.

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

Когда-то Haier Group был небольшим заводом, который производил дешевые холодильники. Теперь это крупная китайская корпорация, чьи акции торгуются сразу на нескольких биржах (кстати, бумаги фирмы доступны в том числе российскому инвестору). Компания производит бытовую технику (холодильники, стиральные машины и т. п.), а также потребительскую электронику. Об истории становления корпорации и ее интеллектуальной собственности рассказываем в нашем материале. 

.

Обе мои предыдущие статьи про этот сайт с кейсами CS2 заканчивались списком того, чего в нём нет: платежей, депозита предметов, кейс-баттлов, рефералки, KYC. Список закрыт — и почти всё сложное в нём свелось к одному вопросу: что происходит, когда несколько человек одновременно двигают одни и те же деньги. Батл на четверых в одной транзакции, порядок блокировок, из-за которого не случается дедлок, PgBouncer под Prisma и правило чтения с реплики, которое нельзя выразить типом.

У меня был доступ к последним Qwen, GLM и Sol. Рядом лежали аккаунты ко всяким Claude c Astra. Не то, чтобы все это реально требовалось для разработки эмулятора ZX-Spectrum, но остановиться было тяжело. В итоге эмулятор получился просто на загляденье и вы можете прочитать про боли и решения в реальном проекте.

TL;DR: Да, за год БЯМки сильно подросли в своих умениях. Сегодня я смело могу утверждать, что по своему уровню они достигли джунов. Если убрать скорость и стоимость за скобки, то это почти настоящие кожанные мешки. Почему почти? Настоящий кожанный мешок не обладает такой широтой знаний. Но зато умеет творить. Про пруфы читать ниже (смаил).

Практически год назад я написал статью (https://habr.com/ru/articles/956344/), как я писал эмулятор ZX Spectrum на go. Потом полгода назад (https://habr.com/ru/articles/962612/) жаловался, что golang уж очень неподходящий язык для эмуляторов. И вот теперь я опровергаю сам себя…

Сценарий: полная компрометация записи персональных данных. У атакующего - файл с растворёнными персональными данными: телефон, email, паспорт, адрес, ИНН, СНИЛС.

Чтобы упростить задачу атакующему, мы передаём почти всё: в сообщении 361 символ, 317 без пробелов, 45 слов. Мы даже передаём PIN и порядок слов.

Для миллионов геймеров Геральт из Ривии — это белые волосы, два меча и саундтрек CD Projekt RED. Игры и сериал сделали Сапковского массовым явлением. Но культовой фигурой среди читателей фэнтези он стал раньше, задолго до успеха адаптаций — благодаря тому, как методично разбирал жанр на части.

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

Дальше разберем все по порядку, слой за слоем.

Платформа Big Pineapple — на базе которой работают 1.1.1.1, Gateway DNS, DNS Firewall, AS112 и ряд других DNS-сервисов Cloudflare — в любой отдельный момент времени хранит 250 млрд. кэш-записей. При таких масштабах использование даже одного лишнего байта на запись стоит нашему парку машин более 250 ГБ памяти.

Озадачившись этой проблемой, мы последовательно внесли пять изменений в механизм сохранения кэш-записей, сократив объём памяти, необходимый для хранения одной такой записи, более чем вдвое. В общей сложности нам удалось освободить примерно 100 ТБ по всему парку, что равнозначно объёму RAM в 130 из наших серверов 13-го поколения. При этом также ускорилась работа кэша. Пропускная способность при вставке записей выросла на 43%, а задержка поиска упала на 19%. Причём за счёт сокращения числа аллокаций и повышения локальности данных жертвовать скоростью ради экономии памяти не пришлось.

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

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

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

Привет, Хабр! Несколько лет назад я уже рассказывал об анализе и восстановлении аккумуляторов для ноутбуков. Тогда я сподобился купить девайс под названием Professional Laptop Battery Analyzer NLBA1 (самое интересное — девайс румынский), который за прошедшие годы смог много чего восстановить. Какие-то АКБ удалось вернуть в строй, другие после проверки отправились на разборку без лишних сожалений. Так получилось, что на время я отложил прибор на полку, но на днях появился повод снова ввести его в строй.

Дело в том, что мне попался небольшой ASUS X200CA с типичной для «старичков» историей: пару лет пролежал без дела в разряженном состоянии. Я включил, все работает, но вот беда — девайс не заряжается. Покупать новую батарею для такой машины особого желания не было, поэтому я решил попробовать починить старую. Заодно появился хороший повод вернуться к теме NLBA1 и показать весь процесс на конкретном примере. Что ж, поехали!

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

Когда мы стали делать своего ИИ-помощника, который пишет/правит код и запускает его на сервере, поняли, что сборка должна быть быстрой. Очень быстрой.

В статье я расскажу, как нам удалось ускорить сборку Python до 20 раз.

Самая дорогая модель оказалась самой быстрой: 341 секунда против 395 у самой дешёвой, потому что ей нужно меньше ходов и вдвое меньше текста. Четыре задачи из пяти решили все, 32 прогона из 32. А на пятой младшая модель написала баг и отчиталась двумя галочками подряд, вторая из которых опровергает первую.

С этим утверждением всё в порядке. Оно верное. Я согласился и только потом сообразил, что мы обсуждали не то: вопрос был не «прочитают ли содержимое», а «что вообще узнает сторона, через которую всё это идёт».

Ответ на второй вопрос из первого не следует.