Все потоки

Рособрнадзор назвал предметы, которые школьники могут взять на единый госэкзамен 2026.

Допускаются в том числе:

• на биологии, химии, физике и географии — непрограммируемый калькулятор;

• линейка без справочной информации — на математике;

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

• на экзамены по всем предметам разрешается принести перекус, воду и лекарства;

• во время ЕГЭ на столе должны лежать чёрная гелевая или капиллярная ручка и паспорт.

Остальные личные вещи должны быть оставлены в специально отведённом месте до рамки металлоискателя.

Когда бизнес получил self-service BI и построил внутри него собственное хранилище данных

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

В ОТП Банке за год с момента запуска FineBI выросли до 1 000 пользователей и 660 отчётов при приросте 50 пользователей в месяц. Масштаб впечатляет, но вместе с ним пришло и теневое хранилище.

Пётр Гордиенко, руководитель команды BI в ОТП Банке, расскажет, как они к этому пришли, почему осознанно выбрали «больше свободы» на старте и какой план из трёх шагов готовят, чтобы вернуть контроль, не убив при этом скорость.

📅 22 апреля | 15:00 МСК | FineDay Online 2026

Бесплатно, онлайн, ~3 часа

→ Регистрация

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

Этот пет-проект Уолц создал с помощью Codex от OpenAI примерно за час, раздавая инструменту голосовые команды.

Система аналитики на сайте проекта собирает по открытым источникам информацию о меню компаний, а ИИ обрабатывает и ранжирует обеды.

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

Как разработчикам монетизировать свои игры в 2026?

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

Традиционный подход подразумевает, что разработчик заключает договор с площадкой (Steam, VK Play, Itch и т.д.). Игрок покупает игру, и деньги идут на счёт платформы. После этого в определенные даты происходит выплаты на счета разработчиков за вычетом комиссий. Где-то больше, где-то меньше, где-то по-другому. Но смысл тот же. Этот подход позволяет, во-первых, брать комиссии, во-вторых, легче работать с возвратами и в-третьих, быстрее распознавать отмывание денег и мошенничество.

Мы решили использовать схему маркетплейсов, где каждый разработчик приходит со своим статусом (ООО, ИП, смз). Но приходит он в первую очередь не к нам, а к платёжным агрегаторам типа Юкасса, Робокасса, любая …касса. Одним словом, подключает себе интернет-эквайринг, такое делает любой банк. Банк ему даёт API для подключения, ID магазина, ключи для проведения оплат и всё, действуй.

Где здесь мы? Мы предоставляем бесплатный хостинг для игр. Сама площадка + страница игры + страница разработчика. Всё тоже самое что у itch[.]io. Заодно есть консоль разработчика, в которую добавляется всё больше и больше возможностей. Соответственно, в этой консоли разработчик указывает тот самый идентификатор магазина, суперсекретный ключ и дальше надеется на магию.

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

Опережу (почти) все вопросы и сразу отвечу:

Q: На что вы будете существовать если у вас комиссии 0%?

A: При покупке игры рядом есть еще кнопочка “поддержать платформу”, надеемся, что это сработает

Q: Вы делаете очередного убийцу стима?

A: Нет

Q: Это точно не развод?

A: Точно нет, чесслово

На остальные вопросы обязательно ответим. Так как это не реклама, то прямо указывать название площадки не буду, но подскажу, что наш канал https://t.me/dustore_official

🧠 MemifyDB: прежде всего — видение (vision).

Прежде чем погружаться в код, нужно чётко ответить на вопрос: а что именно мы строим?
Этот пост — не про хардкорный кодинг, а про так называемое видение системы (system vision).
Мы разберём, какие вообще бывают in-memory базы данных, чем они отличаются и почему наш путь будет таким: key-value → документная БД.

Поехали!

📚 Типы in-memory баз данных

1. Key-Value хранилища

Самый простой и быстрый вид. Данные хранятся как пары «ключ — значение», где значение — обычно строка, число или бинарный объект.

• Примеры: Redis, Memcached, DragonflyDB.

• Сценарии: кэширование, сессии пользователей, счётчики, очереди задач.

• Плюсы: максимальная скорость, минимальный оверхед, простота масштабирования (шардирование по ключу).

• Минусы: ограниченная модель данных — нет сложных запросов, только операции по ключу.

