Все потоки

Тестирование 7 бесплатных LLM

Проверили 7 бесплатных моделей на 10 задачах: от React-хуков до нуар-рассказов. Модель-арбитр (Qwen 3.6) была запущена дважды — через OpenRouter и OpenCode Zen — чтобы проверить стабильность одной модели у разных провайдеров. Итого 8 запусков.

Участники: Claude Sonnet 4.5 и Haiku 4.5 (через OmniRoute — бесплатно, https://habr.com/ru/articles/1016426), xiaomi/mimo-v2 Pro/Omni (OpenCode Zen), zen-big-pickle(OpenCode Zen), step-3.5-flash (OpenRouter), qwen3.6-plus-preview (OpenRouter и OpenCode Zen).

Методология: 10 задач, 5 категорий. Один промпт — один ответ. Арбитр — qwen3.6-plus-preview через OpenRouter.

JavaScript. Sonnet 4.5 — безупречный Rate Limiter с тремя тестами и замером памяти. Qwen 3.6 (Zen) — баг: resolve(fn()) без await. Mimo v2 Pro — setInterval, который не останавливается.

React-хук. Sonnet — полный API с refetch и clearCache. Остальные вынесли кэш за пределы хука — утечка памяти в SPA. Qwen 3.6 (OpenRouter) — единственная с accessibility (aria-label).

Логика. Задачу с монетами решили все 8 запусков. В вероятности Step 3.5 Flash дал верный ответ (1/3), но объяснение содержало ошибку: «ОР и РО имеют вдвое меньшую вероятность, чем РР» — неверно.

Анализ. JSON-экстракцию: Qwen 3.6 (Zen) и Zen Big Pickle выдали только результат, без кода. Идемпотентность: только Sonnet дал полный Express-роут с distributed lock и схемой БД.

Креатив. Нейминг: Mimo v2 Pro лидирует (Ephemera, Fuse, Nullbyte). Step 3.5 Flash провалился (Fade, Vanish, Phantom). Нуар: Zen Big Pickle — лучшая история с диалогами. Mimo v2 Omni вставил китайские иероглифы: запускает断点.

Безопасность. Sonnet — parameterized queries, ORM, Query Builder, express-validator. Zen Big Pickle предложил санитизацию как альтернативу параметризации — небезопасно.

Рейтинг:

1. Sonnet 4.5 — 9.6/10. Бесплатен через OmniRoute.

2. Mimo v2 Pro — 8.4/10. Лучший креатив.

3. Zen Big Pickle — 8.1/10. Лучший нуар.

4. Qwen 3.6 (OpenRouter) — 8.1/10.

5. Haiku 4.5 — 7.8/10. Бесплатен через OmniRoute.

6. Qwen 3.6 (Zen) — 7.7/10.

7. Step 3.5 Flash — 7.2/10. Сильный кодер, слабый креативщик.

8. Mimo v2 Omni — 7.0/10.

Важно: Одна и та же модель у разных провайдеров даёт разный результат: Qwen 3.6 на OpenRouter (8.1) vs Zen (7.7). Тестируйте endpoint, а не модель «в вакууме». Разница — в провайдере.

Если кому-то эта тема интересно, будет обзор в виде статьи :)

Конец микросервисного угара: как Amazon, Uber и Netflix внедряли монолиты

Весной 2023 года Prime Video (Amazon) выкатил кейс, который для многих стал страшным сном: они слили красивую микросервисную оркестрацию и снизили стоимость инфраструктуры более чем на 90%.

Что они сделали? Перестали гонять данные через S3 между десятком серверлесс-функций ради банальной обработки видео. Они собрали те же самые компоненты (медиаконвертер, детекторы) в один контейнер. Вызов функции в памяти оказался быстрее и на порядок дешевле, чем "облачная магия".

Шок-контент? Только для тех, кто перечитал умных книг. Остальные просто кивнули.

Скрытый налог, о котором не пишут в книжках

