Kurgan-Telecom Ru | Информационные технологии

Мы, devrel-ы, привыкли, что удивлять и креативить — это наша работа, поэтому к чужим приглашениям часто относимся со сдержанным профессиональным прищуром. Однако когда я получила пригласительное письмо на 20-й День рождения Хабра с темой «Дача 2.0», внутри что-то щёлкнуло раньше, чем я успела включить своего внутреннего скептика: я поняла, что точно не пропущу это событие.

В феврале 2024 года американская ContextLogic объявила, что продаёт маркетплейс Wish сингапурскому холдингу Qoo10 за 173 млн долларов. Цифра выглядит обычной для сделок такого рода, пока не вспомнить, что десятью годами раньше Wish был самым скачиваемым шоппинг-приложением планеты, оценивался в 14 млрд долларов и официально отказался от предложений о покупке от Amazon и Alibaba по 10 млрд каждое. Цена сделки оказалась на 99% ниже пиковой оценки — фактически от компании, претендовавшей на роль следующего Walmart, остался только торговый знак, переходящий из рук в руки.

Как выкатить собственный движок JavaScript

Привет, Хаброжители! Мы подготовили для вас перевод статьи, в которой автор делится опытом создания собственного движка JavaScript с нуля.

Автор на языке Go с нуля создаёт простой движок JavaScript. В статье пошагово разобраны ключевые этапы: от лексического анализа и построения AST до реализации вычислителя и встроенных функций (print, fetch, JSON). Отличный материал, чтобы понять, как код на JS превращается в работающие инструкции.

Каждый раз, когда нужно передать кому-то файл или пароль, выбор бесит: WeTransfer и аналоги видят всё, почта и телеграм хранят файл в плейнтексте вечно, PrivateBin только для текста. Хотелось простого: бросил файл, получил ссылку, а сервер физически не может его прочитать. И чтобы сервер был мой. Так появился share·me, self-hosted сервис, который шифрует файлы и текст прямо в браузере (AES-256-GCM), а ключ кладёт в URL-фрагмент, который браузер никогда не отправляет на сервер. Внутри: Rust/axum, Next.js, потоковое шифрование больших файлов и пара граблей, на которых я споткнулся.

10 новых российских продуктов для цифровизации работы клубов и сообществ, умного поиска с ИИ для интернет-магазинов, установления прямых контактов с клиентами, анализа и управления корпоративными знаниями, мягкой нейрокоррекции для детей и взрослых и многого другого. Битва за «Продукт недели» началась!

Product Radar — здесь каждую неделю публикуются лучшие онлайн-сервисы и железки от русскоязычных команд.

Платёж не прошёл. Отключить пользователя сразу или подождать? Если подождать, то сколько и на каких условиях? Разбираем механику grace-периода изнутри: состояния подписки, поведение доступа для B2C и B2B, цепочку уведомлений и технические подводные камни.

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

Нашел простенькую сказку — «Колосок» — и стал искать, как в целом можно генерировать видео-контент своими руками.

Если вам было интересно погенерировать видео на открытых моделях и посмотреть, что из этого получится — эта статья как раз про это. Можно наглядно посмотреть результат

Anti-corruption layer в учебниках выглядит как одна аккуратная коробка между чужой системой и вашей: всё чужое остаётся снаружи, внутрь проходит только то, что уже переведено на язык вашего домена. Граница ровная, как по линейке. Почти за год, что мы вытесняли 10-летний Rails-монолит на .NET, такой ровной границы я не увидел ни разу – ни у себя, ни, кажется, у кого-то ещё на живом проекте.

Понятно это стало в первую же неделю. Мы открыли таблицу exercises и нашли в одной JSONB-колонке 14 разных форм одного типа задания, слепленных за 10 лет. Смаппить это в новые DTO как есть – и новая модель отрастит ровно ту же форму, что у Rails. “Нужен ACL”, подумали мы. Только, как выяснилось на практике, не один.

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

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

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

В прошлой статье про ГИГАХРУЩ мы показали игру как живой weird-проект: браузерный survival horror / ARPG без движка, ассетов и спокойной жизни.

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

Разберем, как ГИГАХРУЩ устроен под бетоном: один активный клеточный этаж, typed arrays, плоские сущности, WebGL raycasting, A-Life, самосбор как мутация мира, сохранение, ограничения и MESH PASS как render-only объем поверх клеточной симуляции.

В предыдущей части цикла разобрали 13 таблиц REDB: как устроены objects, values, structures, как RTTI-хранение значений отличается от старого EAV-паттерна, зачем нужен scheme_metadata_cache. Если не читали — начните с неё, без понимания схемы дальше тяжело.

В этой статье — то, что обычно идёт следующим вопросом: «А индексы где? У вас же значения всех полей лежат в одной таблице. Любой WHERE — это Seq Scan по миллионам строк».

Это статья 1.1, а не 2 — потому что она прямое продолжение разговора про физическое хранение. Глубокое погружение в C# — это статьи 3-5 цикла: Code-first схемы (SyncSchemeAsync<T>), CRUD (SaveAsync/LoadAsync), LINQ-транслятор. Здесь разговор остаётся в плоскости БД и DDL.

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