2. Документо-ориентированные БД

Значение — структурированный документ (JSON, BSON, XML). Внутри документа можно индексировать поля и выполнять запросы по содержимому.

• Примеры: MongoDB (in-memory storage engine), Couchbase.

• Сценарии: хранение сложных объектов (профили, каталоги), где важна гибкость схемы.

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

• Минусы: чуть более высокий оверхед по сравнению с key-value (парсинг, индексация).

3. Колоночные (Columnar) in-memory БД

Данные хранятся не по строкам, а по колонкам. Это даёт огромное преимущество при аналитических запросах (суммы, средние, группировки).

• Примеры: SAP HANA, MemSQL (SingleStore) в колоночном режиме, Apache Arrow (формат, но не БД).

• Сценарии: аналитика реального времени, отчёты, BI.

• Плюсы: сверхбыстрая агрегация, высокая степень сжатия.

• Минусы: медленные точечные обновления (OLTP-нагрузка), сложность реализации.

4. Графовые БД

Хранят сущности (узлы) и связи между ними (рёбра). Оптимизированы для обходов графа.

• Примеры: RedisGraph (модуль Redis), Neo4j (с in-memory режимом).

• Сценарии: социальные сети, рекомендательные системы, сети связей.

• Плюсы: эффективные запросы связей, интуитивная модель для связанных данных.

• Минусы: узкая ниша, сложность шардирования.

5. Time-series БД

Специализированы для временных рядов — метрик, логов, событий. Оптимизированы для записи и запросов по временным интервалам.

• Примеры: InfluxDB, TimescaleDB (in-memory части).

• Сценарии: мониторинг, IoT, финансовые тикеры.

• Плюсы: высокая скорость записи, сжатие старых данных, встроенные функции по времени.

• Минусы: слабо подходят для произвольных данных.

…## 🧭 Наш курс: от Key-Value к документам

Для MemifyDB я выбрал путь, который кажется самым прагматичным:

1. Создаём ядро Key-Value
   Это фундамент. Мы реализуем:

   • потокобезопасное in-memory хранилище;

   • поддержку разных типов значений (строки, списки, хеши, числа);

   • механизмы TTL и эвикшена (LRU);

   • бинарный протокол, близкий к внутреннему представлению.

   Key-value движок даст нам максимальную скорость и стабильность, а также позволит отточить все низкоуровневые механизмы (аллокаторы, сериализацию, сетевое взаимодействие).

2. Надстраиваем документный слой
   Поверх key-value ядра мы добавляем возможность интерпретировать значение как JSON-подобный документ:

   • индексация по полям;

   • поддержка частичного обновления;

   • запросы с фильтрацией по содержимому.

При этом сами документы будут храниться в key-value хранилище как обычные значения, а индексы — как дополнительные структуры (хеш-таблицы, B-деревья) в памяти.

Такая двухслойная архитектура даёт:

• гибкость — можно работать и как с обычным кэшем, и как с документной БД;

• производительность — key-value ядро остаётся быстрым, а документные операции добавляются без потери эффективности;

• расширяемость — позже можно добавить другие модели (например, колоночные агрегаты) как отдельные слои.

Как в 2026 году строить надежную и безопасную ИТ⁠-⁠инфраструктуру?

Приглашаем на долгожданный марафон вебинаров от ISPsystem с самым полным разбором платформ для управления ИТ⁠-⁠инфраструктурой.

VMmanager, DCImanager и Clouden — три дня, три продукта, одна цель: сформировать стек оптимальных решений для вашего ИТ-ландшафта. Без воды, самые востребованные фичи и сценарии использования, свежие кейсы и наглядное демо продуктов.

5 причин посетить:

1️⃣ Тренды и актуальность. Узнаете о реальном развитии продуктов, новых фичах и сценариях использования. Поймёте, как платформы ISPsystem помогают эффективно управлять инфраструктурой в условиях динамично меняющегося рынка.

2️⃣ Общение с продуктовой командой. Спикеры — разработчики и владельцы продуктов. Это шанс узнать детали «изнутри» и повлиять на будущие обновления.

3️⃣ Реальные проекты. Мы покажем не «работу в идеальном мире» и «галочки» с «полочками», а настоящие кейсы внедрения и истории успеха.

