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

Всех приветствую!

Данная статья будет посвящена довольно важным вещам, таким как: refreshtoken, метод-уровневой безопасности и примеру реализации правила "свой/чужой профиль"

Проблема, которую не решает обычная оптимизация

Классические методы оптимизации — градиентный спуск, генетические алгоритмы с элитизмом, CMA‑ES — заточены под одну вещь: найти один глобальный максимум функции приспособленности. Всё остальное население на пути к этому максимуму считается расходным материалом и отбрасывается.

Но во многих задачах нас интересует не единственное решение, а набор разнообразных хороших решений:

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

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

Дизайн и инженерия. Инженеру интересно увидеть весь фронт компромиссов (вес vs прочность vs стоимость), а не одну точку.

Открытые (так называемый open‑ended) эволюционные системы, где само понятие «лучшего» плохо определено, а интересна широта поведенческого репертуара.

Это направление получило название Quality‑Diversity (QD) оптимизации: цель — не максимизировать один скаляр, а заполнить пространство возможных поведений решениями, каждое из которых максимально хорошо в своей поведенческой нише.

MAP‑Elites — один из первых и самый концептуально простой алгоритм этого семейства.

Идея алгоритма

MAP‑Elites (Multi‑dimensional Archive of Phenotypic Elites) был предложен в 2015 году.

Языковые модели генерируют текст, следуя скрытым грамматическим правилам, или грамматика - просто побочный эффект предсказания следующего слова?

Этот вопрос увлёк меня почти на два года исследований.

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

В статье разберём, как выстроить воспроизводимый ML‑пайплайн с контролем данных, версий и состояний, чтобы решения модели можно было восстановить, проверить и обосновать.

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

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

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

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

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

Думаю, один из самых завораживающих и интересных феноменов, о котором я узнал именно с Хабра — это клеточные автоматы. О Джоне Конвее и его игре «Жизнь» я впервые прочитал в переводной статье уважаемого @SLY_G «Джон Хортон Конвей: Жизнь, как игра», а среди авторских материалов мне запомнились «Наша Вселенная — симуляция на основе большого клеточного автомата?», которую мне довелось прочитать, будучи в жюри конкурса «Технотекст», «Простейшие клеточные автоматы и их практическое применение» уважаемого @oshibka404 и, наконец, блестяще иллюстрированная алгоритмическая работа «Эволюционирующие клеточные автоматы» уважаемого @xcont. Эти статьи натолкнули меня на размышления о том, почему биологическая (дарвиновская) эволюция не слишком популярна в качестве источника сюжетов для компьютерных игр. Если как следует поискать, такие игры всё-таки существуют (пусть многие из них и напоминают образовательные пет-проекты), но мейнстримом они определённо не стали. Под катом попробую рассмотреть, так ли интересно играть в эволюцию и не слишком ли фаталистична и сложна эта тема в качестве развлекательной.

Есть таблица GPS-точек. Транспорт шлёт координаты каждые несколько секунд, за сутки набегают миллионы строк, и таблица секционирована по времени. Значит, кто-то должен заранее создавать партицию на завтра и отцеплять партиции старше девяноста дней. Иначе в одну прекрасную ночь вставка упадёт с no partition of relation "gps_points" found for row, и это будет ровно в тот момент, когда никто не смотрит.

Я запустил Ideogram 4 локально на Mac, а затем собрал для него нативное приложение на Swift и MLX — без отдельного Python-процесса во время рендера. Сразу честно: «6 часов против 11 минут» — не ускорение одной картинки в 35 раз, а два разных режима: максимальный Quality 2048×2048 на 48 шагах и повседневный Turbo 1152×768 на 12. Это продолжение серии о Typhoonminigen. В статье — архитектура приложения, реальные замеры, удачные решения, ограничения и ошибки, которые пришлось исправлять по пути.

Как мы сегодня измеряем работу разработчиков: velocity, story points, lead time, cycle time, число PR и закрытых тасок. Строим красивые дашборды, считаем DORA-метрики, прогнозируем сроки, оцениваем загрузку команд.

А вот измерение инженерных решений на зачаточном уровне. В лучше случае ADR и запись в трекере техдолга. Чаще — вообще ничего.

Существующая оценка качества инженерии субъективна.

Обычно это мнение тимлида с 3–5 годами опыта в одной-двух предметных областях. При этом именно инженерные решения определяют стоимость разработки через год-два: смогут ли десять разработчиков одновременно работать над кодом и можно ли вообще масштабировать продукт без переписывания половины кодовой базы.

Сегодняшняя парадигма проста: чтобы большой проект не развалился, достаточно вытягивать DESIGN + держать выше среднего CODE QUALITY. А 2026 год показал, насколько все забивают на SECURITY, а с перформансом справляются тем, что бигтехи держат под это отдельные перф-команды: как будто уже написание (или проектирование+генерация) эффективного алгоритма больше не влияет на то, кто действительно Senior.

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

Мы научились измерять скорость разработки. Но почти не измеряем качество инженерии. 

Что вообще такое инженерный уровень?

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

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

О том, как я это сделал и какие возможности получила моя система, — в этой статье.

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

В 2026 году тот же путь можно пройти быстрее: передать ИИ требования и за несколько итераций получить кликабельный прототип на HTML, CSS и JavaScript — с формами, модальными окнами, валидацией и тестовыми сценариями.

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

Ну то есть настоящий агент. Не «я иногда открываю ChatGPT в соседней вкладке». Не «у меня Cursor дописывает функции». А именно свой - который живёт прям в мессенджере (эх, пока не в квартире/доме), помнит всё про твои проекты, тебя и всегда под рукой, что бы ни случилось.

Если да, то это круто, напиши в комментариях как его зовут

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

После вайб-кодинга: почему в 2026 году появляется новый класс Code Clean-up Agents. Как стоимость разработки смещается от генерации к проверке, рефакторингу и контролю изменений

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

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

В этой точке полезно отделить генерацию патча от подготовки изменения к отправке в основную ветку. Для второй задачи в 2026 году формируется отдельный класс инструментов: Code Clean-up Agents.

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

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

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

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

Мысли о масштабируемой архитектуре приложений через кодовую структуру и философии «developer as a user»; подходит для indie-разработчиков и стартапов на ранних стадиях.

Я фрилансер. Делаю лендинги, интерактивные сайты и AI-продукты. Три месяца назад зарегистрировался на Kwork, FL.ru и Workzilla. Активно откликаться начал только с начала июля — и уже не раз попадаю в шорт-лист кандидатов. Обсуждаю детали, предлагаю решения.

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

Это не история успеха. Это история о том, что я сделал, пока жду.

Если ты в похожей ситуации — навык есть, портфолио пустое, клиенты пока не выбрали — эта статья для тебя. Без мотивационных цитат и «просто верь в себя». Конкретный опыт.

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

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

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

Артефакт нашей сборки — не бинарник, а код вместе с терабайтами рассчитанных таблиц. Рассказываем, как из штатных фич Airflow, Spark и Delta Lake у нас собрался настоящий CI/CD для данных и моделей — с релизами, стейджем и откатами. И почему кнопку «выкатить в прод» жмёт дежурный data scientist, а не инженер данных.