Несмотря на отсутствие предложений по решению проблемы, в данной статье действительно затрагивается довольно актуальная тема. Вспомните недавние статьи о куче вредоносных NPM пакетов. Об этом нужно говорить, и нужно предлагать пути решения. Один из вариантов - создание безопасного репозитория, в котором проверяется каждый включённый пакет. Пакеты, не включённые туда, можно будет установить на свой страх и риск. Проблема в реализации такого подхода. Понятно, что для ручной проверки ресурсов не хватит. Если кто-то будет это финансировать, возможно, проблема решится. Но во многих случаях компании просто дорабатывают существующие пакеты под свои нужды
Девелоперу-то это всё очевидно. А ревьюверу? А людям, которые будут поддерживать этот код в дальнейшем? Вы представьте, как ревьюверам тяжело - у них может быть 2 или 3 джуна, у которых они кто-то вроде наставников, и у каждого нужно проверять код. Конечно, им проще будет смотреть на алиасы!
Питон и низкое потребление ресурсов - звучит довольно смешно.
Задам 3 наводящих вопроса.
Скажите, что в этой системе больше всего потребляет ресурсов: непосредственно интерпретатор Python, PyQt5 или Vosk?
На чём написан PyQt5?
Что в проекте написано непосредственно на Python?
Надеюсь, посыл понятен.
А насчёт механизма нечёткого сравнения: отчасти согласен. При добавлении своего скрипта стоит добавить опцию отклбчения этого механизма, а также обязательно необходимо предоставить возможность создать подтверждение команды
Интересная статья, но не совсем понятен посыл. Почему я должен забывать старые паттерны, которые уже используются в проекте? Или статья - предложение написать приложение на старом фреймворке, но на новый лад? Тут скорее надо делать гайд для миграции на Vue3.
Ещё непонятен момент с Vuex/Pinia. Вы сначала говорите, что лучше использовать Vuex:
во Vue 2 лучше использовать Vuex для сложного стейта.
А затем утверждаете обратное:
Мой выбор однозначно падает на Pinia.
Постепенно внедряйте Composition API и Pinia, чтобы упростить будущий переход на Vue 3.
И в последней цитате прямо говорится про переход на Vue3, но во всей остальной статье нет других упоминаний этого
Блин, почему в одну модель пытаются уместить все знания мира? ИИ до сих пор не осознаёт значение того, что он говорит, а его уже пытаются сделать сверхразумом. В человеческом мозге есть два полушария, отвечающие за разные вещи, а люди забывают об этом. Я бы предложил обучать текущую реализацию "ИИ" на конкретных областях знаний, делая модели меньше, но эффективнее. Это снизит вероятность возникновения галлюцинаций и повысит точность.
В будущем было бы неплохо обучать модель подобно самому человеку: эмулировать настоящие переживания. Ещё можно попробовать реализовать что-то вроде оптимизации строения нейронной сети: обратное распространение ошибки, но "на уровень выше"
Автор был не очень точен в формулировке. Безусловно, он имел ввиду "неявную статическую типизацию". Не хейтите его - он понял всё верно)
Статья, не считая этого косяка, очень даже дельная: не стоит использовать var на каждом шаге. Стоит использовать либо в реально очевидных местах, либо вместо монструозных типовых конструкций, либо в сприптах. Но на самом деле сильно переживать не стоит, ведь обо всём напишут в кодостайле и выскажут на ревью :)
Ааа, мою идею реализовали)) Я тоже давно задумывался о таком агенте) вы -- молодец :) всё реализовали замечательно
У меня была идея помимо всего прочего дать модели возможность использовать "калькулятор" - можно в виде хуков наподобие [calculate]1+1[/calculate]. Также можно добавить "рекурсивные" хуки (например, [memory][calculate]1+1[/calculate][/memory]). Плюсом было бы дать возможность через те же хуки использовать поиск в интернете. Дальше можно начать подключать датчики, сигналы с которых будут в реальном времени обрабатываться, и получится растоящий киборг))
Вот насчёт языка я бы не очень согласился. В олимпиадах важна скорость решения задач и, в частности, написания самого кода. Если в C++ довольно легко ошибиться, то в python больше вероятности написать верный код с первого раза. За время выполнения программы не дают бонусов почти нигде (если ничего не поменялось, конечно, я 2-3 года назад активно участвовал). Обычно делают так: если алгоритм может отработать менее чем за 30 секунд на бОльшем объёме данных, чем в стандартном условии, то дают +балл. А это зависит уже от реализации. Если вы напишите алгоритм сложностью O(n^4), то пишите на чём угодно - доп.балл не дадут :(
Поэтому я бы советовал напротив - выбирать язык, который лично вам даётся проще, и на котором пишется быстрее и без ошибок
Заметил неточность: вы назвали граф, описывающий структуру материала заметок, деревом. Я не придираюсь, просто раз вы разработчик, для вас может быть полезно почитать об этом. В будущем это может очень пригодиться
(Возможно, это просто опечатка, но на всякий случай решил написать)
Посыл статьи в том, что не нужно городить то, что не требуется. Если требуется паттерн - применяйте. Но если в задаче "вывести на экран Hello, world!" программист оборачивает вызов System.out.println в метод printStr класса StringPrinter (наследуемого от AbstractPrinter) и создаёт PrinterFactory - это уже перебор. Помните, что все паттерны призваны упростить код и его дальнейшую поддержку, а не усложнить
Здесь статья как раз про то, как НАДО продумывать - без ЛИШНИХ сложностей. Но нет четких правил и примеров. С одной стороны, очень хорошо, что люди стали наконец задумываться о бессмысленности примерения монструозных паттернов, но плохо, что нет никакой чёткой информации
Несмотря на отсутствие предложений по решению проблемы, в данной статье действительно затрагивается довольно актуальная тема. Вспомните недавние статьи о куче вредоносных NPM пакетов. Об этом нужно говорить, и нужно предлагать пути решения. Один из вариантов - создание безопасного репозитория, в котором проверяется каждый включённый пакет. Пакеты, не включённые туда, можно будет установить на свой страх и риск. Проблема в реализации такого подхода. Понятно, что для ручной проверки ресурсов не хватит. Если кто-то будет это финансировать, возможно, проблема решится. Но во многих случаях компании просто дорабатывают существующие пакеты под свои нужды
Девелоперу-то это всё очевидно. А ревьюверу? А людям, которые будут поддерживать этот код в дальнейшем? Вы представьте, как ревьюверам тяжело - у них может быть 2 или 3 джуна, у которых они кто-то вроде наставников, и у каждого нужно проверять код. Конечно, им проще будет смотреть на алиасы!
Вам-то это всё очевидно. А представьте, что вы отдаёте сво
Задам 3 наводящих вопроса.
Скажите, что в этой системе больше всего потребляет ресурсов: непосредственно интерпретатор Python, PyQt5 или Vosk?
На чём написан PyQt5?
Что в проекте написано непосредственно на Python?
Надеюсь, посыл понятен.
А насчёт механизма нечёткого сравнения: отчасти согласен. При добавлении своего скрипта стоит добавить опцию отклбчения этого механизма, а также обязательно необходимо предоставить возможность создать подтверждение команды
Интересная статья, но не совсем понятен посыл. Почему я должен забывать старые паттерны, которые уже используются в проекте? Или статья - предложение написать приложение на старом фреймворке, но на новый лад? Тут скорее надо делать гайд для миграции на Vue3.
Ещё непонятен момент с Vuex/Pinia. Вы сначала говорите, что лучше использовать Vuex:
А затем утверждаете обратное:
И в последней цитате прямо говорится про переход на Vue3, но во всей остальной статье нет других упоминаний этого
Блин, почему в одну модель пытаются уместить все знания мира? ИИ до сих пор не осознаёт значение того, что он говорит, а его уже пытаются сделать сверхразумом. В человеческом мозге есть два полушария, отвечающие за разные вещи, а люди забывают об этом. Я бы предложил обучать текущую реализацию "ИИ" на конкретных областях знаний, делая модели меньше, но эффективнее. Это снизит вероятность возникновения галлюцинаций и повысит точность.
В будущем было бы неплохо обучать модель подобно самому человеку: эмулировать настоящие переживания. Ещё можно попробовать реализовать что-то вроде оптимизации строения нейронной сети: обратное распространение ошибки, но "на уровень выше"
Статья супер! Но насколько я знаю, EFLAGS 32-битный регистр. FLAGS, расширением над которым и является EFLAGS, как раз таки 16-битный
Дорогие комментаторы
Автор был не очень точен в формулировке. Безусловно, он имел ввиду "неявную статическую типизацию". Не хейтите его - он понял всё верно)
Статья, не считая этого косяка, очень даже дельная: не стоит использовать var на каждом шаге. Стоит использовать либо в реально очевидных местах, либо вместо монструозных типовых конструкций, либо в сприптах. Но на самом деле сильно переживать не стоит, ведь обо всём напишут в кодостайле и выскажут на ревью :)
Ааа, мою идею реализовали)) Я тоже давно задумывался о таком агенте) вы -- молодец :) всё реализовали замечательно
У меня была идея помимо всего прочего дать модели возможность использовать "калькулятор" - можно в виде хуков наподобие [calculate]1+1[/calculate]. Также можно добавить "рекурсивные" хуки (например, [memory][calculate]1+1[/calculate][/memory]). Плюсом было бы дать возможность через те же хуки использовать поиск в интернете. Дальше можно начать подключать датчики, сигналы с которых будут в реальном времени обрабатываться, и получится растоящий киборг))
Индусеть
Главное, чтобы Петя не увидел этот пост, а то он осознает свою ценность и будет отлынивать от своей главной задачи))
Спасибо, статья очень информативная)
Вот насчёт языка я бы не очень согласился. В олимпиадах важна скорость решения задач и, в частности, написания самого кода. Если в C++ довольно легко ошибиться, то в python больше вероятности написать верный код с первого раза. За время выполнения программы не дают бонусов почти нигде (если ничего не поменялось, конечно, я 2-3 года назад активно участвовал). Обычно делают так: если алгоритм может отработать менее чем за 30 секунд на бОльшем объёме данных, чем в стандартном условии, то дают +балл. А это зависит уже от реализации. Если вы напишите алгоритм сложностью O(n^4), то пишите на чём угодно - доп.балл не дадут :(
Поэтому я бы советовал напротив - выбирать язык, который лично вам даётся проще, и на котором пишется быстрее и без ошибок
Здесь идёт речь о дефолтном декодировании gzip при HTTP запросах, никакой рекурсивной распаковки архива здесь нет)
Ещё одна особенность JavaScript? ;)
Функционал практически идентичный, но не хватает такой же продуманной прокрутки при выделении, как в Paint.NET. в остальном - полный аналог
Заметил неточность: вы назвали граф, описывающий структуру материала заметок, деревом. Я не придираюсь, просто раз вы разработчик, для вас может быть полезно почитать об этом. В будущем это может очень пригодиться
(Возможно, это просто опечатка, но на всякий случай решил написать)
Посыл статьи в том, что не нужно городить то, что не требуется. Если требуется паттерн - применяйте. Но если в задаче "вывести на экран Hello, world!" программист оборачивает вызов System.out.println в метод printStr класса StringPrinter (наследуемого от AbstractPrinter) и создаёт PrinterFactory - это уже перебор. Помните, что все паттерны призваны упростить код и его дальнейшую поддержку, а не усложнить
Здесь статья как раз про то, как НАДО продумывать - без ЛИШНИХ сложностей. Но нет четких правил и примеров. С одной стороны, очень хорошо, что люди стали наконец задумываться о бессмысленности примерения монструозных паттернов, но плохо, что нет никакой чёткой информации
Статья как раз об этом. В чём странность?
Такое ощущение, что rust здесь только для галочки. Он же только позволяет получить доступ к конфигу, я правильно понял?