4️⃣ Живой диалог (Q&A сессия). Вы сможете обсудить свои задачи с продуктовой командой здесь и сейчас, в режиме реального времени.

5️⃣ Бонусы для участников. Все участники получат закрытый доступ к записям вебинаров, презентациям спикеров и дополнительным полезным материалам, которые останутся у вас навсегда.

Вебинары пройдут 23, 28 апреля и 5 мая.

👉 Регистрация и подробная программа — тут.

Продолжаю делиться граблями, на которые я наступил в Claude Code. Как я ловил API Error: Stream idle timeout - partial response received

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

Проблема такая: оркестратор собирает SEO-статью на 8 000 слов, отдаёт редактору, пробует сохранить. Через 30 секунд тишины: API Error: Stream idle timeout — partial response received

Файл создан, но обрезан на месте, где стрим ушёл в idle.

❌ Первая очевидная неверная гипотеза: большой Write

Значит надо резать на чанки. Снизил лимит 15 000 → 8 000 → 6 000 → 5 000. Таймаут повторялся. Значит, дело не в размере записи.

✨ Настоящая причина: пересборка текста

Оркестратор не копировал готовый текст субагента. Он его пересобирал: переоформлял, перенумеровывал 28 сносок, «причёсывал» заголовки. Пока модель думала над форматированием, токены в стрим не эмитились. API считал соединение мёртвым и закрывал.

Решение РАЗ: passthrough + чанки ≤ 3 000

Вводим правило rules/common/safe-file-save.md:

➡️ Субагент возвращает строку оркестратору. Оркестратор копирует её в Write байт-в-байт — без «улучшений».

➡️ Разбиение планируется один раз до первого Write, потом проходится механически.

➡️ Лимит 3 000 символов на Write/Edit — потолок, при котором стрим не уходит в idle при честном passthrough.

➡️ Перед каждым Edit — сообщение 💾 Чанк K/M…. Иначе пользователь видит тишину и прерывает.

Если таймаут повторяется на 3 000 — спуск на 1 500. Если и там падает — это сеть, не контент.

И Recovery для обрезанных файлов

Повторный Write поверх частичного файла затирает уже сохранённое. Поэтому:

➡️ ls — проверить, что файл есть

➡️ Read — измерить длину

➡️ Edit (append) с точки обрыва, чанки по 3 000

Никогда не стартовать Write заново по тому же пути.

⭐️ Вторая волна: редактор

После фикса записи таймаут вернулся на возврате субагента-редактора. Вход 18 000 символов, выход 18 000 переписанного текста + отчёт «до/после» + метрики. Prefill и генерация занимают десятки секунд без эмита токенов. Retry не помогал: корень — объём выхода.

Решение ДВА: diff-mode

Вводим правило rules/common/editor-diff-mode.md. Редактор возвращает не переписанный текст, а список правок:

=== EDIT id=1 op=replace === FIND: Данное решение является инновационным продуктом REPLACE: VK Cloud управляет инфраструктурой — от ВМ до managed-БД REASON: редполитика + инфостиль === END EDIT ===

Лимиты: ≤ 60 правок, FIND ≤ 300, REPLACE ≤ 500, суммарный выход ≤ 8 000. Оркестратор парсит блоки и применяет через Edit.

Матрица по длине для глубокой редактуры:

➡️ ≤ 4 000 → классический

➡️ 4 000 – 20 000 → diff-mode

➡️ > 20 000 → секционный (одна H2 за вызов)

Пороги ниже именно для тяжёлых режимов — они удваивают выход за счёт отчёта «до/после».

Что в итоге то:

Два источника одной ошибки: оркестратор переформатирует перед Write, редактор генерирует слишком много на выход. Лечатся по отдельности: passthrough + чанки для записи, diff-mode для правок. Recovery закрывает остаточные случаи, когда таймаут всё-таки прилетел.

Я вроде не курю, но захотелось.

Как всегда ссылка на канал. Подписывайтесь

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

Естественным шагом для меня стало желание присоединиться к Программе поощрения авторов (ППА). По правилам Хабра, для этого нужно соответствовать ряду критериев, один из которых — наличие значка «Старожил» (выдается через 3 года после регистрации, а так же карма 50+).

И тут начался квест, который я пока не могу пройти.

