Почему сразу ругаться, ну может не +50%, а +30%, т.е. какая компенсация вас бы устроила именно на эту позицию (на эти условия, все дело в цене), т.е. вы оставляете шанс работодателю, и если согласятся — то все в выигрыше (получается такой баланс).
Но в целом ваш подход хорош.
Да, как я и упомянул, для компиллируемых языков той проблемы быть не должно и GRPC должен быть быстр, не поделитесь исходником?, тоже интересно потестить.
Следовало бы так же протестировать все компоненты на разных хостах
Изначально тест и проводился на разных хостах (в Digital Ocean), но видимо там сеть была не быстрая и многие тесты показывали одинаковый* результат, но мы тестируем не скорость сети, а сервер/прокси, поэтому было решено тестировать без влияния сети (ведь у всех разные сети).
grpc, если клиент на столько неэффективен, следовало бы его исключить.
Мне кажется это может быть полезной информацией для питон разработчиков, чтобы потом не удивлятся когда GRPC будет уже внедрен.
— Не совсем уловил, как прописываются правила, соединяющие клиентов и обработчиков>
Есть 2 варианта, один описан в 5 разделе — например если обработчик должен обрабатывать команду «start», обработчик отправляет серверу json: '{"name": "start"}' и после того как клиент отправит запрос на url /start, клиент и обработчик будут «соединены» (но только на 1 команду т.к. вторая команда от клиента может быть другая на другой обработчик).
Для второго варианта пример тут, так же есть несколько примеров тут.
— Может ли быть несколько обработчиков по одной теме?
Да, множество обрабочтиков и множество клиентов на одни и теже «темы» (очереди) работают хорошо.
— Как послать сообщение конкретному обработчику из нескольких?
Для этого обрабочик может добавить список команд которые могут содержать идентификатор, например '{"name": "start:15,start"}', таким образом обработчик одновременно обслуживает 2 команды «start:15» и «start» (где 15 — это идентификатор). А клиенты в свою очередь могут получить список всех обработчиков из "/rpc/details" и работать с выбраным (подобный подход так же используется и для MQ систем).
Как видно, нужная нам директория содержится в блоке с номером 579. В ней мы найдем номер нода для папки home,
А почему сделано через ноды?, когда можно было бы хранить ссылку на нужный блок, т.е. вся инфа о содержимом папки была бы в блоке этой папки, и подобной проблемы бы не возникло.
Для мелких скриптов, там где городить ORM не хочется, сделал такой маппер sqlmapper, по сравнению c sqlalchemy (+reflect), код выходит компактней и быстрее, примеры:
db = Connection(db='example') # mysql/psql/sqlite
db.tblname.insert({'name': 'Ubuntu', 'value': 14})
# INSERT INTO `tblname` (`name`, `value`) VALUES ('Ubuntu', 14)
for d in db.tblname.find({'name': 'Ubuntu'}):
# SELECT tblname.* FROM `tblname` WHERE `tblname`.`name`='Ubuntu'
print(d)
И добавление таблиц/колонок если ещё не созданы:
# a table is created for first column
db.tblname.add_column('id', 'INT(11)', primary=True, auto_increment=True, exist_ok=True)
# CREATE TABLE `tblname` (`id` INT(11) NOT NULL AUTO_INCREMENT, PRIMARY KEY ...
db.tblname.add_column('name', 'VARCHAR(32)', exist_ok=True)
# ALTER TABLE `tblname` ADD COLUMN `name` VARCHAR(32)
1. Циклические импорты можно решить через инициализацию (т.е. «проблемный» код переместить в ф-ю из глобальной части, и запускать когда все уже импортированно)
А как у вас оно решается, когда нужны 2 модуля которые цыклический друг от друга?
2. Такие импорты делать класический или по полному пути компонента, либо аналогично сделать локальный модуль импорта.
3. Если проект стартует целиком и эти модули импортируются в любом случае (монолит), то разницы не будет.
А если нужна возможность запуска кусками, то можно сделать «режимы запуска» где будет импортироваться не все.
Ещё как вариант не импортировать глобально, а как один модуль, и использовать, например, как libs.math.sqrt, тогда можно вообще сделать ленивую подгрузку модулей.
Так же можно комбинировать подходы, и ложить в общий импорт только то, что действительно используется часто, тогда кол-во импортов скоратится до минимума.
Кроме того есть и другие архитектурные решения, где минимум импортов в больших проектах.
Цены выглядят завышеными если учесть, что за ~$30 из китая можно заказать телефон с андройдом (linux) с дисплеем, батареей и зарядкой.
И вопрос: есть ли какие-то варианты, чтобы конечный пользователь, без сложностей, мог подключить плату к приватному wifi? (например если я отправлю ему raspberry-pi с софтом по почте).
Интересный анализ, в глаза бросилось ES6 vs TypeScript.
Кол-во тех кто то попробовал TypeScript и больше бы его не использовали, более чем в 9 раз выше относительно, чем у ES6.
Т.е. большой антирейтинг у TS, что вы об этом думуаете?
Но в целом ваш подход хорош.
Мне кажется это может быть полезной информацией для питон разработчиков, чтобы потом не удивлятся когда GRPC будет уже внедрен.
Нет, но возможно в следующий тест будет включён.
'{"name": "start"}'и после того как клиент отправит запрос на url/start, клиент и обработчик будут «соединены» (но только на 1 команду т.к. вторая команда от клиента может быть другая на другой обработчик).Для второго варианта пример тут, так же есть несколько примеров тут.
Да, множество обрабочтиков и множество клиентов на одни и теже «темы» (очереди) работают хорошо.
Для этого обрабочик может добавить список команд которые могут содержать идентификатор, например
'{"name": "start:15,start"}', таким образом обработчик одновременно обслуживает 2 команды «start:15» и «start» (где 15 — это идентификатор). А клиенты в свою очередь могут получить список всех обработчиков из "/rpc/details" и работать с выбраным (подобный подход так же используется и для MQ систем).И добавление таблиц/колонок если ещё не созданы:
А как у вас оно решается, когда нужны 2 модуля которые цыклический друг от друга?
2. Такие импорты делать класический или по полному пути компонента, либо аналогично сделать локальный модуль импорта.
3. Если проект стартует целиком и эти модули импортируются в любом случае (монолит), то разницы не будет.
А если нужна возможность запуска кусками, то можно сделать «режимы запуска» где будет импортироваться не все.
Ещё как вариант не импортировать глобально, а как один модуль, и использовать, например, как
libs.math.sqrt, тогда можно вообще сделать ленивую подгрузку модулей.Так же можно комбинировать подходы, и ложить в общий импорт только то, что действительно используется часто, тогда кол-во импортов скоратится до минимума.
Кроме того есть и другие архитектурные решения, где минимум импортов в больших проектах.
Без магии и инструментарий не поломается.
И вопрос: есть ли какие-то варианты, чтобы конечный пользователь, без сложностей, мог подключить плату к приватному wifi? (например если я отправлю ему raspberry-pi с софтом по почте).
Кол-во тех кто то попробовал TypeScript и больше бы его не использовали, более чем в 9 раз выше относительно, чем у ES6.
Т.е. большой антирейтинг у TS, что вы об этом думуаете?
семьеместе, чем не удача?Алиса, по видимому, тоже не проч похайповать, выдав не уязвимость за уязвимость.