А скажите, отдает ли народ пулл-реквесты на тестирование до мержа? Скажем, я заменил красную кнопочку на 2 зеленые. И хочу показать код код-ревьюеру, а кнопочки — QA, до того, как мержить PR. Такое вообще практикуется?
Если да — то получается что каждую ветку, соответствующую PR, надо куда-то деплоить? Как это выглядит? Ну то есть, в случае обычного аппа можно отдавать собранное в CI приложение. А в случае веба? И как это технически выглядит? Поддомены в DNS прописываются? Или есть пул энвов?
TLDR: оптические сети не интероперабельные. Если провайдер дает вам какое-то говно в качестве CPE -- то заменить его на другое того же стандарта совершенно нет никакой возможности. В отличие например от ADSL, LTE или Ethernet.
В этом плане конечно рулят провайдеры, которые дают вам «лигаси»-решение в виде отдельного говно-медиаконвертера и обычного Ethernet-говнороутера.
Most ONTs run customized firmware which implement vendor and ISP-specific integrations and are locked down in functionality to match service requirements. ONTs often perform differently depending on the OLT and the settings applied by the ISP; for convenience it is often desirable to switch from an external ONT to an SFP or vice-versa, but most OLTs perform so many checks on the ONT that a simple replacement is almost impossible.
В процессе написания MCP-сервера для нужд нашего нетехнического менеджера (он анализирует транскрипты разного рода совещаний) я пришел к выводу, что LLM Tool Call — это такой «очень вычислительно дорогой» акт взаимодействия с внешним миром. Соответственно, в этот акт надо максимально все уместить.
То есть, идеальный флоу для LLM с использованием инструментов такой:
— по промпту сгенерировать внешний запрос
— по вернувшемуся результату запроса + промпту сгенерировать ответ.
Тут мы платим за токены в промпте 2 раза, и по 1 разу за токены вызова, результата и ответа.
А если вы тупо экспортируете API через MCP, то как правило этих «раунд-трипов» надо больше (сгенерировать запрос, по ответу сгенерировать ещё один, ...). Ну и стоимость растет квадратично.
Поэтому надо дизайнить MCP под конкретную вашу задачу, под будущие промпты, минимизируя количество телодвижений. И идеальное количество этих «телодвижений» — нулевое, при котором вы заранее даете все нужные данные модели в промпт через ресурсы, и она никаких инструментов и раунд-трипов не делает, а сразу Вам отвечает.
У нас тут корпоративная подписка на Claude Team Plan. Сделана была в рассчете на то, что нам нужна коллаборация.
Ну, какая-то коллаборация действительно получилась — созданными мной проектами могут пользоваться и реально пользуются другие члены команды. И ещё есть общекорпоративные Remote MCP сервера. Но на этом все «корпоративные» преимущества заканчиваются.
Мораль такова: текущая ситуация, когда компании-разработчики моделей вертикально интегрированы и кроме моделей разрабатывают и инструменты, говно и не нужна. Качество этих самых инструментов так себе.
Вот чуть более подробные жалобы на корпоративную подписку Клода.
Нет возможности совместно чатиться с клодом, подобно совместной работе над гуглодокументом. Даже нельзя в реалтайме смотреть как чатится кто-то другой.
Нет никаких IAM/RBAC. Есть публичные проекты, доступные всем в организации, и приватные, доступные списку пользователей который укажешь. Нельзя дать «всем пользователям группы Х» так как нету самих возможностей группировки пользователей.
Если добавляешь MCP в организацию — он добавляется во все чаты всех проектов, отъедая у этих чатов контекст. Можно отключать, но эти настройки не запоминаются, надо каждый раз повторять. Теперь представьте что у вас 10 источников информации в компании. И галки что включено что отключено надо будет каждый раз прокликивать при создании чата.
Проекты из динамических документов собирать нельзя. Что делает бессмысленной вообще всю эту затею с проектами. В «приватные» проекты (см выше) можно добавлять гуглодоки, и то непонятно, они динамически добавятся (всегда будет свежая версия) или статически (всегда будет версия на момент добавления). Можно было бы разрешить добавлять MCP-ресурсы, но это не сделано — MCP-ресурсы можно добавлять только в сообщения чата, как аплоады.
У тулзов вроде бы ограничение на размер. То есть большие контексты тулзами генерировать нельзя без приседаний (это к дополнению тому что misuse тулз для генерации контекста — приседание само по себе).
Нет какого-либо программного доступа к артефактам, что делает их тоже довольно бессмысленными (можно заменить например редактированием файла через MCP Tools но надо писать превьюер)
Подписку нельзя оплатить банком. Корпоративную. Только картой, и у них почти все наши карты не принимаются. Не хотят они денег.
Чаты, использующие интеграции, нельзя шарить вообще.
Я тут обнаружил что есть 2 режима взаимодействия c LLM:
— запрос сведений и действий, которые ты не знаешь («промпт вверх»)
— запрос сведений и действий, которые ты знаешь («промпт вниз»)
Запросы вверх похожи на гугление. «В каком советском фильме Володька сбрил усы?».
Запросы «вниз» похожи на выдачу заданий подчиненным. «По такому JSON сделай вот такой Markdown».
Интересно, что в кино ИИ позиционируется как находящийся «внизу». Skynet, HAL 9000, спасательная лодка из «С роботами не шутят», робот Вертер.
«Верхние» ИИ довольно редки, в-основном из-за интеллектуального шовинизма («ИИ никагда не заменит живой проститутки») и трудности представить, как оно может оказаться. Мой любимый «Мешок» из одноименного рассказа Моррисона, HAL-образный ИИ из мультика Wall-E.
Так вот, эти два типа запросов требуют разного подхода к решению. И например Клод последних версий (3.5+) строит из себя «верхнего», из-за чего «нижние» поручения выполняет совсем по-наркомански. Пытается писать код на 15 шагов вперёд.
Если ты не знаешь программирования и просишь его сделать тулзу «вверх», то рабочий парсинг командной строки, хоть ты и не просил, выглядит круто. А если знаешь — то он его делает без библиотек и зачастую не в том стиле пишет, что надо, постоянно надо переделывать исходные промпты, уточняя в исходном промпте требования к стилю и библиотекам.
Мы тут занялись измерением латенси от нажатия клавиши до появления ее в терминале. И выяснилось, что во-первых, g действительно 9.8 +- 10%, а во-вторых, что латенси локального cmd в винде.. 50 мс.
Ну то есть 30-50 мс RTT до ближайшего датацентра в Европе меняет картину значительно (больше чем на 10%) но не радикально (не на порядок).
И что сам RDP даже в софт-варианте (без серверной видеокарты) дает минимальный оверхед по сравнению с локальной + сетевой латенси (~12 +- 4 мс дополнительно).
Это же говорит нам, что, в принципе, можно пробовать сделать сверхбыстрый локальный UI с латенси меньше 16 мс (время 1 кадра на 60 Hz) и посмотреть, как оно по ощущениям. Vibe coding, anyone? :D
Несмотря на название, основа этого всего — старые добрые неэкспортируемые приватные ключи на смарт-карте. Только теперь роль смарткарты играет TPM или его мобильные аналоги.
Аналогом PKCS#7 является CTAP2.
Аналогом mutual TLS using PKCS#7 является браузерный WebAuthn API.
В сравнении с PKCS#7 поддерживаются новые сценарии.
Есть концепция Authenticator — это наш PKCS#7 токен, «смарткарта».
Бывают Platform Authenticator и Roaming Authenticator.
Platform Authenticator — это наш Windows Hello/TPM или эппловский FaceID/их чип. Так сказать, смарткарта, встроенная в устройство, где роль пина может исполнять биометрия.
Roaming Authenticator — это более привычный «внешний» по отношению к вашему устройству аутентификатор.
Если вы мальчик-дебил, то для вас Platform Authenticator - это просто более безопасный способ запомнить пароль на устройстве. Идея в том, что Roaming Authenticators нинужны, и 90% пользователей достаточно просто прибивать их пароль от етуба с котиками к устройству.
Ирония тут в том что, во-первых, SSH-ключи сохранять таким образом нельзя, а во-вторых, что как раз етуб все равно запоминает состояние залогированности лигаси-методом.
Так что польза от Platform Authenticator сомнительная, и кроме того, при отсутствии какого-либо лигаси или Roaming authenticator непонятен процесс энроллинга/бутстрепа, первоначальной генерации кредов аутентификатором.
Наиболее логичной выглядит схема с «холодным» Roaming Authenticator, который мы подключаем ко всем нашим устройствам для их энроллинга.
5. Включаете SSH Agent Forwarding в PuTTY и заходите на любой линукс (если есть лигаси-ключи их прямо в pageant добавляем вместе с нашим CAPI key 6. ssh-add -L | grep CAPI показывает наш ключ в формате SSH без необходимости пресловутой ебли с DER. Его прямо можно делать ssh-add localhost или копировать из терминала в другие места.
7. При коннекте к серверу, который узнаёт наш key fingerprint - это важно - открывается окно с пинкодом. Левые сервера, которым ключи, лежащие в TPM, не нужны - не открывают.
8. Пишет Authenticating with public key "CAPI:фингерпринт"
9. PROFIT!
Ключ лежит не в pageant, а в виртуальной смарткарте, заимплеменченной поверх TPM. Хез, насколько это сесюрно в результате. RSA2048 делается по дефолту, ничего лучше, чем дефолт, приседаниями не сделать. Ну и MS вроде бы убила эти виртуальные смарткарты в win11, и TPMv2 их не поддерживает даже в Win10. Но я поищу решение, у меня на ноуте с разбиванием об колено как раз TPMv2.
Upd:
1. С TPMv2 тоже работает. 2. Внезапно интерфейс управления ключами находится.. внутри putty-cac в разделе certificates. 3. Пробрасывается в сесии RDP по аналогии с SSH Agent.