Согласно моему профилю, я зарегистрирован 13 апреля 2023 года, а так же имею карму 81. Заветная дата наступила, три года прошли. Но значок в профиле так и не появился.

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

Пишу этот пост-обращение по двум причинам:

1. Привлечь внимание администрации Хабра. Ребята, если вы это читаете, посмотрите, пожалуйста, мой профиль. Возможно, мой тикет просто потерялся в горе других обращений.

2. Узнать у сообщества: сталкивался ли кто-то из авторов с подобной задержкой при получении ачивок? Выдаются ли они кроном раз в месяц, или сейчас всё работает в ручном режиме?

Буду рад любым советам и инсайдам.
Хабр

Всем чистого кода и быстрых ответов от саппорта!

Upd: Проблему решили!)

Мировой лидер по добыче алмазов АЛРОСА перевел DIrectum RX на СУБД Tantor Postgres, проект занял всего 5 месяцев. При этом бизнес-процессы работали в штатном режиме, сроки не сместились, бюджет не увеличился.

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

23 апреля в 11:00 мск на бесплатном вебинаре эксперты АЛРОСА, «Тантор Лабс», «СТАРКОВ Групп» и Directum поделятся подробностями кейса.

Для участия нужна только регистрация. Встретимся на вебинаре!

А где хранятся ваши файлы? Безопасно ли это и насколько удобно?

Многим знакома ситуация, когда файлы разбросаны по облачным хранилищам и рабочим столам сотрудников в десятках вариантах, а где находится тот самый «последний_итог_финал_точно_финал» файл?

🔑 Еще одна проблема – это отсутствие полного контроля над доступом к файлам. Неясно у кого может оказаться ссылка и кто может скачать и передать файл.

Что со всем этим делать? 23 апреля в 14:30 по Мск эксперты команды «Авандок» ГК «КОРУС Консалтинг» проводят вебинар «Корпоративный Диск: как навести порядок в документах и взять данные под контроль».

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

Также на вебинаре покажем, как можно организовать корпоративные базы знаний и использовать ИИ-помощника для ответов на вопросы пользователей.

Спикеры:
🎙Мария Токарева – Директор по развитию решений, ГК «Корус Конслатинг» «При создании и развитии продукта я делаю акцент на пользовательском опыте и безопасности, что сегодня особенно важно»
🎙Мария Лямина – Руководитель группы аналитики, ГК «Корус Конслатинг» «Стремлюсь к созданию решений, которые не только удовлетворяют потребности бизнеса, но и улучшают пользовательский опыт»

Присоединяйтесь, чтобы узнать больше об инструменте

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

С момента покупки нового мультиметра UNI-T UT61B+ я горю желанием поменять родные щупы. Несмотря на китайское происхождение, у них минимальное сопротивление, а замеры они делают достаточно точно и быстро. Единственный существенный минус - их наконечники очень короткие и толстые, что накладывает определенные ограничения на их использование и измерения. Во-первых, когда мы имеем дело с плотной SMD-пайкой в ограниченном пространстве, в том числе с многоножечными чипами, производить измерения не только невозможно, но и опасно, так как можно “закоротить” плату. Во-вторых, на щуп нельзя прикрепить “крокодила”, например, для подачи точечного питания или имитации джампера.

Можно сказать, что проблема “высосана из пальца” и все, что мне нужно сделать - это сходить в магазин и купить подходящие комплектующие. Сказано - сделано: купил, принес домой, хотел начать работу и … не тут-то было. При первичной проверке щупов оказалось, что измерения на них скачут. Вроде качественный компьютерно-бытовой магазин на 3 буквы, а продали ерунду.

Хорошо, идем в синий маркетплейс и выбираем щупы с 36 тысячами отзывов и средней оценкой 4.8 (ну столько-то не накрутят же, верно?). “Оказалось, что показалась”, и замеры как прыгали, так и прыгают. При попытке вернуть товар даже продавец отказался их забирать обратно и предложил их оставить себе с выплатой небольшой компенсации. Я пару раз отказывался, но в итоге просто “забил”: теперь они лежат мертвым грузом и я не представляю, что с ними делать. Если посмотреть отзывы, очень много людей говорят, что провода работают отлично. Мне вот интересно: это мне так повезло или это “нелицензионные” провода и юни-т не хочет с ними работать ;)

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

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

