ага, просто записывать координаты каждого клика и отправлять перед уходом со страницы. Ну или записывать в localStorage, websql, indexedDB... и отправлять в момент, когда пользователь покидает непосредственно админку.
Всеми руками за Bitbucket, правда статистика(по активности разрабов, скачиваниям и т.п.) там практически отсутствует. И оф. сайт последнее время конкретно загружен. Плюс ссылку для скачивания на главную проекта придется выносить самостоятельно(в readme.md). Во всем остальном весьма удобен - API, задачи, вики, группы.
ну, так то да. Но тут все зависит от того что за "пульт". Может выйти так, что геморроя с его подключением будет уйма. А так то, можно, конечно и его подключить. Например если вольтаж неподходит придется делать повышать его или понижать, если частота не подходит придется придумывать как сделать нужную частоту, или например вообще нужно выдавать гармонические колебания. Просто одно подключается "всунул и поехало", а другое много сложнее, но подключить можно все.
Выучивается очень быстро. Несколько дней и вы уже его знаете(не наизусть конечно). Он написан очень хорошо и все интересующие вопросы можно легко решить чтением исходного кода.
тогда уж всю страницу уменьшать, да еще и не монотонно, а с большей интенсивностью к положению мыши. Хм, а ведь это довольно крутой эффект. Надо будет попробовать, если это возможно вообще)
я сейчас нашел для себя формат CBOR он похож на msgpack , но в отличие от него работает и работает быстрее. Да и еще, он предоставляет возможность удобного расширения функционала.
# Останавливаем чистильщик, если чистить нечего
if len(self.SessionsRestore) < 1:
break
Это штука останавливает вечный цикл, тем самым завершая работу функции. А когда код функции выполнен, поток, в котором эта функция была запущена, так же уничтожается. Это сделано для того, чтобы цикл вместе с потоком не работали в пустую. Зачем проходить по пустому списку (len(self.SessionsRestore) < 1) , да еще и в отдельном потоке? Поэтому я запускаю поток и цикл в нем, только при наличии смысла(непустого self.SessionsRestore). Вот собственно в этом и есть суть этой конструкции.
Насчет вашего примера: то что он добавляет только один раз это понятно. Мне в принципе без разницы, можно и так, а можно и периодически запускать, а при опустошении хранилища останавливать.
Мне интересно что быстрее) Отдельный поток или через ioloop . Чтож, наверно придется проводить тесты. Но думаю что отдельный поток быстрее, поэтому пока сделал отдельным потоком.
саму clear_sessions_restore() сделал не методом класса, а обычной функций, отдельно от класса. Содержимое не менял, она так же просто завершает "вечный" цикл, если хранилище app.SessionsRestore пустое. таким образом "убивая" себя вместе с потоком.
Хм, не знаю. Это получается не отдельный поток, а просто вклиниваемся в "асинхронную модель" торнады. В прочем, возможно это даже производительнее, чем делать отдельный поток. Не знаю.
В прочем, спасибо за ответ. Отмечу решением.
