Все так делают, тут автор комментария что-то перепутал явно... Иначе получится, что заказ собрали, а оплату не получили - никакой безопасности. Обычно просто доплата/возврат/замена идут в случае изменения состава заказа
Довольно интересно) в действительности, увы, каждый элемент должен работать стабильно, независимо от того, сколько других элементов во всём рое. Дело в том, что воркеры - это идеальные клоны. Если один из них ведёт себя нестабильно, значит и остальные тоже. Если "забить" на поведение конкретных элементов, приложение/сервис будет работать как Франкенштейн, у которого части тела отказывают. Например, в интернет магазине каталог товаров работает, но заказ из корзины нельзя оформить. "Это же рой, в целом среда рабочая", - увы, не оправдание... Я не к тому, что идея плохая - нужно просто её развить и продумать до конца. Так-то было бы удобно мыслить высокоуровневыми конечными целями вместо конкретных системных фич. Но детальный контроль никуда не девается, увы
А ещё открою секрет: когда вы пишите любую программу, вы уже в парадигме среды. Потому что любая программа запускается на ОС. ОС - среда, в прямом смысле. ОС работает на компьютере. Компьютер - также среда. Да и компьютер, в свою очередь, функционирует в среде, в которой мы живём)) просто за каждую среду отвечают свои люди. Каждая среда - система. От этого не убежишь, во всяком случае, пока что. Любая среда декомпозирована и успешно поддерживается ответственными людьми, контролируется каждый элемент. Без этого не создать процессор. Без этого не создать ОС. Даже браузер, на котором описанный выше сайт-франкенштейн крутится, не создать
В больших компаниях люди, которые только что пришли, тоже живут в своей среде. Остальное для них просто работает. Они могут даже не понять, что в другой среде есть баг, т.к. это не их зона ответственности. Хотя они работают с этой средой, разрабатывают они другую. Что для них - неизведанный рой с набором высокоуровневых конечных целей, описывающих, как это должно работать, для других - понятная система с четкой структурой
Так что отчасти мы уже в этой парадигме. Просто нужно увидеть её. Мы никогда не будем контролировать всё на свете, но будем контролировать то, за что ответственны, и доверять другим ответственным людям. "Разделяй и властвуй"
P.S. надеюсь, я правильно понял посыл статьи. Если что - заранее извиняюсь и прошу поправить
Не знаю, как у вас, а у нас ветка оформляется ПЕРЕД созданием merge request, а не после, чтобы не загрязнять обсуждения в GitLab (там же выводится список коммитов после любого push). В процессе разработки можно как угодно коммиты делать. Но в историю должны пойти чистые и аккуратные коммиты
Про дробление файлов, как мне кажется, идея отличная - можно было вместо всех этих трудностей с пулами просто регулярно говорить клиенту, на какой сервер какой процент блоков файла отправлять
L7 для балансеров, скорее всего. То есть чтобы достучаться до какого-то балансера для получения адреса сервера, нужно пройти через gateway, т.к. балансеров тоже много, но трафик там небольшой
Смотрите. В 1-м своём комментарии я не навязывал обязательное использование стора. Я лишь перечислил плюсы такого подхода. Если есть пагинация, и нужно фильтровать данные в разных местах - стор, скорее всего, не стоит использовать вовсе. Всё зависит от потребностей)
Когда я писал второй комментарий, я неверно вас понял, за что извиняюсь. Решил, что вы собрались писать логику обработки данных прямо в компоненте))
Но тем не менее. Допустим, у вас есть множество сервисов, занимающихся обработкой и получением данных. Стора в проекте пока нет. Вы в компонентах получаете / отправляете данные только через сервисы. Но вдруг появляется первый ваш стор. И прямо в этом сторе прописано:data.value = await (await fetch(...)).json();проходит какое-то время, и в команду приходит новенький. Ему дают задачу: дописать логику получения данных с бэка. Например, поменять формат данных, возвращаемых API. Где он будет искать логику получения данных? Конечно, в сервисах. А найдёт в сторе. И где ему дописывать новую логику?
Ну так в вашей схеме получается, что кто угодно может изменить стор. Я вообще не представляю, как КОМПОНЕНТ может менять стор? Я всегда все операции с данными делаю через сервисы. Если есть сотня компонентов и сервисов, и при этом часть компонентов меняет данные самостоятельно - это жесть. Я через это проходил на своих проектах))
Получается, что данные запрашиваются через сервисы и записываются в стор, а компоненты только читают данные из стора. Как вы и написали. Данные записываются в хранилище, и через реактивность подтягиваются там, где нужно. Это очень удобно
Не всем компонентам нужна консистентность
Вы неправильно понимаете принцип, который я описал. Вот у вас есть исходные данные в сторе. Одному компоненту требуется сортировка по цене, другому - по цвету и с фильтром по категориям. Вместо того, чтобы хранить копии данных в сторе для каждого компонента - берёте и реактивно сортируете/фильтруете данные из стора через computed. У вас будет 1 источник истины и никаких лишних копий данных
Так тестируйте сервис
Вот исходя из моих доводов выше, представьте, как будет удобно тестировать такую систему. Вы один раз для всех зависимых компонентов задаёте данные в сторе, а потом через computed делаете с ними, что хотите, и проверяете
На мой взгляд, тут чистейшей воды side effect. Если это стор - ожидаемо, что ты получаешь уже сохраненные данные. Тогда можно тупо в сервис это запихнуть. Или тут подразумевается некий кэш?
На самом деле, я осознал, что немного соврал. Примерно в 50% случаев при поиске вылезает ИИ от Гугла/Яндекса. Большой плюс здесь в том, что эти ИИ довольно глупые, чтобы "качественно галлюцинировать" - все их выдумки видны сразу, с первого взгляда понятно, когда нужно искать самому
Это очень хороший компромисс, это действительно помогает в простых запросах. И это намного эффективнее, чем вбивать запрос в "тяжёлую" нейросеть. Я бы сказал, это как из пушки по воробьям) а вот лайтовые поисковые ИИ типа "поиск с Я.Алисой" - идеально
На форумах люди проверяли и тестировали решение. Причем с обеих сторон - и автор вопроса, и автор ответа. Плюс люди в комментариях ругаются, если ответ плохой. Качество контента на форумах и на ИИ даже сравнивать страшно
Часто люди спрашивают, зачем понимать, осознавать, что ты делаешь через нейросеть. И в чём вообще проблема нейросетей. Отличный пример: автор статьи в начале пишет, что он очень переживает по поводу безопасности. Он же в конце: отключает на macOS проверку сертификатов из-за какой-то ошибки
P.S. а ведь раньше форумы ругали за качество... Видно, что сейчас приоритетнее количество
Вот и у меня то же самое. В существующем проекте вообще невозможно пользоваться нейронками. Если вдруг кто-то смог, поделитесь рецептом, пожалуйста... У меня халтура - логистический проект на 4 сервиса в монорепе. Очень не хочется писать самому, но LLM выдаёт такой ужас, что приходится
Честно, для меня гуглить в ряде случаев намного продуктивнее того же ЛЛМ поиска. Пока он подумает, погенерирует, ошибётся и поправит сам себя, я уже давно вобью в поиск ключевые слова (которые в разы короче промпта, кстати) и получу ответ, даже не открывая ссылку, из описания статьи
Конечно, всё зависит от цели. И, наверное, от стоимости подписки на LLM)) но я перепробовал очень много бесплатных моделей, и понял, что во многих случаях, например, проще почитать оригинальное объяснение на старом добром stackoverflow, чем глючную выдачу LLM. Просто потому, что на stackoverflow это уже кто-то проверил, и это реально работает
Это же касается и гугления ответов на экзаменах, кстати. Если мне задают вопрос, на который я плохо знаю ответ, я иду гуглить его, и разбираюсь в теме за несколько запросов. Тем, кто пользовался LLM, почти никогда не засчитывают ответ, потому что LLM режет детали или выдумывает их
Внутри стора нельзя писать логику получения запросов. Для этого есть сервисы. Сервис должен получать данные с АПИ, обрабатывать и отправлять в стор
Зачем хранить данные в сторе, если они используются в 1 компоненте? 1) консистентность - данные с Бека хранятся в одном месте; 2) удобство тестов - можно легко мокать стор (попробуйте замокать локальную переменную где-то в сервисе); 3) удобная отладка - просмотр содержимого стора; ...и т.д.
Все так делают, тут автор комментария что-то перепутал явно... Иначе получится, что заказ собрали, а оплату не получили - никакой безопасности. Обычно просто доплата/возврат/замена идут в случае изменения состава заказа
Довольно интересно) в действительности, увы, каждый элемент должен работать стабильно, независимо от того, сколько других элементов во всём рое. Дело в том, что воркеры - это идеальные клоны. Если один из них ведёт себя нестабильно, значит и остальные тоже. Если "забить" на поведение конкретных элементов, приложение/сервис будет работать как Франкенштейн, у которого части тела отказывают. Например, в интернет магазине каталог товаров работает, но заказ из корзины нельзя оформить. "Это же рой, в целом среда рабочая", - увы, не оправдание... Я не к тому, что идея плохая - нужно просто её развить и продумать до конца. Так-то было бы удобно мыслить высокоуровневыми конечными целями вместо конкретных системных фич. Но детальный контроль никуда не девается, увы
А ещё открою секрет: когда вы пишите любую программу, вы уже в парадигме среды. Потому что любая программа запускается на ОС. ОС - среда, в прямом смысле. ОС работает на компьютере. Компьютер - также среда. Да и компьютер, в свою очередь, функционирует в среде, в которой мы живём)) просто за каждую среду отвечают свои люди. Каждая среда - система. От этого не убежишь, во всяком случае, пока что. Любая среда декомпозирована и успешно поддерживается ответственными людьми, контролируется каждый элемент. Без этого не создать процессор. Без этого не создать ОС. Даже браузер, на котором описанный выше сайт-франкенштейн крутится, не создать
В больших компаниях люди, которые только что пришли, тоже живут в своей среде. Остальное для них просто работает. Они могут даже не понять, что в другой среде есть баг, т.к. это не их зона ответственности. Хотя они работают с этой средой, разрабатывают они другую. Что для них - неизведанный рой с набором высокоуровневых конечных целей, описывающих, как это должно работать, для других - понятная система с четкой структурой
Так что отчасти мы уже в этой парадигме. Просто нужно увидеть её. Мы никогда не будем контролировать всё на свете, но будем контролировать то, за что ответственны, и доверять другим ответственным людям. "Разделяй и властвуй"
P.S. надеюсь, я правильно понял посыл статьи. Если что - заранее извиняюсь и прошу поправить
А, значит, всё-таки антропик захватит мир? Способность читать между строк и тут пригодилась)
...а потом кто-то в переменную $CITY добавит символы
';
И будет весело :)
Не знаю, как у вас, а у нас ветка оформляется ПЕРЕД созданием merge request, а не после, чтобы не загрязнять обсуждения в GitLab (там же выводится список коммитов после любого push). В процессе разработки можно как угодно коммиты делать. Но в историю должны пойти чистые и аккуратные коммиты
Про дробление файлов, как мне кажется, идея отличная - можно было вместо всех этих трудностей с пулами просто регулярно говорить клиенту, на какой сервер какой процент блоков файла отправлять
L7 для балансеров, скорее всего. То есть чтобы достучаться до какого-то балансера для получения адреса сервера, нужно пройти через gateway, т.к. балансеров тоже много, но трафик там небольшой
Смотрите. В 1-м своём комментарии я не навязывал обязательное использование стора. Я лишь перечислил плюсы такого подхода. Если есть пагинация, и нужно фильтровать данные в разных местах - стор, скорее всего, не стоит использовать вовсе. Всё зависит от потребностей)
Когда я писал второй комментарий, я неверно вас понял, за что извиняюсь. Решил, что вы собрались писать логику обработки данных прямо в компоненте))
Но тем не менее. Допустим, у вас есть множество сервисов, занимающихся обработкой и получением данных. Стора в проекте пока нет. Вы в компонентах получаете / отправляете данные только через сервисы. Но вдруг появляется первый ваш стор. И прямо в этом сторе прописано:
data.value = await (await fetch(...)).json();проходит какое-то время, и в команду приходит новенький. Ему дают задачу: дописать логику получения данных с бэка. Например, поменять формат данных, возвращаемых API. Где он будет искать логику получения данных? Конечно, в сервисах. А найдёт в сторе. И где ему дописывать новую логику?Нужны 4 человека-добровольца. Задача: сменить имена на root, nobody, Admin и Guest
Тут принцип другой. VLESS использует маскировку, а в Naive буквально скопировали реализацию из хрома, как я понял
Ну и VLESS довольно успешно блокируется. Очевидно, что, если бы он не был на волне хайпа, внимания бы к себе не привлек, о чём автор и сказал
Ну так в вашей схеме получается, что кто угодно может изменить стор. Я вообще не представляю, как КОМПОНЕНТ может менять стор? Я всегда все операции с данными делаю через сервисы. Если есть сотня компонентов и сервисов, и при этом часть компонентов меняет данные самостоятельно - это жесть. Я через это проходил на своих проектах))
Получается, что данные запрашиваются через сервисы и записываются в стор, а компоненты только читают данные из стора. Как вы и написали. Данные записываются в хранилище, и через реактивность подтягиваются там, где нужно. Это очень удобно
Вы неправильно понимаете принцип, который я описал. Вот у вас есть исходные данные в сторе. Одному компоненту требуется сортировка по цене, другому - по цвету и с фильтром по категориям. Вместо того, чтобы хранить копии данных в сторе для каждого компонента - берёте и реактивно сортируете/фильтруете данные из стора через computed. У вас будет 1 источник истины и никаких лишних копий данных
Вот исходя из моих доводов выше, представьте, как будет удобно тестировать такую систему. Вы один раз для всех зависимых компонентов задаёте данные в сторе, а потом через computed делаете с ними, что хотите, и проверяете
Довольно странное решение... Зачем тогда сервисы?
На мой взгляд, тут чистейшей воды side effect. Если это стор - ожидаемо, что ты получаешь уже сохраненные данные. Тогда можно тупо в сервис это запихнуть. Или тут подразумевается некий кэш?
На самом деле, я осознал, что немного соврал. Примерно в 50% случаев при поиске вылезает ИИ от Гугла/Яндекса. Большой плюс здесь в том, что эти ИИ довольно глупые, чтобы "качественно галлюцинировать" - все их выдумки видны сразу, с первого взгляда понятно, когда нужно искать самому
Это очень хороший компромисс, это действительно помогает в простых запросах. И это намного эффективнее, чем вбивать запрос в "тяжёлую" нейросеть. Я бы сказал, это как из пушки по воробьям) а вот лайтовые поисковые ИИ типа "поиск с Я.Алисой" - идеально
На форумах люди проверяли и тестировали решение. Причем с обеих сторон - и автор вопроса, и автор ответа. Плюс люди в комментариях ругаются, если ответ плохой. Качество контента на форумах и на ИИ даже сравнивать страшно
Часто люди спрашивают, зачем понимать, осознавать, что ты делаешь через нейросеть. И в чём вообще проблема нейросетей. Отличный пример: автор статьи в начале пишет, что он очень переживает по поводу безопасности. Он же в конце: отключает на macOS проверку сертификатов из-за какой-то ошибки
P.S. а ведь раньше форумы ругали за качество... Видно, что сейчас приоритетнее количество
Вот и у меня то же самое. В существующем проекте вообще невозможно пользоваться нейронками. Если вдруг кто-то смог, поделитесь рецептом, пожалуйста... У меня халтура - логистический проект на 4 сервиса в монорепе. Очень не хочется писать самому, но LLM выдаёт такой ужас, что приходится
Честно, для меня гуглить в ряде случаев намного продуктивнее того же ЛЛМ поиска. Пока он подумает, погенерирует, ошибётся и поправит сам себя, я уже давно вобью в поиск ключевые слова (которые в разы короче промпта, кстати) и получу ответ, даже не открывая ссылку, из описания статьи
Конечно, всё зависит от цели. И, наверное, от стоимости подписки на LLM)) но я перепробовал очень много бесплатных моделей, и понял, что во многих случаях, например, проще почитать оригинальное объяснение на старом добром stackoverflow, чем глючную выдачу LLM. Просто потому, что на stackoverflow это уже кто-то проверил, и это реально работает
Это же касается и гугления ответов на экзаменах, кстати. Если мне задают вопрос, на который я плохо знаю ответ, я иду гуглить его, и разбираюсь в теме за несколько запросов. Тем, кто пользовался LLM, почти никогда не засчитывают ответ, потому что LLM режет детали или выдумывает их
Внутри стора нельзя писать логику получения запросов. Для этого есть сервисы. Сервис должен получать данные с АПИ, обрабатывать и отправлять в стор
Зачем хранить данные в сторе, если они используются в 1 компоненте? 1) консистентность - данные с Бека хранятся в одном месте; 2) удобство тестов - можно легко мокать стор (попробуйте замокать локальную переменную где-то в сервисе); 3) удобная отладка - просмотр содержимого стора; ...и т.д.
В современных реалиях фраза "7068 строк кода, 15 модулей и ни одного фреймворка" звучит страшно XD
Но это шутка, конечно) решение супер, я сам хотел для себя написать что-то подобное. Точ что описано в статье - прям то, что нужно!
Хах, понятное дело. Поэтому призываю и тебя не писать "на шару" :)
В любом случае, тут решение далеко от идеала
Тогда согласен на все сто. Очень не нравится, когда люди следуют паттернам по принципу "потому что так надо"
Хах, такими темпами новый TCP протокол получится))