SK hynix начала массовое производство модулей памяти SOCAMM2 объёмом 192 Гбайт для Nvidia Vera Rubin

Компания SK Hynix объявила о старте серийного выпуска модулей памяти формата SOCAMM2 (Small Outline Compression Attached Memory Module 2) на базе чипов LPDDR5X с суммарной ёмкостью 192 Гбайт. Продукция предназначена для серверных платформ класса AI, включая архитектуру NVIDIA Vera Rubin, и ориентирована на рабочие нагрузки, связанные с обучением и инференсом больших языковых моделей.

Технические характеристики

Модули изготовлены по 10-нм технологическому процессу поколения 1c (шестая норма литографии), что обеспечивает высокую плотность размещения ячеек памяти. Каждый модуль поддерживает скорость передачи данных до 9600 МТ/с на контакт, а совокупная пропускная способность достигает 153,6 Гбайт/с — это в 2,6 раза выше, чем у стандартных серверных модулей DDR5 RDIMM.

Энергоэффективность улучшена на 70–75% относительно традиционных решений благодаря архитектуре LPDDR5X: пониженное напряжение питания (1,05 В против 1,1 В у DDR5), оптимизированные схемы ввода-вывода и улучшенные алгоритмы управления питанием. Это критически важно для дата-центров, где память может потреблять до 30% энергии стойки.

Архитектурные особенности и применение

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

В платформах на базе NVIDIA Vera Rubin CPU Vera поддерживает до 1,5 Тбайт адресного пространства LPDDR5X с совокупной пропускной способностью до 1,2 Тбайт/с

NVIDIA Rubin

Такая конфигурация позволяет эффективно распределять контекстные данные и KV-кэш моделей уровня Llama 3 70B между быстрой памятью HBM4 GPU Rubin и ёмкой системной памятью, сокращая задержки инференса и повышая пропускную способность при обработке длинных контекстов.

Экосистема и совместимость

Помимо SK Hynix, модули SOCAMM2 аналогичной ёмкости производят Micron и Samsung. Ожидается, что платформа AMD Verano, анонс которой запланирован на 2027 год, также получит поддержку данного формата. Это создаёт здоровую конкуренцию и снижает риски зависимости от единственного поставщика.

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

Значение для индустрии

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

Примечание: данные о производительности приведены на основе спецификаций производителей и тестовых конфигураций; реальные показатели могут варьироваться в зависимости от системной архитектуры и рабочей нагрузки.

Источники:

https://developer.nvidia.com/blog/inside-the-nvidia-rubin-platform-six-new-chips-one-ai-supercomputer/
https://semiconductor.samsung.com/dram/module/socamm2/
https://www.tweaktown.com/news/108474/micron-starts-sampling-its-192gb-socamm2-low-power-memory-for-use-in-ai-servers/index.html

Игра в имитацию сновидений для быстрого засыпания.

Знакомая ситуация: вы закончили работу над сложным багом в 2 часа ночи, легли в постель, но мозг отказывается переходить в режим Standby. Вместо сна вы прокручиваете циклы кода, планируете завтрашние задачи или ведете воображаемые споры в комментариях. Обычные советы вроде «считайте овец» часто не работают...

Механика: что такое когнитивный шаффл?

Метод когнитивного шаффла (или «серийного разнообразного воображения» — SDI) был разработан доктором Люком П. Бодуэном из Университета Саймона Фрейзера.

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

Источники: BBC Future: The micro-dreaming game :  CNN: Mental trick to help you sleep 

Почему это работает?

• Имитация микро-снов: метод имитирует естественный процесс «гипнагогического менталитета» — хаотичных образов, которые возникают у нас прямо перед засыпанием. Мозг воспринимает этот хаос как сигнал к отключению.

• Блокировка тревоги: случайные образы занимают «рабочую память», не давая ей обрабатывать стрессовые сценарии.

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

Алгоритм (Step-by-step) 

• Выберите «seed-слово»: Оно должно состоять минимум из 5 букв, быть эмоционально нейтральным и не содержать повторяющихся букв (например, «КВАРТАЛ»).

• Возьмите первую букву (например, К) и придумайте слово на эту букву, которое легко визуализировать (например, «КАКТУС»).

• Визуализируйте этот предмет в течение нескольких секунд и переходите к следующей букве.

