А почему просто не сериализовать на клиенте? Сериализация намного проще шифрования. Шифрование вообще избыточно в этом случае, ведь данные в любом случае передаются "в открытую" вначале. На мой взгляд, это уже сильный оверхед только ради красивой документации. При медленном интернете (что особенно актуально сейчас) это будет боль...
Вы серьезно? Человек говорит о том, что ВСЕ нейронки так или иначе галлюцинируют. Это особенность из архитектуры. Они же просто предсказывают токены, даже не понимая сути вопроса и своего ответа
Ещё странно, что автор делает str(some_bytes.decode()). Ведь decode возвращает строку)) это, конечно, с парсингом тайтла для получения никнейма вообще не сравнится по странности, но тоже не заметку: так делать не надо
Кстати, а чем хорош iTerm? У меня недолгое время был довольно старый мак эир, 13-го года. Я довольно часто пользовался терминалом, но никаких прелестей не почувствовал. Вот теперь сижу думаю, что я что-то важное упустил))
Так я говорю: создайте свой cat. У него будет идентичное название и идентичный способ использования. Когда ИИ будет вызывать "bash -c cat filename.txt", он на самом деле будет вызывать не встроенный cat, а вашу реализацию. И теперь смотрите, какая магия. Если файл превышает заданное ограничение на размер, команда, которая выглядит и вызывается точно так же, как падает с вашей кастомный ошибкой: "file too large. Please use 'cat filename.txt START:END'". То есть код ошибки сразу же подсказывает ИИшке правильное использование команды. Второй пример: ИИ пытается использовать sed. Но для sed у вас своя реализация, который на любой вызов говорит: "sed is not supported. Please use git patch". ИИ сразу вспоминает, что нужно использовать. А для docker/npm/etc. так же будет своя реализация, которая просто является алиасом: она перехватывает все аргументы, переданные ИИ, и вызывает реальную команду. Таким образом, у вас будет собственный клиентский шелл для ИИ, изменяющий поведение УЖЕ СУЩЕСТВУЮЩИХ команд, с ПОЧТИ ИДЕНТИЧНЫМ API. Вот что я имел ввиду. Если нужны подробности, предлагаю перейти в ЛС, а то эта ветка совсем разбухнет))
Да не потому, что ИИ сгенерировано. А потому, что сгенерировано бездумно. Нет нормальных раскрытых примеров, нет подробностей, нет КОНКРЕТИКИ. ИИ никогда конкретику не сгенерирует. Это отличительная черта таких бездумных статей. Когда конкретика будет, будут плюсы
Не совсем)) Вы же говорите, что ИИ читает текст через cat вместо вашего инструмента. Так что мешает подменить реализацию самого cat? Просто сделайте его своим инструментом) тогда даже инструкций для ИИ не нужно будет писать
Так же можно сделать и с остальными командами. Запретить ей писать в файлы в обход патчей на уровне middleware шелла - и все проблемы, описанные в статье, решатся (на мой взгляд)
Я бы не давал полный доступ ИИшке к шеллу. Вместо этого создал бы обёртку над bash. В этой обёртке есть разрешенные команды-алиасы. На некоторые требуется подтверждение, на некоторые - нет. Это и будет набором инструментов, только которые интуитивно понятны системе. Если ИИ пытается выполнить `cat largefile.txt` - выдаётся ошибка "файл слишком большой. Укажите диапазон в формате старт:стоп", или что-то подобное. Команд для записи просто не должно быть - всё через патчи. На npm/TS/RS/PHP/docker/yarn и т.д. будут "прозрачные" алиасы без подтверждений. Или с подтверждением. На остальные команды писать "permission denied" или "unsupported in this project"
Получится как middleware для шелла. Полная изоляция, абсолютно интуитивное управление. Можно будет сколько угодно инструментов впихнуть. Попробуйте :)
Не согласен. LLM читает быстро, но поверхностно. Если Вы про контекстное окно, то оно забивается очень быстро, после чего LLM забывает всё больше фактов и путается. Если же Вы про обучение, то тут механизм другой. LLM предсказывает наиболее вероятные токены. Так как на просторах гитхаба и в статьях очень много довольно старого материала, логично, что старые фичи будут казаться LLM более вероятными в использовании. А информации по новым фичами действительно недостаточно, т.к. для обучения нужно большое количество примеров
Когда человек читает, он ассоциирует текст со своим опытом. У LLM, увы, нет опыта. В этом принципиальная разница. Поэтому человеку так сложно запомнить что-то большое. И поэтому человек может разобраться в чем-то по-настоящему глубоко
Почему люди создали SPA? Потому что глупо загружать каждый раз одни и те же элементы: хедер, футер, меню и т.д. Кэширование страдает от того, что всё в едином HTML. Но зачем всё так переусложнять, если можно:
Рендерить базовый Layout с шапкой и футером
Внутрь Layout добавить банальный iframe
Менять src у iframe в зависимости от нажатой кнопки в меню
При этом страницы можно писать на любом фреймворке. Они абсолютно независимы. Основная страница в браузере лишний раз не перезагружается, перезагружается только iframe. В чем проблема такого подхода?))
P.S. я конечно немного утрирую. Но ведь помимо этого существует ещё море более лёгких решений, чем SSR с гидратацией и тому подобное
Видимо, это были не те собесы. Как раз таки то, что ты понимаешь, где конкретно нужны данные технологии, делает из тебя специалиста. Думаю, если на собесе дадут задачу написать хелло ворлд, а кандидат пойдет собирать проект на Next.js, его не примут))
Самое банальное, что тут можно вспомнить - бесконечная загрузка при ошибке
Если подумать, то это реально потенциальный источник багов, т.к. мы вручную управляем состоянием, переносим ответственность за это во фронтенд. Но, в большинстве случаев, это оправдано: "нафига мне тащить поддержку какого-нибудь SSE, если у меня всего один тяжёлый запрос"
Многие спрашивают, где коды Грея применяются. Приведу простейший пример:
Задача скрейпинга отзывов с Амазона. Так как вывод ограничен всего 10-ю страницами, в ход идёт перебор фильтров. То есть мы просто поочередно перебираем все фильтры, затем уникьюлизируем результаты
Но вот проблема: при изменении одного фильтра страница перезагружается. При переборе фильтров в цикле получилось бы очень много лишних перезагрузок, т.к. за 1 итерацию мы меняем сразу несколько фильтров. Так как у меня в тот момент была гонка с другим программистом в этой задаче, я стал думать, как это оптимизировать. И придумал собственный "цикличный код Грея" (на тот момент я даже не знал о существовании такого). Я добился того, что на каждой итерации я изменяю ровно 1 фильтр, но перебираю все значения
А почему просто не сериализовать на клиенте? Сериализация намного проще шифрования. Шифрование вообще избыточно в этом случае, ведь данные в любом случае передаются "в открытую" вначале. На мой взгляд, это уже сильный оверхед только ради красивой документации. При медленном интернете (что особенно актуально сейчас) это будет боль...
А в чём смысл писать "клонируй проект ..., установи через ...", если в консоли есть автокомплит?))
Вы серьезно? Человек говорит о том, что ВСЕ нейронки так или иначе галлюцинируют. Это особенность из архитектуры. Они же просто предсказывают токены, даже не понимая сути вопроса и своего ответа
Согласен, это жесть какая-то
Ещё странно, что автор делает str(some_bytes.decode()). Ведь decode возвращает строку)) это, конечно, с парсингом тайтла для получения никнейма вообще не сравнится по странности, но тоже не заметку: так делать не надо
Кстати, а чем хорош iTerm? У меня недолгое время был довольно старый мак эир, 13-го года. Я довольно часто пользовался терминалом, но никаких прелестей не почувствовал. Вот теперь сижу думаю, что я что-то важное упустил))
Так я говорю: создайте свой cat. У него будет идентичное название и идентичный способ использования. Когда ИИ будет вызывать "bash -c cat filename.txt", он на самом деле будет вызывать не встроенный cat, а вашу реализацию. И теперь смотрите, какая магия. Если файл превышает заданное ограничение на размер, команда, которая выглядит и вызывается точно так же, как падает с вашей кастомный ошибкой: "file too large. Please use 'cat filename.txt START:END'". То есть код ошибки сразу же подсказывает ИИшке правильное использование команды. Второй пример: ИИ пытается использовать sed. Но для sed у вас своя реализация, который на любой вызов говорит: "sed is not supported. Please use git patch". ИИ сразу вспоминает, что нужно использовать. А для docker/npm/etc. так же будет своя реализация, которая просто является алиасом: она перехватывает все аргументы, переданные ИИ, и вызывает реальную команду. Таким образом, у вас будет собственный клиентский шелл для ИИ, изменяющий поведение УЖЕ СУЩЕСТВУЮЩИХ команд, с ПОЧТИ ИДЕНТИЧНЫМ API. Вот что я имел ввиду. Если нужны подробности, предлагаю перейти в ЛС, а то эта ветка совсем разбухнет))
Вы не понимаете)) запрет на уровне шелла. Я предлагаю вам написать свой шелл
Да не потому, что ИИ сгенерировано. А потому, что сгенерировано бездумно. Нет нормальных раскрытых примеров, нет подробностей, нет КОНКРЕТИКИ. ИИ никогда конкретику не сгенерирует. Это отличительная черта таких бездумных статей. Когда конкретика будет, будут плюсы
Не совсем)) Вы же говорите, что ИИ читает текст через cat вместо вашего инструмента. Так что мешает подменить реализацию самого cat? Просто сделайте его своим инструментом) тогда даже инструкций для ИИ не нужно будет писать
Так же можно сделать и с остальными командами. Запретить ей писать в файлы в обход патчей на уровне middleware шелла - и все проблемы, описанные в статье, решатся (на мой взгляд)
Я бы не давал полный доступ ИИшке к шеллу. Вместо этого создал бы обёртку над bash. В этой обёртке есть разрешенные команды-алиасы. На некоторые требуется подтверждение, на некоторые - нет. Это и будет набором инструментов, только которые интуитивно понятны системе. Если ИИ пытается выполнить `cat largefile.txt` - выдаётся ошибка "файл слишком большой. Укажите диапазон в формате старт:стоп", или что-то подобное. Команд для записи просто не должно быть - всё через патчи. На npm/TS/RS/PHP/docker/yarn и т.д. будут "прозрачные" алиасы без подтверждений. Или с подтверждением. На остальные команды писать "permission denied" или "unsupported in this project"
Получится как middleware для шелла. Полная изоляция, абсолютно интуитивное управление. Можно будет сколько угодно инструментов впихнуть. Попробуйте :)
А теперь попросите исправить код)))
Не согласен. LLM читает быстро, но поверхностно. Если Вы про контекстное окно, то оно забивается очень быстро, после чего LLM забывает всё больше фактов и путается. Если же Вы про обучение, то тут механизм другой. LLM предсказывает наиболее вероятные токены. Так как на просторах гитхаба и в статьях очень много довольно старого материала, логично, что старые фичи будут казаться LLM более вероятными в использовании. А информации по новым фичами действительно недостаточно, т.к. для обучения нужно большое количество примеров
Когда человек читает, он ассоциирует текст со своим опытом. У LLM, увы, нет опыта. В этом принципиальная разница. Поэтому человеку так сложно запомнить что-то большое. И поэтому человек может разобраться в чем-то по-настоящему глубоко
У меня внезапно возникла интересная мысль
Почему люди создали SPA? Потому что глупо загружать каждый раз одни и те же элементы: хедер, футер, меню и т.д. Кэширование страдает от того, что всё в едином HTML. Но зачем всё так переусложнять, если можно:
Рендерить базовый Layout с шапкой и футером
Внутрь Layout добавить банальный iframe
Менять src у iframe в зависимости от нажатой кнопки в меню
При этом страницы можно писать на любом фреймворке. Они абсолютно независимы. Основная страница в браузере лишний раз не перезагружается, перезагружается только iframe. В чем проблема такого подхода?))
P.S. я конечно немного утрирую. Но ведь помимо этого существует ещё море более лёгких решений, чем SSR с гидратацией и тому подобное
P.S.S. даже нашел статью на тему iframe: https://habr.com/ru/companies/oleg-bunin/articles/716084/?ysclid=mmb3pe6bbn488742420 оказывается, всё уже придумали 30 лет назад)) тема с postmessage звучит очень многообещающе
Это в случае, если конкретно такая задача ставится. Я имел ввиду "боевую" задачу: когда нужно реализовать что-то по ТЗ максимально эффективно
Как вариант - создать собственный сборщик, который на этапе "компиляции" объединяет все html в 1, безо всякого лишнего JS в результате
Видимо, это были не те собесы. Как раз таки то, что ты понимаешь, где конкретно нужны данные технологии, делает из тебя специалиста. Думаю, если на собесе дадут задачу написать хелло ворлд, а кандидат пойдет собирать проект на Next.js, его не примут))
Самое банальное, что тут можно вспомнить - бесконечная загрузка при ошибке
Если подумать, то это реально потенциальный источник багов, т.к. мы вручную управляем состоянием, переносим ответственность за это во фронтенд. Но, в большинстве случаев, это оправдано: "нафига мне тащить поддержку какого-нибудь SSE, если у меня всего один тяжёлый запрос"
Многие спрашивают, где коды Грея применяются. Приведу простейший пример:
Задача скрейпинга отзывов с Амазона. Так как вывод ограничен всего 10-ю страницами, в ход идёт перебор фильтров. То есть мы просто поочередно перебираем все фильтры, затем уникьюлизируем результаты
Но вот проблема: при изменении одного фильтра страница перезагружается. При переборе фильтров в цикле получилось бы очень много лишних перезагрузок, т.к. за 1 итерацию мы меняем сразу несколько фильтров. Так как у меня в тот момент была гонка с другим программистом в этой задаче, я стал думать, как это оптимизировать. И придумал собственный "цикличный код Грея" (на тот момент я даже не знал о существовании такого). Я добился того, что на каждой итерации я изменяю ровно 1 фильтр, но перебираю все значения
У меня не повернулся бы язык назвать C++ "ванильным"))) он и без фреймворков хардкор :)
Они просто проходят ревью :)