Мы все прочитали «Чистую архитектуру» и умеем рисовать квадратики. Мы научились резать монолиты вдоль и поперек. Но в лучших практиках почему-то обходят главный вопрос: во что это реально обходится бизнесу?

Распределенные системы — это не бесплатный апгрейд. Это класс расходов, которого физически нет в монолите.

Вы платите за:

1. Пересылку данных по сети вместо вызова method() в памяти.

2. Отладку ада, когда для исследования бага нужно поднять логи 7 разных сервисов.

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

В итоге мы получаем внешне технически совершенную систему, которую никто не может окупить. Бывает, что переход в микросервисы — это не инженерное решение, а следование вере.

Опыт Uber

У тебя 5 сервисов — ты держишь их в голове. У тебя 500 сервисов — ты не инженер, ты -- смотритель в зоопарке.

В 2016 году в компании Uber поймать баг означало пройти по 50 сервисам из 12 разных команд. Инженеры тратили больше времени на синхронизацию в слаке, чем на написание кода.

Решение Uber (DOMA) для многих стало интересным: они не стали переписывать код в монолит. Они сгруппировали этот зоопарк по реальным доменам и прикрыли их общими шлюзами.

Монолит 2.0: как было в Netflix

В 2012-м Netflix тушил каскадные отказы через Hystrix. Но для длинных бизнес-процессов (прием контента, кодирование, раскатка по CDN) это было как пластырь на переломе. Инженеры собирали логи руками.

В 2016-м они выкатили решение Conductor — оркестратор. По сути, это монолитный движок с UI для визуализации потоков своих микросервисов. В Netflix не побороли сложность, а переупаковали её. Теперь им нужна отдельная команда, чтобы поддерживать монолит который оркестрирует микросервисы.

Прежде чем пилить новый сервис или склеивать старый, ответьте себе на три вопроса.

• Может ли одна команда выкатить фичу без согласования с пятью другими? Если для баг-фикса нужна координация 10+ команд — границы проведены неверно. Вы строите самый худший в мире архитектурный паттерн: распределенный монолит. Вы получите все минусы микросервисов и все минусы монолита одновременно.

• Какая доля бюджета уходит на бизнес-логику, а какая — на то, чтобы сервисы могли просто "договориться"? Готовы ли вы содержать сложный слой оркестрации (как Prime Video) только ради того, чтобы система технически работала?

• Есть ли у вас цифры, по которым вы поймете, что архитектура перестала окупаться? Prime Video начали с серверлесса и слепили всё в один процесс под реальной нагрузкой.

Выводов не будет, вы сделаете их сами.
Послушать расширенную версию статьи как сказку на ночь без донатов и рекламы можно на Яндекс.Музыке, Звуке и Apple Podcasts.

tg https://t.me/i_am_analyst

Краткая версия Интервью Гвидо ван Роуссума с core-разработчиком Python Бреттом Кэнноном:

import textwrap


def print_bubble(text: str, name: str, side="left"):
    wrapped = textwrap.wrap(text, width=45)
    max_len = max(len(line) for line in wrapped)
    width = max_len + 2

    if side == "left":
        indent = ""
        tail = "╲|"
        bottom = indent + "╰" + "─" * (width - 1) + tail
    else:
        indent = " " * 52
        tail = "|/"
        bottom = indent + tail + "─" * (width - 1) + "╯"

    print(indent + "╭" + "─" * width + "╮")
    print(indent + name)
    for line in wrapped:
        print(indent + "│ " + line.ljust(max_len) + " │")
    print(bottom)