• Когда слова на текущую букву закончатся или вам станет скучно, переходите к следующей букве вашего "seed-слова".

Важно: если слово вызывает у вас стресс (например, «Проект» или «Правки»), просто пропустите его и переходите к следующему. Обычно люди засыпают, не дойдя даже до третьей буквы.

Метод может не подойти в следующих случаях:

• Афантазия: неспособность визуализировать образы.

• ADHD: Некоторым людям с СДВГ сложно удерживать фокус даже на случайных словах.

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

Когнитивный шаффл — это способ «обмануть» регуляторы сна в мозгу, заставляя его обрабатывать случайные визуальные образы. Это переводит систему из аналитического режима в режим «микро-снов», характерный для засыпания.

Алгоритм: Слово > Буква > Серия визуализаций на эту букву > СОН.

ChatGPT на собесе: инструкция по провалу

На прошлой неделе провёл два техсобеса на Kotlin-разработчика и в очередной раз словил абсолютный кринж: кандидаты пытаются проходить интервью с ChatGPT, и делают это максимально тупо.

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

*️⃣ Стук клавиш. Я задаю вопрос, человек задумчиво молчит, зато в микрофон радостно начинает лупить механическая клавиатура. Напокупали себе кастомных механик с громкими свитчами, а теперь палятся на первом же промпте.

*️⃣ Светомузыка на лице. Кандидат сидит в полутёмной комнате, и ровно после моего вопроса его лицо внезапно озаряется белым светом - открылась спасительная вкладка браузера.

*️⃣ Бегающий взгляд. Прямо на камере видно, как глаза двигаются влево-вправо, считывая строчки сгенерированного текста.

Как выглядит сам диалог с таким «киборгом»?

Например, прошу объяснить, что такое ACID. Кандидат сначала зависает на 5–7 секунд. Мнётся, выдаёт невнятное мычание в духе «ну… это короче про базы данных и надежность».

А потом в него вселяется Википедия. Он внезапным дикторским голосом начинает чеканить:

ACID — это Atomicity, Consistency, Isolation, Durability…

и выдает все расшифровки книжным языком. Переход от “не могу связать два слова” к “я лектор по базам данных” занимает ровно одну загрузку ответа.

И это не моя личная паранойя. В Huntflow я всё чаще вижу в карточках от других интервьюеров пометки: “кажется, использует ИИ”, “вероятно, зачитывает ответы с экрана”.

Как я на это реагирую в моменте? Не рублю с плеча и не устраиваю сцен. Сначала даю шанс, пытаюсь помочь наводящими вопросами. Но когда понимаю, что человек на том конце провода не рассуждает, а просто работает кожаным интерфейсом между мной и LLM,  я перестаю его вытаскивать. Просто прогоняю по оставшимся вопросам в x2 скорости и сворачиваю звонок.

Знаете, в чём главная ирония? Я вообще не из лагеря морализаторов: обманул на собесе - в ад.

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

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

Дебаж 🐞с ноги в TG, VK и Дзен

В Японии представили спортивную визуальную систему Fencing Visualized, которая в с помощью ИИ в режиме реального времени отслеживает движение шпаг и спортсменов на дуэлях, рисуя их цветные шлейфы. Технология работает через компьютерное зрение без датчиков и маркеров. Дополнительно система распознаёт приёмы фехтовальщиков и показывает их на экране.

Переосмысление библиотеки LDL.

Я полностью пересмотрел концепцию библиотеки LDL.

Что такое LDL?
Это графическая библиотека с единым API для всех систем как старых, так и новых.

Раньше я писал её на C++98, что давало хорошую портабельность. Но сейчас я пересмотрел многие тезисы, которые декларировал на GitHub, чтобы наконец добраться до первого релиза.

Новая стратегия

Я решил выпускать релизы без реализации полного функционала (графика, звук, шрифты и т.д.) постепенно, итеративно.

• Перешёл на C89 для максимальной переносимости. Это не только DOS или Windows 3.x, но и старые системы вроде Solaris, PlayStation 1 и другие.

• Для первого релиза реализую минимальный базовый функционал: графику (OpenGL, Vulkan), окна и события. По возможностям аналог GLFW.

• С каждым следующим релизом буду добавлять: 2D-рендер, звук, шрифты и прочее.

