За 15 лет с Linux я понял одну неприятную вещь: **часть настроек нужна была не системе, а моему ощущению контроля**.
Когда-то я тоже жил по схеме: i3, polybar, тонкая настройка `vimrc`, скрипты на каждый чих, автопереключение всего при подключении монитора. Это выглядит как инженерная дисциплина, но часто превращается в отдельный проект по обслуживанию рабочего места.
Сейчас у меня Fedora почти без кастомизации: GNOME, браузер, редактор, видео для демо — и всё работает. Не идеально в эстетическом смысле, зато предсказуемо.
Это очень похоже на типовой битриксовый проект: можно собрать архитектуру из десятка самописных надстроек, а потом годами поддерживать саму обвязку. А можно оставить только то, что реально влияет на бизнес\-процесс, и не трогать лишнее.
__Антиошибка недели__: не путать удобство с количеством настроек.
Иногда лучший `тюнинг` — это убрать тюнинг.
Когда-то я тоже жил по схеме: i3, polybar, тонкая настройка `vimrc`, скрипты на каждый чих, автопереключение всего при подключении монитора. Это выглядит как инженерная дисциплина, но часто превращается в отдельный проект по обслуживанию рабочего места.
Сейчас у меня Fedora почти без кастомизации: GNOME, браузер, редактор, видео для демо — и всё работает. Не идеально в эстетическом смысле, зато предсказуемо.
Это очень похоже на типовой битриксовый проект: можно собрать архитектуру из десятка самописных надстроек, а потом годами поддерживать саму обвязку. А можно оставить только то, что реально влияет на бизнес\-процесс, и не трогать лишнее.
__Антиошибка недели__: не путать удобство с количеством настроек.
Иногда лучший `тюнинг` — это убрать тюнинг.
Один из показательных эффектов LLM-петли: если оставить две модели общаться друг с другом без внешней рамки, разговор быстро уезжает от смысла к самоподтверждению.
Я у себя в проектах это называю **антиошибкой автоматизации**: система начинает не решать задачу, а _обслуживать собственный ответ_. В исходном кейсе из такой «свободной беседы» сначала вырос сырой концепт `рефлексивного ядра`, а позже — уже более любопытная идея про `мета-внимание`.
Схема простая:
`вопрос` → `ответ модели` → `ответ на ответ` → `усиление внутренней логики` → потеря внешней привязки.
Для 1C-Битрикс это очень знакомый паттерн. Тот же эффект ловится в чат-ботах, автогенерации контента, помощниках для саппорта и даже в интеграциях, где нет жесткого контроля контекста. Если не задать ограничения, модель начинает красиво, но бесполезно «докручивать» сама себя.
Вывод практический: LLM нужна не свобода, а _границы, проверка и внешний якорь_. Иначе вместо архитектуры получаем самореференсный шум.
Я у себя в проектах это называю **антиошибкой автоматизации**: система начинает не решать задачу, а _обслуживать собственный ответ_. В исходном кейсе из такой «свободной беседы» сначала вырос сырой концепт `рефлексивного ядра`, а позже — уже более любопытная идея про `мета-внимание`.
Схема простая:
`вопрос` → `ответ модели` → `ответ на ответ` → `усиление внутренней логики` → потеря внешней привязки.
Для 1C-Битрикс это очень знакомый паттерн. Тот же эффект ловится в чат-ботах, автогенерации контента, помощниках для саппорта и даже в интеграциях, где нет жесткого контроля контекста. Если не задать ограничения, модель начинает красиво, но бесполезно «докручивать» сама себя.
Вывод практический: LLM нужна не свобода, а _границы, проверка и внешний якорь_. Иначе вместо архитектуры получаем самореференсный шум.
В начале июня я снова увидел старую картину: массово начали сбоить не только самодельные обходы, но и решения на связке `xray + VLESS + REALITY`.
С инженерной точки зрения это выглядит как _волна ограничений_, а не как единичная ошибка у провайдера. Когда ломается сразу несколько независимых реализаций, обычно проблема сидит не в клиенте и не в одном сервере, а в **логике фильтрации на стороне сети**.
Что важно для нас, интеграторов и админов: такие вещи редко чинятся «обновите конфиг». Нужно смотреть на схему целиком — точки выхода, TLS-поведение, последовательность рукопожатий, устойчивость к активной проверке.
Я бы описал это так: сначала система пропускает привычный трафик, потом начинает выборочно резать подозрительные паттерны, и уже после этого ломаются даже аккуратно собранные связки. Типовой кейс из инфраструктуры, где ограничения идут не в лоб, а по признакам.
Если у вас в проекте завязано что-то критичное на нестандартных каналах связи, держите план Б. И да, проверяйте не только «работает/не работает», а __почему__ именно отвалилось. Это экономит часы на бесполезной переборке конфигов.
—
Чтобы быть в курсе рынка — подпишись на @affcareers_spb
С инженерной точки зрения это выглядит как _волна ограничений_, а не как единичная ошибка у провайдера. Когда ломается сразу несколько независимых реализаций, обычно проблема сидит не в клиенте и не в одном сервере, а в **логике фильтрации на стороне сети**.
Что важно для нас, интеграторов и админов: такие вещи редко чинятся «обновите конфиг». Нужно смотреть на схему целиком — точки выхода, TLS-поведение, последовательность рукопожатий, устойчивость к активной проверке.
Я бы описал это так: сначала система пропускает привычный трафик, потом начинает выборочно резать подозрительные паттерны, и уже после этого ломаются даже аккуратно собранные связки. Типовой кейс из инфраструктуры, где ограничения идут не в лоб, а по признакам.
Если у вас в проекте завязано что-то критичное на нестандартных каналах связи, держите план Б. И да, проверяйте не только «работает/не работает», а __почему__ именно отвалилось. Это экономит часы на бесполезной переборке конфигов.
—
Чтобы быть в курсе рынка — подпишись на @affcareers_spb
В проектах я часто вижу одну и ту же ошибку: люди недооценивают то, что «и у нас под боком не страшно». С живой природой это работает плохо.
Подборка про пауков европейской части России напомнила мне простой принцип архитектуры: __не ориентироваться на внешний вид__. Каракурт, тарантул, сольпуга и их менее известные соседи выглядят по-разному, но в задаче безопасности у них одна логика — держать дистанцию и не проверять на практике, кто из них «на самом деле неопасный».
В техподдержке и в проектах я бы сказал так: если объект системы помечен как рискованный, не пытаемся «быстро посмотреть руками». Сначала идентификация, потом регламент, потом действия. Иначе получаем лишний инцидент там, где можно было обойтись без него.
С природой, как и с интеграциями, лучше работает сухой подход: __сначала понять, потом трогать__.
Подборка про пауков европейской части России напомнила мне простой принцип архитектуры: __не ориентироваться на внешний вид__. Каракурт, тарантул, сольпуга и их менее известные соседи выглядят по-разному, но в задаче безопасности у них одна логика — держать дистанцию и не проверять на практике, кто из них «на самом деле неопасный».
В техподдержке и в проектах я бы сказал так: если объект системы помечен как рискованный, не пытаемся «быстро посмотреть руками». Сначала идентификация, потом регламент, потом действия. Иначе получаем лишний инцидент там, где можно было обойтись без него.
С природой, как и с интеграциями, лучше работает сухой подход: __сначала понять, потом трогать__.
Типовой кейс из проекта: приходит запрос «сделайте так, чтобы Telegram просто работал, а не объясняйте мне, что такое Zapret и TgWsProxy». И вот тут любая ручная схема быстро превращается в батники, конфиги, консоль и звонки в поддержку.
Показали GUI-обёртку, которая закрывает эту боль почти полностью: она сама ставит нужные компоненты, подхватывает настройки, следит за состоянием и обновляется без участия пользователя. По сути, это попытка собрать `one click`-эксплуатацию там, где обычно живёт набор костылей.
С архитектурной точки зрения мне нравится не сам GUI, а идея убрать человека из цепочки регулярного обслуживания. Для инфраструктурных утилит это часто важнее красивой панели. И да, даже ритм-игра там есть — видимо, чтобы обновления проходили веселее 🙂
Показали GUI-обёртку, которая закрывает эту боль почти полностью: она сама ставит нужные компоненты, подхватывает настройки, следит за состоянием и обновляется без участия пользователя. По сути, это попытка собрать `one click`-эксплуатацию там, где обычно живёт набор костылей.
С архитектурной точки зрения мне нравится не сам GUI, а идея убрать человека из цепочки регулярного обслуживания. Для инфраструктурных утилит это часто важнее красивой панели. И да, даже ритм-игра там есть — видимо, чтобы обновления проходили веселее 🙂
Иногда лучший способ «сделать асинхронно» — не городить два режима, а честно сломать совместимость и переписать всё под один контракт. В проектах на Битриксе я такую логику вижу регулярно: сначала добавляют второй путь «на всякий случай», потом растёт матрица тестов, усложняется поддержка, а выигрыш в производительности съедается зоопарком исключений.
Типовой кейс из проекта: был модуль интеграции с CRM, где часть вызовов шла синхронно, часть — через очереди и агентов. В итоге отладка занимала больше времени, чем сама обработка. После перевода на единый сценарий — один вход, один формат ответа, один слой ошибок — код стал короче, а поддержка предсказуемее.
Схема простая:
инициатор → единый обработчик → очередь/фоновая задача → запись результата → уведомление.
Мой вывод сухой, но практический: если архитектура уже расползается на «старый» и «новый» режимы, почти всегда стоит сначала считать не throughput, а стоимость поддержки. В enterprise это часто важнее. ⚙️
Типовой кейс из проекта: был модуль интеграции с CRM, где часть вызовов шла синхронно, часть — через очереди и агентов. В итоге отладка занимала больше времени, чем сама обработка. После перевода на единый сценарий — один вход, один формат ответа, один слой ошибок — код стал короче, а поддержка предсказуемее.
Схема простая:
инициатор → единый обработчик → очередь/фоновая задача → запись результата → уведомление.
Мой вывод сухой, но практический: если архитектура уже расползается на «старый» и «новый» режимы, почти всегда стоит сначала считать не throughput, а стоимость поддержки. В enterprise это часто важнее. ⚙️
В проектах с 1C-Битрикс я регулярно вижу один и тот же паттерн: систему пытаются «закрыть» не логикой, а набором жёстких правил. Права, статусы, кодовые поля, ручные согласования — и всё это должно работать без права на ошибку.
Почти как старый советский кодовый замок: внешне простой, внутри — грубая и надёжная механика. Нажал не ту комбинацию — прохода нет. Сломать сложно, обслуживать неудобно, но если всё собрано правильно, оно переживает десятилетия.
В Битриксе так же живут многие интеграции:
схема одна, а нагрузка и точки отказа — в деталях.
Если не продумать кеш, права доступа и сценарии обновления, «суровая» система внезапно начинает тормозить, дублировать данные и ломаться на пустяках.
Из практики: самые живучие решения — не самые красивые, а те, где заранее описаны исключения. Архитектура без этого быстро превращается в кодовый замок, к которому потеряли инструкцию 🔧
Почти как старый советский кодовый замок: внешне простой, внутри — грубая и надёжная механика. Нажал не ту комбинацию — прохода нет. Сломать сложно, обслуживать неудобно, но если всё собрано правильно, оно переживает десятилетия.
В Битриксе так же живут многие интеграции:
схема одна, а нагрузка и точки отказа — в деталях.
Если не продумать кеш, права доступа и сценарии обновления, «суровая» система внезапно начинает тормозить, дублировать данные и ломаться на пустяках.
Из практики: самые живучие решения — не самые красивые, а те, где заранее описаны исключения. Архитектура без этого быстро превращается в кодовый замок, к которому потеряли инструкцию 🔧
Типовой кейс из проекта: на Android-устройстве в enterprise-сценарии «просто сто́р» внезапно начинает жить собственной жизнью — фоновые установки, телеметрия, постоянные запросы к системным данным. В коде это обычно выглядит как набор привычных для интегратора паттернов: сервисы, AIDL, локальная SQLite, пуш-команды, JNI-обвязка и отдельный слой мониторинга.
Для разработчика Битрикс здесь важен не сам скандал, а схема риска: любое приложение с широкими правами на устройстве становится точкой сбора данных и потенциальным каналом доставки кода. Если у вас корпоративный контур, MDM, VPN, SSO и мобильные клиенты 1C-Bitrix, надо смотреть не только на API, но и на то, что стоит рядом в ОС.
Антиошибка недели: считать, что «официально предустановлено» значит «контролируемо». В мобильной архитектуре доверие не даётся по умолчанию — его проверяют ревизией прав, сетевых вызовов и фоновых сервисов. 🔍
Для разработчика Битрикс здесь важен не сам скандал, а схема риска: любое приложение с широкими правами на устройстве становится точкой сбора данных и потенциальным каналом доставки кода. Если у вас корпоративный контур, MDM, VPN, SSO и мобильные клиенты 1C-Bitrix, надо смотреть не только на API, но и на то, что стоит рядом в ОС.
Антиошибка недели: считать, что «официально предустановлено» значит «контролируемо». В мобильной архитектуре доверие не даётся по умолчанию — его проверяют ревизией прав, сетевых вызовов и фоновых сервисов. 🔍