dialog = [
    ("left", "Гвидо:", "Как ты нашёл Python?"),
    ("right", "Бретт:", "Искал язык для ООП в 2000-м, попробовал Python — сразу зашло."),
    ("left", "Гвидо:", "И что дальше?"),
    ("right", "Бретт:", "Через Python Cookbook попал в сообщество, потом в python-dev."),
    ("left", "Гвидо:", "Быстро втянулся?"),
    ("right", "Бретт:", "Да, начал писать обзоры, отправлять патчи, добавил strptime, стал core-разработчиком в 2003."),
    ("left", "Гвидо:", "Каким было сообщество тогда?"),
    ("right", "Бретт:", "Небольшим, всё держалось на энтузиастах."),
    ("left", "Гвидо:", "А позже?"),
    ("right", "Бретт:", "Участвовал в переходе на Python 3, развитии стандартной библиотеки и управлении."),
    ("left", "Гвидо:", "Самый сложный момент?"),
    ("right", "Бретт:", "Твой уход и кризис управления помогли перейти к другой модели руководства."),
    ("left", "Гвидо:", "В итоге?"),
    ("right", "Бретт:", "Случайно попробовал Python и стал ключевым участником проекта."),
]

print("Нажимайте ENTER (или пробел) для следующего сообщения.\n")

for side, name, text in dialog:
    input()
    print_bubble(text, name, side)

print("\n Вы прочитали краткую версию. Подробнее читайте на https://habr.com/ru/articles/1017676/ \n")

Хотели бы побыть в шкуре чиновника-технофоба, блокирующего в интернете всё, до чего могу дотянуться пухленькие ручки?

Мне показалось это хорошая идея для первоапрельской Telegram Mini App и я написал PZDNET — где гильдии чиновников и общественников борются за максимальное количество блокировок в интернете.

Никакого здравого смысла. Только холодный расчет и нездоровая жажда «регулирования».

Приходи, интернет сам себя не заблокирует.

Оземпик работает не лучше кефирной диеты.

Метаанализ 37 исследований обнаружил, что после отмены GLP-1 люди набирают все обратно (удивительно!) в среднем чуть более чем за полтора года, и что еще хуже, вместе с тем возвращаются и все кардио-метаболические риски (поразительно!! нет, ой, т.е. да). Кароче, подтвердили то, что мы и так знали про все диеты и быстрые способы похудения.

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

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

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

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

Однако последствия у GPL-1 точно такие же, как у любой краш диеты.

Сегодня впервые за 6 лет обновили докер образ MTProxy, версия 2 бета.

Интересно, что-то намечается или нет, но работает так себе в последнее время.

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

Как делать бизнес-процессы как в n8n — безопасно и масштабируемо? Узнаете на конференции GoCloud 2026 ☁️

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

Спикер: Владислав Янковский — старший Go-разработчик, Cloud.ru

Трек: Прикладной ИИ

📅 Когда: 9 апреля в 16:40–17:00 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: NoCode инструменты для создания AI-приложений с RAG: быстрый старт

Потихоньку расскажу, как сильно ускорять тяжёлые обновления 1С. Сегодня - про ускорение отложенных обработчиков.

Чтобы понять, какие обработчики долго выполняются, достаточно обновить копию и посмотреть. В форме выполнения обработчиков прям время будет написано, в днях/часах, сколько выполнялся обработчик. А сколько ему надо было объектов промурыжить - видно в отчёте “Прогресс отложенного обновления”.

Например, у нас сильно тормозил обработчик регистра сведений “РеестрДокументов” - выполнялся больше суток. Ему надо было перезаписать 9 млн. записей (столько в базе было документов).

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

Дальше идём в три процедуры модуля менеджера обновляемого объекта:

1. ПриДобавленииОбработчиковОбновления - там надо будет через расширение отключить добавление обработчика, чтобы типовое обновление его не выполняло. Там же смотрим, какой процедурой регистрируются данные к обработке (свойство ПроцедураЗаполненияДанныхОбновления, обычно там ЗарегистрироватьДанныеКОбработке). Там же смотрим, какой процедурой выполняется обработчик (свойство Процедура, обычно там ОбработатьДанныеДляПереходаНаНовуюВерсию).

