Алгоритмы *

Каждый день мы пишем JSX, используем хуки и стараемся не нарушать их строгие правила. Но как вся эта «магия» работает под капотом? Почему условный рендер ломает useState, а индексы массива в key приводят к багам? Зачем React перешел на архитектуру Fiber и как алгоритм обходит дерево элементов, не блокируя браузер?

Чтобы перестать воспринимать React как черный ящик, лучший способ — написать его с нуля.

В этой статье мы шаг за шагом воссоздадим собственный движок React. Мы реализуем функцию createElement, разберем Fiber-архитектуру с асинхронным рендерингом, напишем алгоритм Reconciliation и создадим систему хуков, разобравшись в логике их работы.

Меня зовут Дарья Беляева, я — Tech Lead и архитектор решений на стыке BIM, CDE и Revit API. Мы с коллегой, Андреем Прохоровым, за два месяца с нуля сделали AGR.Checker — плагин для Revit, который проверяет ЦИМ на соответствие требованиям IDS перед сдачей в составе АГР. В этой статье — конкретные инженерные решения, которые легли в основу плагина, и то, с чем мы разобрались при регистрации прав на программу в Роспатенте.

В первой части мы успешно вскрыли чёрный ящик LINQ: написали Where вручную, разобрались, как компилятор превращает yield return в конечные автоматы, и посмотрели на методы с частичной буферизацией. Но LINQ был бы не собой, если бы на этом всё закончилось.

Во второй части переходим к «тяжёлой артиллерии» — OrderBy, GroupBy и Join. Эти методы вынуждены нарушить главный завет ленивых вычислений: они материализуют данные в памяти, прежде чем отдать хоть один элемент. Но как именно?

После этой статьи LINQ перестанет быть чёрным ящиком: вы будете точно понимать, сколько памяти съест каждая цепочка методов и в каком порядке следует вызывать эту цепочку.

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

Для кого этот учебник?

• Для новичков в сфере финтеха. Он полезен для ознакомления с этой предметной областью и паттернами, обеспечивающими надёжность финансовых систем.

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

• Для людей вне сферы финтеха. Чтобы понять, как и почему разработка ПО для финансовых систем отличается от привычной вам.

Чем отличаются DQN, PPO, SAC, AlphaZero и другие модели reinforcement learning друг от друга? В этой статье я простым языком разберу основные алгоритмы обучения с подкреплением и покажу на одной карте, как они связаны между собой.

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

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

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

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

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

Несколько раз в год отдел оптимизации офисного пространства Альфа‑Банка думает над тем, как разместить сотрудников бэк‑офиса по локациям на несколько лет вперёд. Раньше ребята делали это вручную: было медленно (месяц работы), больно (Excel) и неоптимально (никто не мог гарантировать, что найденная рассадка удовлетворяет всем ограничениям).

Коллеги хотели автоматизировать ручную работу — с этим они и пришли к нам. 

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

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

Через 26 часов посмотрели что получилось.

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

В этой статье рассмотрено, как передавать данные пакетами через baremetal приложение no-os на ad9361. Для генерации фрейма на передающей стороне и обработки фрейма на приёмной стороне использована библиотека liquid-dsp, которая скомпилирована под arm ядро в zynq-7000. Для ретрансляции сообщений использован алгоритм обхода графа BFS (Breadth-First Search, поиск в ширину) и простая система адресации приёмопередатчиков в полезной нагрузке пакета сообщения.

Зачем тратить сутки на перелёты, мчаться на другой конец света и жить неделю в режиме нон‑стоп на одной из главных ML‑конференций планеты, когда пейпер уже на arXiv, код — на GitHub, а краткие выжимки из выступлений — мгновенно в соцсетях?

Меня зовут Карина Романова, я разработчик в Яндексе и занимаюсь LLM‑агентами в Алисе. В июле мы с командой прилетели в Сеул на ICML 2026, и я ответила себе на вопрос «зачем?». Для нас офлайн‑конференции — это единственный способ за несколько дней прочувствовать реальный фокус сообщества, встретиться с авторами работ и узнать детали, которых нет в опубликованных текстах.

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