Лицензия и целевые платформы

• Лицензия меняется на LGPLv3.

• На старте поддерживаются Windows и Linux.

Качество и инструменты

При разработке использую:

• AddressSanitizer (ASan)

• UndefinedBehaviorSanitizer (UBSan)

• Различные анализаторы кода

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

Примеры и бэкенды

• Добавлю десятки примеров с OpenGL 1.x, OpenGL 3.x и Vulkan.

• Буду добавлять бэкенды для LDL: не только под ОС, но и поверх других графических библиотек — SDL, SFML, GLFW и т.д.

• API остаётся единым для всех бэкендов.

Это позволит сразу добавить поддержку звука и шрифтов (через бэкенды), а в нативных версиях реализовывать их позже.

 2D-рендер без границ

Одной из главных задач LDL я вижу создание единого 2D-интерфейса, который стирает различия между поколениями графики.

Вам не нужно думать о том, что находится в системе: современная видеокарта с Vulkan, старый ускоритель с OpenGL 1.2 или вообще только центральный процессор (Software Rendering).

• Единый интерфейс: Вы используете одни и те же команды для рисования пикселей, линий и спрайтов.

• Адаптивность: LDL сам выберет наиболее эффективный способ вывода изображения. На современной системе это будет аппаратное ускорение, а на «железе» без видеокарты оптимизированный программный растеризатор.

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

Философия: Машина времени в вашем коде

Зачем тратить силы на поддержку систем, которые многие считают «трупами»?

1. Борьба с цифровым забвением

Современный софт живет 3–5 лет. Мы выбрасываем железо не потому, что оно сломалось, а потому, что софт стал слишком тяжелым и ленивым. LDL — это протест против «запланированного устаревания». Я хочу, чтобы код, написанный сегодня, мог дышать в железе любой эпохи.

2. Инженерный аскетизм

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

3. Преемственность поколений

Мы стоим на плечах гигантов, но часто забываем их имена. LDL сохраняет возможность для диалога между эпохами. Это инструмент, который позволяет современному разработчику почувствовать «металл» старых машин, не теряя связи с современными технологиями вроде Vulkan.

Итог

LDL — это Little Directmedia Layer. Он маленький не потому, что слабый, а потому, что в нем нет ничего лишнего. Это попытка создать код, который будет принадлежать не конкретной версии ОС, а истории программирования в целом.

Один API. Один код. Тридцать лет компьютерной истории.

Когда у тебя 50 отчётов в FineReport, 100+ дашбордов в FineBI, и никто не знает, откуда берутся данные 

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

В Галамарте решили это системно: подключили дата-каталог DataHub к продуктам FanRuan. Как именно это сделали, какие стены пришлось пробить и чего не нашлось ни в одной документации, расскажет Дмитрий Конюхов на FineDay Online.

Что получили на выходе:

— бизнес-глоссарий, где каждый термин привязан к формуле, источнику и конкретным дашбордам

— lineage от витрины до сырых данных — в одном окне, за пределами FanRuan

— возможность за секунды найти, в каких из 100+ дашбордов используется нужнаяметрика

— базу для self-service: аналитики переиспользуют существующие датасеты вместо создания новых

📅 22 апреля | 15:00 МСК | FineDay Online 2026

Бесплатно, онлайн, ~3 часа

→ Регистрация

Иллюзия автоматизации: почему API не гарантирует легкую миграцию

Мы в Хайстекс любим API-интеграции, это стандарт и архитектурная основа нашего продукта. Когда нужно мигрировать сотни машин в зрелые публичные облака, API — оптимальный выбор. Но у любого вендора СРК и миграции есть бэклог с кейсами, где API превращается из помощника в серьезную издержку.

Этот пост — для инженеров и архитекторов, которые занимаются миграциями ВМ и регулярно упираются в стоимость и сроки поддержки API-интеграций под каждую новую целевую площадку.

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

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

Если API целевой среды — это нестабильная переменная, логично вывести её за скобки. Так появилась архитектура Direct2Target (D2T). Это метод, позволяющий сделать целевую сторону миграции полностью воспроизводимой без зависимости от API конкретного облака. В сценарии D2T целевая ВМ-«болванка» подготавливается заранее — вручную или с помощью ваших привычных скриптов («инфраструктура как код»). Решение не тратит время на попытки договориться с облаком о создании ресурсов, а сразу приступает к главной задаче: доставке данных напрямую в диски подготовленной машины.