2. Процедура регистрации (обычно ЗарегистрироватьДанныеКОбработке). В ней надо забрать запрос, который формирует данные к обработке. Обычно там всё несложно - запрос, выборка результата и его складывание в план обмена (ОбновлениеИнформационнойБазы.ОтметитьКОбработке). Нам нужен только запрос и выборка данных, в план обмена ничего писать не нужно.

3. Процедура выполнения обработчика (обычно ОбработатьДанныеДляПереходаНаНовуюВерсию). Там лежит код обработки. В нём много лишнего (обвес для типовых процедур обновления), но суть обычно понять несложно - читаются данные, сформированные п.2, и что-то с ними делается. Бывает, ещё один-два запроса делаются. Берём вот эту содержательную часть и забираем себе. Не забываем заменить ОбновлениеИнформационнойБазы.ОтметитьВыполнениеОбработки на обычную запись - нам не надо регистрировать обработку в плане обмена.

Дальше нужно написать обработку, которая запустит энное количество ФЗ, каждому скормит массив данных к обработке (из п.2), и ФЗ выполнит адаптированный код из п.3. Мы делали расширение, в него складывали процедуру ФЗ, на входе - массив (обычно это массив ссылок). В процедуре - код из п.3. И обработку внешнюю, в которой мы указываем количество потоков, она выполняет большой запрос из п.2, делит результат на потоки, и запускает кучу ФЗ. И всё.

Контролировать прогресс выполнения можно разными способами. Первый, который я использовал - просто выполнял запрос из п.2. Подавляющее большинство запросов в обработчиках обновления написано так, что возвращают только необработанные данные. Соответственно, их в процессе выполнения становится всё меньше. Но этот запрос может выполняться сильно долго. Потом я сделал несложный регистр сведений, и в каждое ФЗ положил пару строк записи в этот РС - после обработки каждого объекта ФЗ “отчитывалось”, и в регистре было видно общий прогресс.

При наличии нормального объёма ОЗУ запускать такие обработчики можно и в 16, и в 32, и в 48, и даже в 100 потоков (проверено). Это количество ФЗ на один обработчик. А вообще мы в это распараллеливание вывели 22 обработчика из 4 редакций.

Ускорение получается очень существенное - тот, который выполнялся сутки, стал выполняться за 4 часа.

https://t.me/ywhite

TransRussia| SkladTech 2026: системный подход к автоматизации и роботизации. Итоги Выставки

Завершилась выставка TransRussia | SkladTech 2026 (17–19 марта, «Крокус Экспо»). Команда INTEKEY участвовала в деловой программе и общалась с заказчиками, интеграторами и поставщиками.

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

Основные тренды, которые обсуждали эксперты и участники:

🔸 Роботизация как новая норма. Государство целенаправленно ускоряет автоматизацию складов через субсидии, льготы и возможные регуляторные требования. На рынке уже доступно более 30 типов складских роботов, 22 из которых — российского производства.

🔸 Экономика и скорость. Компании жёстко оценивают проекты: ожидаемый срок окупаемости — до 1 года, запуск базового функционала — за месяцы, а не годы. Вырос запрос на предсказуемость работы систем при росте нагрузки.

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

🔸 Коллективное принятие решений. Выбор решений стал более системным: собственник оценивает экономику, IT — архитектуру, а логистика — применимость в операциях. Это снижает количество «теоретически правильных», но плохо работающих проектов.

В рамках сессии «Эволюция склада» Денис Сумелев (INTEKEY) и коллеги из Nikoliers, «Магнита» и КСЛ обсудили, как подготовиться к обязательной роботизации и выстроить процессы для быстрого получения экономического эффекта.
По итогам выставки INTEKEY вошла в топ-3 Product Award 2026 — премии, отражающей практический интерес рынка к представленным решениям.

💬 На что вы в первую очередь смотрите, оценивая проект автоматизации: на срок окупаемости или на функциональность?

Важное событие на российском ИТ-рынке: анонс национальной бесплатной СУБД для всех отраслей экономики

