Pull to refresh
8K+
368
Alex Efros@powerman

Software Architect, Team Lead, Lead Go Developer

-0,2
Rating
208
Subscribers
Send message

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

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

Зато их не соблюдает сам РКН. Будет забавный юридический казус, если подать в суд на Apple за то, что они выполняют незаконные требования РКН. Подать в западный суд, разумеется. И посмотреть, как в том суде РКН будет обосновывать требования удалять VPN клиенты и что конкретно они нарушили по текущему законодательству РФ.

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

Повторюсь - я сам так делаю, но считаю что это неправильно и учить такому не стоит.

Эта позиция (в отношении других вещей) мне хорошо понятна. Более того, я примерно из этих соображений несколько раз пытался освоить Ansible, да и на все альтернативы смотрел - те, которые Вы упомянули плюс ещё Terraform. И хотя я в основном всё-таки архитект и программист, но у меня хватает и админского опыта: начинал со слаквари в 94-м, в 2001 даже сделал собственный дистрибутив линуха на базе LFS и поддерживал его года 2.5 примерно, после этого перешёл на Gentoo, которым пользуюсь до сих пор. И я прекрасно понимаю всю пользу IaC. Но если при таком бэкграунде, многолетнем желании внедрить IaC, и нескольким подходам к существующим инструментам, я этого так и не сделал - возможно дело не во мне (моей лени или безграмотности), а в том, что существующие инструменты действительно не подходят для такой задачи и целевой аудитории "не профессиональный админ"?

Кроме того, даже если так делать неправильно, может всё-таки лучше так, чем никак (настраивать ручками без IaC)? У этого подхода довольно узкая область применимости - но я вроде бы честно и чётко её в статье обозначил. И если ни я ни Вы не взяли Ansible, а делаем так - почему "плохо" про это честно написать? От того, что про этот подход все будут стыдливо молчать - что изменится к лучшему? У меня вот управление серверами с ним однозначно стало лучше - IaC вполне рабочий получился, с IaC и документацией стало на порядок лучше, чем без них. Почему про это плохо рассказывать и подталкивать внедрять IaC хотя бы такими, колхозными методами?

Проблема со своими скриптами

Эта проблема касается только bootstrap.sh, а он минимален. Да, надо поставить докер и настроить ssh - но это плюс/минус всё, и поддерживать этот набор не сложно. Да и новые сервера в концепции "пара личных" появляются не часто. Всё это по-прежнему сильно проще, чем разбираться с Ansible (который, к слову, тоже постоянно развивается, меняется, и его конфиги скорее всего тоже через пару лет нужно адаптировать к текущей версии ансибла - так что размен такой себе).

Я храню в keepass. И на серверах пишу в конфиги руками если нужно.

Ну, свои (личные, а не которые для серверов) я тоже в Keepass держу. Но писать в конфиги сервера ручками - это ломает перевыкат сервера "одной кнопкой", разве нет? Как Вы этот подход с тем же Ansible совмещаете?

Если ключ шифрования скомпрометирован, то даже если вы его смените и перешифруете секреты - предыдущие коммиты доступны со старым ключом.

Если ключ скомпрометирован, то нужно сменить все защищённым им секреты. В любом случае, вне зависимости от того, где они хранились, и доступны ли старые коммиты - разве нет?

Разделения доступа нет - это только для одного человека с одним ключом.

Ну, технически fnox всё это умеет, и пригоден даже в enterprise. Но практически, для заявленной задачи "до 5 личных серверов" разделение доступа явно лишняя фича.

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

Chef/Puppet/Salt/Ansible/etc. В зависимости от масштабов. А писать свои скрипты - это несерьёзно.

Ну я вот пытался внедрить Ansible на протяжении многих лет. Не идёт. Слишком сложно для таких масштабов, как у меня. Поэтому заставить себя не просто почитать его доку и немного поиграться, а начать использовать полноценно у меня просто не получалось. А Ansible - это лучшее из всего упомянутого.

Поэтому не вижу ничего плохого в одном тривиальном скрипте, который вполне соответствует масштабу задачи, и позволил мне таки перейти на IaC. Да, пытаться колхозить скрипт для решения этой задачи на тех масштабах, где уже нужно использовать Ansible - дурная идея. Но туда тащить этот подход я и не предлагал.

Хранить секреты в git - я этого вообще не понимаю, ну да бог вам судья, у каждого свой подход.

fnox позволяет держать секреты где угодно. Но, мне просто интересно, а где Вы предлагаете хранить секреты для пары личных серверов? И чем, на Ваш взгляд, мой вариант принципиально отличается от Ansible Vault?

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

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

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

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

Значит, или я плохо мысль изложил, или Вы что-то своё в ней увидели. Я никогда не говорил и не подразумевал ничего положительного в вайб-кодинге. Не для программистов, по крайней мере - я допускаю, что для бизнесмена ставить задачу что программисту (и получать в результате код, который бизнесмен не понимает) что ИИ (и получать ровно то же самое) - одна фигня и в таком качестве вайб-кодинг может иметь своё применение. Но программист обязан понимать код, который он коммитит в репо, и отвечать за него.

с каким-то что ли сарказмом говорите, вы же "ведущая"

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

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

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

Возможно Вы удивитесь, но с разными моделями ИИ - ровно та же фигня!

коллегу не нужно вводить в контекст, он работает там же где ты