В предыдущей статье я рассказал, как писал скрипт мониторинга системы с нуля от идеи до рабочего инструмента с меню, цветным выводом и уведомлениями в Telegram. Там же выяснилось, что большинство проблем при написании bash-скриптов возникает не из-за сложной логики, а из-за незаметных ошибок: забытых токенов-заглушек, тихих падений через pipe, команд которые молча возвращают не то. Именно тогда я понял, что echo для отладкиэто каменный век.

Скрипт мониторинга написан и работает. Теперь поговорим о том, что делать, когда он перестаёт работать или ведёт себя странно. Я собрал инструменты и приёмы, которые реально меняют то, как работать с bash. Не абстрактный список из документации, а вещи которые я использую сам и которые несколько раз спасали в ситуации «скрипт упал на проде, надо найти за пять минут».

Для тех, кто спешит: быстрая шпаргалка

Система продуктивности Один большой текстовый файл OBTF - исследуем какие фишечки можно навесить концепцию в эпоху ИИ.

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

Привет! Меня зовут Дмитрий. Я делал несколько проектов в разных сферах, но все они заканчивались на стадии MVP, хоть и по разным причинам: идея стала никому не нужна, команда выгорела или не хватило скиллов довести до результата.

Поэтому новый проект я начал с намерением дойти до реального работающего продукта с клиентами.

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

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

Большинство этих примеров родилось в эпоху до C++11, когда у языка ещё не было ни умных указателей в стандарте, ни move-семантики, ни constexpr, ни концептов, и приходилось руками собирать из шаблонов и перегрузок некоторые кострукции, которые в более поздниях стандартах язык даёт почти бесплатно. Многие идиомы, примеры и идеи стоит читать в двух смыслах сразу, как исторический артефакт, объясняющий «почему старый код выглядит вот так», и как живой приём, который всё ещё применяется в движках и играх.

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

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

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

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

Как обычно, я сидел и думал, как бы уменьшить расходы токенов в Claude Code.. Рефлексировал содержимое сессий, исследовал вместе с самим Claude Code и наткнулся на интересную штуку.
Сначала я было хотел написать свой писатель файлов из под клода, вместо Write. Но подумал, что это будет слишком напряжно, если делать это в клоде, поддерживать, и так далее.
Но для редактирования файла его надо читать(обязательно! Как минимум в Claude Code) - что логично. Вопрос: а сколько его надо читать? Конкретно сколько строк его надо читать? Теоретически весь? А практически? Для замены, к примеру, одной строки?!
И да, Read читает по-разному, Но всегда больше одной строки(мелкие файлы читаются за один Read)..Ок, а обязательно ли для редактирования читать весь файл(или куски)? И вот вот тут-то нас ожидает сюрприз! Для снятия "защиты" файла от редактирования (в сессии Claude Code) достаточно прочитать ОДНУ строку указанного файла:):)
Если у тебя есть средство поддержки актуальности теста файла(я намекаю на code-index), то снятие гейта в модели будет выглядеть примерно как:

(кусок кода сессии)

Read C:\MCP-Servers\code-index\Cargo.toml (lines 2-2)

Read C:\MCP-Servers\code-index\CHANGELOG.md (lines 2-2)

Read C:\MCP-Servers\code-index\CHANGELOG_EN.md (lines 2-2)

Read C:\MCP-Servers\code-index\README.md (lines 2-2)

Read C:\MCP-Servers\code-index\README_RU.md (lines 2-2)

(это я готовил к выкладке очередной апдейт code-index.
Почему (2-2)? Сам не знаю, в промте указано (1-1), но везде модель ставит 2-2. Тайна сия великая есть:)).

И потом просто в темпе пулемета вызываются команды Edit.

Следовательно, в контекст тебе НЕ сыпятся куски файлов(которые тебе не нужны), и контекст остается максимально чистым.

Как сделать изменения, вносимые с помощью LLM, управляемыми, проверяемыми и воспроизводимыми.

Программные ассистенты LLM продемонстрировали значительную ценность, но в основном для отдельных разработчиков. Внутренняя ИТ-организация Thoughtworks использует их для своих команд и разработала метод и рабочий процесс, называемый структурированной разработкой на основе промптов (Structured Prompt-Driven Development, SPDD). В одноименной статье Вэй Чжан и Джесси Цзе Ся, опубликованной на сайте Мартина Фаулера, описывается простой пример этого рабочего процесса с подробностями на GitHub. Этот рабочий процесс рассматривает промпты как артефакт первого класса, хранящийся вместе с кодом в системе контроля версий и используемый для согласования разработки с потребностями бизнеса. Авторы обнаружили, что разработчикам для эффективной работы необходимы три ключевых навыка: согласованность, подход «сначала абстракция» и итеративный анализ.

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

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

Когда мы говорим об успехе творческих проектов, часто обсуждают качество работы, талант автора или удачную идею.

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