Заказывал себе через pochta.fi из штатов System76 Lemur (после обзора на хабре сразу захотелось себе такой ноут, да и надо было на что-то менять старый) и очень доволен, особенно, ценой за доставку. Вышло недорого и довольно оперативно. Только сайт у них пока не очень информативный, нет, например, своего трекинга посылок, но, надеюсь, он таки появится однажды.
В данном же случае, у вас все ляжет в очередь, и workerы потихоничку и без напряга все отработают.
Может быть я это не заметил в статье, но у вас же есть таймауты для задач в очереди?
Я про версии кода приложения. Без проблем называете несовместимый по запросу/ответу таск «app.mysupertask.v1» и фронтенд с уже обновленным кодом все будет слать на новые воркеры. Даже если вы остановите все воркеры, у вас приходящие сообщения будут копиться в очереди (учитывая timeout который вы уже обработаете сами), а после запуска воркеров, все побежит.
А, вот и про таймаут. Не очень понятно, что означает «обрабатываете сами», правда.
Кажется, я понял, в чём заключается предлагаемый подход. Согласен, он может применятся, хотя я предпочёл бы, чтобы фреймворк/сервер/шина умела решать это за меня.
Опять же на совести разработчика. Worker это просто функция, лично у меня есть декоратор который шлет в sentry ошибки.
WSGI-приложение — это тоже в принципе просто функция. Если вы хотите делать возможность подключения в качестве обработчиков wsgi-приложения на Django или других фреймворках, то, наверное, имеет смысл делать это не ради спортивного интереса, а чтобы разработчики могли этим пользоваться, не задумываясь о множестве деталей, типа логирования. С распределением нагрузки по серверам не так уж и плохо справляется nginx, так что тут непонятно, зачем придумывать ещё одну прослойку. Но вот чего реально не хватает — это возможности «из коробки» собирать логи, а главное, отчётов об ошибках, централизованно, без поиска по логам инстансов и привлечения сторонних лог-сервисов и лог-серверов.
Этот вопрос я бы на вашем месте расписал подробнее. Что понимается под версионностью кода.
Я про версии кода приложения. Вот у вас обновляется код wsgi-приложения, например, разработчик фиксит баг какой-то или меняет бизнес-логику. Обновить везде код и разом перезапустить — плохой вариант. Перезапускать просто всё по-очереди — вариант лучше, но есть некоторый риск в том, что у нас будут одновременно работать две версии кода (что, при смене бизнес-логики иногда бывает очень нехорошо). Было бы неплохо, если бы такой сервер (или шина) позволяли делать рестарт так, чтобы направлять новые запросы на обновлённые обработчики, давая старым обработчикам доработать своё, обновиться и перезапуститься.
Когда eigrad предложил написать прослойку, которой можно запустить любое wsgi приложение с помощью crew, мне эта идея сразу понравилась. Только представьте, запросы хлынут не на ваше wsgi приложение, а будут равномерно поступать через очередь на wsgi-worker.
Реализовать именно прослойку будет скорее всего достаточно просто, т.к. WSGI достаточно простой протокол. Меня лично здесь стали бы волновать другие вещи: логирование (должно быть централизовано или централизуемо), graceful restart и версионность кода.
Каждый раз, открывая подобные статьи, ожидаю увидеть крупным текстом: «Закрой хабр/жж/твиттер/вконтакте/другой_сайт и работай!», и каждый раз обманываюсь.
А потом окажется, что NukePiracy — это организация-ловушка, созданная ThePirateBay при поддержке Mega с целью сбора данных о людях и организациях, занимающихся разведкой против пиратов и лоббированием законов типа SOPA.
Вот и мне думается, что там один единственный дисплей и сверху прозрачные кнопки.
Если посмотреть на габариты, то можно предположить, что дисплей под кнопками имеет диагональ порядка 13 дюймов. При этом разрешение у него должно быть порядка 146 ppi (пересчитайте кто-нибудь, я, возможно, ничего не понимаю или путаю цифры), что далеко не Retina. В общем, что-то меня сильно смущает цена на данный продукт.
Мне кажется, что можно сделать накладную прозрачную «клаву» на айпад или другой планшет, у которой клавиши будут выпуклыми и покрытыми проводящим материалом с внутренней стороны. И оставалось бы дело только за специальным ПО. Не удивлюсь, если такие штуки уже существуют и продаются в китайских интернет-магазинах.
Может быть я это не заметил в статье, но у вас же есть таймауты для задач в очереди?
А, вот и про таймаут. Не очень понятно, что означает «обрабатываете сами», правда.
Кажется, я понял, в чём заключается предлагаемый подход. Согласен, он может применятся, хотя я предпочёл бы, чтобы фреймворк/сервер/шина умела решать это за меня.
WSGI-приложение — это тоже в принципе просто функция. Если вы хотите делать возможность подключения в качестве обработчиков wsgi-приложения на Django или других фреймворках, то, наверное, имеет смысл делать это не ради спортивного интереса, а чтобы разработчики могли этим пользоваться, не задумываясь о множестве деталей, типа логирования. С распределением нагрузки по серверам не так уж и плохо справляется nginx, так что тут непонятно, зачем придумывать ещё одну прослойку. Но вот чего реально не хватает — это возможности «из коробки» собирать логи, а главное, отчётов об ошибках, централизованно, без поиска по логам инстансов и привлечения сторонних лог-сервисов и лог-серверов.
Я про версии кода приложения. Вот у вас обновляется код wsgi-приложения, например, разработчик фиксит баг какой-то или меняет бизнес-логику. Обновить везде код и разом перезапустить — плохой вариант. Перезапускать просто всё по-очереди — вариант лучше, но есть некоторый риск в том, что у нас будут одновременно работать две версии кода (что, при смене бизнес-логики иногда бывает очень нехорошо). Было бы неплохо, если бы такой сервер (или шина) позволяли делать рестарт так, чтобы направлять новые запросы на обновлённые обработчики, давая старым обработчикам доработать своё, обновиться и перезапуститься.
Реализовать именно прослойку будет скорее всего достаточно просто, т.к. WSGI достаточно простой протокол. Меня лично здесь стали бы волновать другие вещи: логирование (должно быть централизовано или централизуемо), graceful restart и версионность кода.
Воообще, в переводах наверное было бы хорошо в заголовке явно автора указывать.
Если посмотреть на габариты, то можно предположить, что дисплей под кнопками имеет диагональ порядка 13 дюймов. При этом разрешение у него должно быть порядка 146 ppi (пересчитайте кто-нибудь, я, возможно, ничего не понимаю или путаю цифры), что далеко не Retina. В общем, что-то меня сильно смущает цена на данный продукт.
Мне кажется, что можно сделать накладную прозрачную «клаву» на айпад или другой планшет, у которой клавиши будут выпуклыми и покрытыми проводящим материалом с внутренней стороны. И оставалось бы дело только за специальным ПО. Не удивлюсь, если такие штуки уже существуют и продаются в китайских интернет-магазинах.
moodle.org