При качественном AGENTS.md и хорошими моделями (уровня не ниже Claude Sonnet, а лучше Opus) это работает практически точно так же.

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

Так было. Но было это, по меркам скорости развитии ИИ-агентов, - очень давно! Сейчас это решил AGENTS.md для проекта в целом плюс дополнительные аналогичные файлы правил для отдельных-специфичных областей проекта, если проект достаточно сложный или просто большой. AGENTS.md добавляется автоматически всегда, дополнительные правила изредка нужно одно-два (про нужную часть проекта и про нужный тип задач) добавить в чат ручками, в зависимости от текущей задачи.

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

А вот это как раз то место, где становится критичен Ваш личный опыт и донесение его до ИИ в промпте. Если этого не делать, то ИИ примет решения уровня среднего миддла, и количество несогласованного кода в проекте только вырастет. Но при работе с командой из тех же миддлов результат будет ровно такой же, и придётся всё-равно либо доносить свой опыт в процессе ревью PR либо мержить как есть.

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

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

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

Когда я работаю сама, мне не нужно

Это правда. Но когда Вы работаете в команде (Вы же лид, ведущий - кого Вы "ведёте" если работаете в одиночку?) то всё, что Вы описали как "проблему работы с ИИ", ровно так же проявляется при работе с коллегами! И да, это совсем другой флоу. Но в одиночку много не наработаешь, к сожалению.

Мне лично писать код нравится, нравится состояние потока

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

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

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

я пока не готова отказаться от своего опыта 🤷‍♀️

И не нужно отказываться. Качество того, что ИИ выдаёт самостоятельно - очень и очень средненькое. И вряд ли станет лучше без какого-то принципиального изменения в подходах к обучению ИИ - потому что обученный на всём доступном коде ИИ не различает где код хороший а где плохой, считая средний по выборке нормой - а этот средний уровень очень далёк от нормы. Поэтому Ваш опыт - это именно то, что позволяет получать от ИИ результаты Вашего уровня, а не среднего. Описывая свои требования, приоритеты, отношения и подходы в AGENTS.md и промптах конкретной задачи, плюс показывая ИИ текущий код написанный в соответствии с Вашим опытом, Вы и формируете тот контекст, который необходим ИИ чтобы писать код "как Вы", а не как в среднем пишут на этой планете.

Вы как-то не так используете AI.
Может модель слабая (попробуйте Claude Sonnet/Opus).
Может Вы режим агента не включили на полную (чтобы AI за один запрос написал и код, и тесты, запустил линтеры+тесты и исправил все ошибки, и только потом выдал результат на ревью).
Может Вы плохо ставите задачу модели, например не описав достаточно хорошо суть проекта и используемые подходы в CLAUDE.md/AGENTS.md (там должно быть примерно всё то, что выдаётся новичку при онбординге в проект). У Вас в профиле написано "ведущий", значит Вы умеете ставить задачи коллегам - вот ровно так же ставьте задачу и модели.

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

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

А ему это и не нужно. Он определит доступность серверов телеги и внешний IP, после чего траффик к этому внешнему IP забанят предполагая что это VPN (раз телега доступна).

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

Кстати, интересная идея - использовать двух-хоповую настройку VPN: телефон подключается к VPN с IP1, сервер с IP1 роутит трафик через сервер с IP2, в результате в инет трафик отправленный на IP1 выходит с IP2 ⇒ РКН определяет IP2, блокирует трафик к IP2 ⇒ всё продолжает работать.

Проблемы сложности написания кода на сях решаема в масштабах человечества банальным наращиваем экспертизы со временем.

Так о том и речь. Мы наращивали экспертизу в C более 50 лет. И эта экспертиза нам однозначно говорит: ручное управление памятью абсолютно большинство разработчиков не вытягивают. Или Вы предлагаете ещё лет 50 понаращивать, в надежде что что-то изменится? :)

Или KeePass. Он тоже умеет OTP делать. Правда, обычно в нём же и пароль лежит, т.е. это уже не 2FA по сути. Но это можно решить сделав для 2FA отдельную БД и держать её на другом устройстве. Ну или не заморачиваться, если есть уверенность в защищённости основной БД и компа, на котором она используется.

Смешно. А по факту - это война меча и щита. И буквально пару дней назад она меня задолбала и я купил отдельный телефон для таких капризных приложений, потому что у меня уже нет ни времени ни моральных сил пытаться запустить Google Wallet под Magisk+LSPosed+XPrivacyLua не отключая при этом все эти защиты для Google Play Services сотоварищи. Я попытался, оно сходу с минимально допустимыми (для меня) ограничениями не завелось, ну и вот. Может там и получилось бы что-то нашаманить убив на это несколько часов, но не факт. И даже если бы получилось, то не факт, что через несколько недель после очередного обновления оно бы снова не поломалось. Когда я некоторое время назад тестил Safety Net на этом телефоне - всё проходило, но, видать, Google Wallet этого мало.

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

1
23 ...

Information

Rating
Does not participate
Location
Харьков, Харьковская обл., Украина
Date of birth
Registered
Activity

Specialization

Бэкенд разработчик, Архитектор программного обеспечения
Ведущий
From 10,000 $
Проектирование архитектуры приложений
Golang
Linux
Docker
Безопасность сетей
Модульное тестирование
Наставничество
Разработка ТЗ
Разработка программного обеспечения
Высоконагруженные системы