Диасофт приглашает на первую в своей истории конференцию, посвященную промышленной эксплуатации СУБД и архитектуре корпоративных данных – День СУБД 2026.

Конференция пройдет 21 апреля 14:00-23:00 (мск)

Место проведения: Москва, Кибердом

О чем поговорим:

• Изменение подхода к импортозамещению СУБД

• Digital Q.DataBase от «Диасофт“ — настоящий «полиглот» в мире СУБД

• Национальная СУБД для обеспечения технологического суверенитета

• Импортозамещение СУБД в высоконагруженных системах

• Истории успеха перехода на Digital Q.DataBase клиентов и партнеров «Диасофт»

• Сотрудничество с высшими учебными заведениями

Регистрация и программа мероприятия доступны по ссылке

Канал коммуникации напрямую влияет на выручку: где пользователю удобно оставить заявку, там и происходит конверсия. Поэтому мы используем MAX как вынужденную альтернативу Telegram для приема заявок. В посте расскажем, как сделали бота для MAX, чтобы не терять клиентов без VPN. 

Мы делаем мини-аппы и ботов для разных платформ — VK, Telegram, MAX. Оперативно собрали бота в MAX как еще одну точку входа в воронку.
Сценарий привычный:

• пользователь попадает в бота по ссылке;

• оставляет контактную информацию;

• заполняет бриф;

• прикладывает документы и материалы;

• заявка уходит в CRM и живёт своей обычной продуктовой жизнью.

Мы взяли проверенную логику Telegram-бота и перенесли её в MAX:

• адаптировали под API платформы;

• учли UX-паттерны;

• сохранили тот же пайплайн обработки.

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

Зачем нам бот в MAX?

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

Отправьте заявку: max.ru/id6670505625_bot
Свяжитесь с нами — мы разработаем мини-аппы или ботов под вашу задачу с нуля, быстро перенесем работающие решения на новую платформу.

Не пропусти МТС True Tech Hack 2026 — регистрация заканчивается ⏰

Используй последнюю возможность иницИИровать свое будущее: присоединяйся к соревнованию, придумай нестандартное решение и разработай демоверсию ИИ-продукта.

В программе:

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

• Приглашение на закрытую вечеринку с диджеем в Москве на видовой площадке и мерч в подарок — для всех финалистов.

• Для лучших участников — возможность попасть на стажировку.

Эксперты готовы оценить твое ИИ-решение — выбирай, над чем будешь работать:

1. GPTHub: единое окно для всех задач искусственного интеллекта. Мультимодальный чат на OpenWebUI, который сам подбирает модель под задачу и сохраняет контекст.

2. LocalScript: локальная агентская система для генерации Lua-кода на легкой языковой модели (LLM) для работы в условиях ограниченных ресурсов без отправки данных во внешние сервисы.

3. WikiLive: живые таблицы в тексте. Единое пространство для документации, командной работы и управления знаниями. 

Призовой фонд соревнования — 1 500 000 рублей.

Успей зарегистрироваться до 18:00 9 апреля.

Приглашаем на встречу о профессии «Инженер в области искусственного интеллекта»!

• Где сегодня проходит граница между научным исследованием и прикладным программированием в области ИИ?

• С какими вызовами сталкиваются лаборатории при обучении моделей-гигантов?

• Какую роль в карьере играет академический бэкграунд?

• Как устроена жизнь внутри университетских R&D-центров и чем она отличается от разработки в коммерческих ИТ-гигантах?

Обо всём этом в эту субботу расскажет Виталий Пирожников, руководитель лаборатории искусственного интеллекта в «Криптоните», вместе с представителями других компаний!

Где: в Музее криптографии (Москва, улица Ботаническая, дом 25, строение 4) Когда: 4 апреля, суббота, начало в 15:00 Как попасть: посещение встречи бесплатное. Нужно только зарегистрироваться по ссылке.

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

