Питон и низкое потребление ресурсов - звучит довольно смешно.
Задам 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 - это уже перебор. Помните, что все паттерны призваны упростить код и его дальнейшую поддержку, а не усложнить
Здесь статья как раз про то, как НАДО продумывать - без ЛИШНИХ сложностей. Но нет четких правил и примеров. С одной стороны, очень хорошо, что люди стали наконец задумываться о бессмысленности примерения монструозных паттернов, но плохо, что нет никакой чёткой информации
Видимо, автор вспомнил про 3proxy. Там действительно по дефолту стоит 3128. Но это самый нестабильный прокси сервер, который я когда-либо использовал. Сейчас нашел божественный докер-контейнер со сконфигурированным прокси сервером, изменяющимся через обычные environment переменные. Http завелось без танцев с бубном, с socks не было надобности, но подключаться не хотело. Он в первых строках поиска, так что кому надо - пользуйтесь. Бнз остановок крутится более 2х месяцев
Автор хотел сказать, что микросервисы - не антоним монолиту. Что под монолитом можно подразумевать разное. И если код разделён на слои, то, наверное, не очень корректно называть его монолитом. Но, очевидно, это - не микросервисы
Но тут автор не совсем прав, так как нужно всего лишь учитывать контекст. В контексте архитектуры сервиса вместо монолита правильнее употребить слова легаси код. А в контексте архитектуры всей системы - монолит и микросервисы
Не думаю, что рейтинги Хабра повысились бы от того, что он будет на собственном поддомене размещать рекламу уже чужого сервиса, и тем более делать на него редирект :) продать домен - одно, продать поддомен своего основного домена - принципиально другое. Не думаю, что Хабр хотел бы связать себя каким-либо образом с именем другой компании
Есть куча других вариантов. Но Хабр делает упор на конфиденциальность. Понятное дело, что нельзя угодить всем, поэтому передать данные конкретной компании довольно трудно и небезопасно. Поэтому их решение действительно универсальное и показывает заинтересованность в сохранении репутации. Лично я одобряю
Задам 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 здесь только для галочки. Он же только позволяет получить доступ к конфигу, я правильно понял?
Видимо, автор вспомнил про 3proxy. Там действительно по дефолту стоит 3128. Но это самый нестабильный прокси сервер, который я когда-либо использовал. Сейчас нашел божественный докер-контейнер со сконфигурированным прокси сервером, изменяющимся через обычные environment переменные. Http завелось без танцев с бубном, с socks не было надобности, но подключаться не хотело. Он в первых строках поиска, так что кому надо - пользуйтесь. Бнз остановок крутится более 2х месяцев
Автор хотел сказать, что микросервисы - не антоним монолиту. Что под монолитом можно подразумевать разное. И если код разделён на слои, то, наверное, не очень корректно называть его монолитом. Но, очевидно, это - не микросервисы
Но тут автор не совсем прав, так как нужно всего лишь учитывать контекст. В контексте архитектуры сервиса вместо монолита правильнее употребить слова легаси код. А в контексте архитектуры всей системы - монолит и микросервисы
Не думаю, что рейтинги Хабра повысились бы от того, что он будет на собственном поддомене размещать рекламу уже чужого сервиса, и тем более делать на него редирект :) продать домен - одно, продать поддомен своего основного домена - принципиально другое. Не думаю, что Хабр хотел бы связать себя каким-либо образом с именем другой компании
Есть куча других вариантов. Но Хабр делает упор на конфиденциальность. Понятное дело, что нельзя угодить всем, поэтому передать данные конкретной компании довольно трудно и небезопасно. Поэтому их решение действительно универсальное и показывает заинтересованность в сохранении репутации. Лично я одобряю