У меня браузерный генератор вывесок: человек набирает надпись, получает STL-модель корпуса под светодиодную ленту. Всё считается на его же машине, файл никуда не уходит. Однажды пришёл вопрос, который сломал мне неделю: надпись 500 мм, стол принтера 256×256. Что делать?

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

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

Реализация Raft на TypeScript под сидированной симуляцией: каждый тик, каждая задержка сообщения и каждое падение узла берутся из сида. На двадцать пятом прогоне две реплики применили разные значения — при том, что правила алгоритма выполнялись все до одного.

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

Машина Тьюринга (МТ) не сферический конь в вакууме программистского бытия. Она не про «единички-нолики» и елозанье вдоль ленты, а про гимнастику мозгов для программистов. Продолжим тему МТ, начатую в [1]. Ее программирование увлекательная и, без сомнения, серьезная работа по созданию алгоритмов при миним миниморум средств на их реализацию Тем и привлекательна. Особенно на этапах обучения алгоритмическому мышлению.

Продолжим тему нахождения наибольшего общего делителя (НОД) двух чисел для МТ. Только теперь это будет обычное программирование. По счастью ли по совпадению нужный нам алгоритм приведен в книге Н.Вирта [2]. Его блок-схема (БС) приведена на рис. 1. Обычная и ни чем не примечательная БС и совсем простой алгоритм. Особенно в сравнении с рассмотренными для МТ. Привел он его, преследуя другие цели, но сейчас не это главное.

Если мысленно вернуться в 1980-е, аналитика во многом находилась буквально над production

Данные появлялись в операционных системах, затем из них строились отчёты, выгрузки и аналитические витрины. Постепенно мы начали выносить аналитику подальше от production: появились отдельные хранилища, ETL, data warehouse, затем data lake, lakehouse и, наконец, огромный набор специализированных систем для streaming, batch, realtime и research

Каждый раз мы решали вполне реальные проблемы своего времени. Но вместе с этим постепенно привыкли к довольно странной модели:

production хранит настоящее, data lake - прошлое, Kafka - поток, а research живёт где-то ещё

И вот здесь мне стало интересно немного заглянуть вперед...

А что, если в 2052 году мы перестанем воспринимать всё это как разные сущности?

Опираясь не на фантазии, а на то, что смог найти в технических блогах - не концепты, а реальные прототипы

Если не хотите много читать, в конце статьи вся суть одной картинкой

Привет, Хабр! Однажды я подумал, что вот не умеют разработчики жить. В каждом из языков есть свои напасти (от которых, в принципе, спасаются разве что разработчики-полиглоты). Возьмем хотя бы C++ — даже без его шаблонов, исключений, и т.д., там все еще много мраков. Возьмем хотя бы iostream — он, блин, весит 2 МБ в последней версии GCC при компиляции под Windows! Или, вот, std::string — динамическая строка. Звучит интересно на бумаге, учитывая, что язык не из добрейших, но на практике...

У ДДТ был свой ответ на вопрос «что такое осень». И даже не один. У C++-разработчиков — свой: это когда вместо листьев разлетаются корутины, вместо дождя — потоки событий, а select и poll внезапно становятся отличной темой для вечерней встречи. 10 сентября в 18:30 проверим эту версию на мероприятии YADRO и C++ Russia. 

В программе — два технических доклада от разработчиков «Лаборатории Касперского» и YADRO. Перед выступлениями Александр Иргер, эксперт по разработке ПО в области телекоммуникаций, расскажет о планах московского сообщества «плюсовиков» и о том, над какими задачами работают сотни разработчиков на С++ в YADRO. Чтобы присоединиться к встрече в любом формате, пожалуйста, зарегистрируйтесь заранее.

Свой пост я написал после участия в соревнованиях gralhix 004, организованных Софией Сантос | Gralhix.

Задача

Это фотография островного курорта.

Вопросы:

а) Как называется курорт?

б) Каковы координаты острова?

в) В какую сторону света была направлена камера, когда делали снимок?

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

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

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

Спойлер: асимптотика здесь не ошибается. Ошибается вывод, который мы из неё делаем.

Статья для тех, кто асимптотику знает, но не проверял её замером.