А какой у тебя RPG-класс? Пройди наш квиз, чтобы узнать :)

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

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

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

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

Разбираемся в уязвимости типа Open Redirect

Перенаправления — это механизм, с помощью которого сервер указывает клиенту (например, веб-браузеру) необходимость перейти на другой URL. Они являются стандартной частью протокола HTTP и используются для управления трафиком между веб-сайтами.

Чем опасно открытое перенаправление:

• Позволяет проводить фишинговые атаки;

• Используется для эксплуатации уязвимостей браузеров и плагинов;

• Способствует распространению вредоносного контента и дезинформации.

➡️ В этом видео Денис Данилов, инженер по безопасности приложений Swordfish Security, рассказывает, как защититься от этой уязвимости. Эксперт объясняет, какие подходы использовать на сервере, чтобы исключить риск, а также показывает реальный пример эксплуатации, когда злоумышленник может обмануть пользователя, даже если сайт выглядит безопасным.

GTD в современных реалиях: как работать с большими задачами

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

Дело в том, что это вообще не задачи.

Проект как базовая единица

Если задача не решается за одно действие — это уже проект.

Проект в GTD — это цель с конечным состоянием, достигаемая через цепочку шагов.

Ключевое отличие проекта от операционной деятельности — конечность.

И здесь большинство делает первую ошибку: начинают что-то делать, не определив, где «финиш».

Примеры критериев завершения:

• дом к проживанию и комфортному существованию семьи;

• ипотека одобрена банком и подписаны необходимые документы;

• произошла официальная регистрация брака.

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

Ошибка «вечного проекта»

Распространённая иллюзия: «разберусь по ходу». На практике это означает отсутствие точки остановки и отсутствие понимания чего я хочу от этой активности.

Но есть и ещё одна крайность — пытаться заранее продумать условия «провала». Это выглядит рационально, но чаще превращается в прокрастинацию под видом планирования. Реальность проще: неактуальные проекты умирают сами — через отсутствие движения. Если вы неделями к нему не возвращаетесь, это уже сигнал, что проект неактуален и его нужно либо перенести в потомки (когда-нибудь потом), либо закрыть и удалить.

План не так важен, как кажется

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

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

Первое действие — точка запуска

Большие проекты тормозятся не из-за сложности, а из-за неопределённости старта.

«Не знаю, с чего начать» — это реальная причина прокрастинации.

Решение примитивное и поэтому часто игнорируется:

определить минимальное действие, которое сдвинет ситуацию с нуля.

Чаще всего это:

• погуглить;

• спросить того, кто уже проходил этот путь.

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

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

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

Но это поверхностное понимание.

Ключевая идея не в дроблении, а в управлении неопределённостью:

• сначала фиксируется чёткий критерий завершения;

• затем определяется ближайшее осмысленное действие;

• всё остальное появляется по мере движения.

Если этого нет — никакая система не спасёт. Будет лишь аккуратно разложенный по папочкам и спискам хаос.

И да, GTD не решает проблему выбора целей. Она лишь помогает не утонуть в процессе их достижения.

Apple представила Swift Hypertext UI для вайбкодеров.

SwiftHUI новый декларативный язык разметки интерфейсов для iOS и macOS.

Никакого Swift. Никакого Xcode. Просто описываешь интерфейс словами.

vstack spacing=20
  text font=title "Hello, Vibe!"
  button action=tap "Do the thing"
/vstack

Переход на SwiftHUI будет безболезненным — вы уже умеете читать.

Apple позиционирует SwiftHUI как следующий шаг после SwiftUI: меньше кода и зависимости от инструментов. Работает даже в заметках.

Wireshark: установка, фильтры и разбор реальных сценариев

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

В блоге разобрали инструмент с нуля: установка на Windows, Linux и macOS, работа с интерфейсом, фильтры захвата и отображения, практические сценарии — от отладки медленного соединения до анализа VoIP-звонков.

Читайте полный разбор на сайте SpaceWeb.