D2T — не замена API-подходу, это «план Б». Функция позволяет развернуть машину в условиях архитектурных ограничений целевой площадки, не дожидаясь доработок со стороны провайдера.

О том, как реализовать миграцию «в обход» API, почему это в 5 раз быстрее и как перестать превращать переезд в вечную разработку — поговорим на вебинаре 29 апреля в 11:00 (МСК). Регистрация по ссылке.

В программе:

• Прикладные сценарии: когда D2T эффективнее классической интеграции по времени и ресурсам.

• Технологический стек: как обеспечить воспроизводимость миграции на любых площадках без зависимости от API.

• Live Demo: подготовим таргет-ВМ и запустим миграцию в прямом эфире.

Приносите в комментарии баги облачных API, из-за которых сроки проектов улетали в бесконечность. Обсудим, как D2T мог бы упростить вам жизнь в тех кейсах. 

Не раз замечал, что многие люди, даже заставшие эпоху DVD-дисков, до сих пор толком не понимают разницу между DVD+R и DVD-R. Что уж говорить о каких-нибудь сотрудниках больниц, которые требуют «правильные» диски для записи КТ или МРТ. Поэтому предлагаю немного разобраться в этом вопросе и кратко рассказать, как всё было. Да, эпоха DVD уже давно ушла, но разве не любопытно узнать что-то новое о такой, без преувеличения, олдфажной теме?

——————————————————

В конце 90-х и в нулевых, на фоне нового типа дисков случилась маленькая война форматов. Pioneer показала первый DVD-R привод ещё в 1997 году (нашёл для вас первоисточник), а сам формат продвигал DVD Forum — объединение, отвечавшее за «официальные» DVD-стандарты. В него входили такие фирмы как Hitachi, Panasonic, Mitsubishi Electric, Philips, Pioneer, Sony, Toshiba, JVC и еще несколько других компаний.

DVD+R пришёл позже, уже в 2002 году, и его развивала отдельная коалиция компаний, известная как DVD+RW Alliance, в основу ядра которой входили Dell, Hewlett-Packard, Mitsubishi Chemical/Verbatim, Philips, Sony, Thomson Multimedia и Yamaha и некоторые другие.

И если объяснять совсем просто, DVD-R и DVD+R — это одноразовые болванки почти для одних и тех же задач, но с разной логикой записи. У DVD-R используется метод адресации Land Pre-Pit, а у DVD+R — ADIP; второй считался менее чувствительным к помехам и лучше подходил для более скоростной записи. При этом у DVD+R была ещё одна полезная особенность: возможность выставить book type как DVD-ROM, что иногда улучшало совместимость со старыми проигрывателями. Но в эпоху ранних бытовых DVD-плееров именно DVD-R долго воспринимался как более надёжный и безопасный выбор с точки зрения совместимости, потому что этот формат появился раньше и быстрее стал массовым. Именно поэтому во многих государственных учреждениях до сих пор требуют именно DVD-R: их устаревшие приводы нередко банально не читают более поздний и технологически продвинутый формат DVD+R.

Олдфажный факт: если у Mitsubishi участие в обоих альянсах всё же было разведено по разным компаниям внутри большой Mitsubishi Group — речь о Mitsubishi Electric и Mitsubishi Chemical, — то про Sony такого уже не скажешь. Она, по сути, работала сразу на два фронта 😄

Вам может быть интересно:

• «Рождение легенды: Soldier of Fortune»;

• «The Sims: история игры, которую “отменяли” снова и снова»;

• «Игры из эфира: как радио сделало гейминг доступным каждому».

——————————————————

Я играю в игры больше 25 лет и запомнил их именно такими: душевными и затягивающими, с увлекательными механиками и интерактивностью, без внутриигровой валюты и попыток быть чем угодно, но не игрой. В моём Telegram канале тебя ждут не только обзоры на игры, но и актуальные новости, а также рассуждения о геймдеве. Присоединяйся к сообществу олдфагов!

Экипаж миссии «Артемида II» заснял из корабля «Орион», как Земля заходит за Луну, используя iPhone 17 Pro Max и 8-кратный зум.