Честно говоря, по описанию проблем функционирования бота создается впечатление, что его писали какие-то начинающие студенты. Затыки при нагрузке «до 16 сообщений в секунду» это просто детский сад, не говоря уж о том, что «мы не могли исправить ботак, так как он был запущен и с ним общались люди».
У меня жили по 2-3 месяца, даже без граф.обоочек.
С readonly-root живут на улице уже более года, некоторые станции слеланы на «малине» — http://meteo38.ru/
В статье обойден вниманием тот самый момент, когда этот паскаль стал «турбо». То есть TurboPascal 2.0 был некоторое время чуть ли единственным продуктом, который позволял запускать скомпилированные программы и делать бинарники (в .com формате) прямо из редактора без запуска внешнего компиллятора. Это был огромный шаг в плане ускорения разработки, так как программы запускались с дискет и каждый прогон занимал целую вечность.
Насколько я помню, с версии 3.0 в ТурбоПаскале появился встроенный отладчик. Но только с версии 4.0 (скриншот в начале статьи), которая по интерфейсу полностью отличалось от предыдущей, мы получили то, что в последствии многие годы было стандартом де-факто «турбопаскаль».
Если найдутся желающие попробовать «настоящий турбопаскаль», то он есть здесь — http://penzin.info/retro/
Для описанного кейса вообще никаких блокчейнов не нужно — заказчика интересует (как обычно) только конечный результат, но никак не вся, непонятная ему, цепочка действий, которую он не может ни контролировать, ни даже просто адекватно оценить. И ведь подобная ситуация практически со всеми примерами.
IBM сильно пиарит блокчейн, но у них под этим лежит своя, причем, довольно специфическая задача с прицелом на сбыт массы ихнего железа в первую очередь. То есть это все интересно, но нас как-то не очень касается.
Во всей этой движухе (несомненно полезной!) вокруг блокчейнов удручает тот факт, что юзкейсы приходится высасывать из пальца и буквально силой «натягивать» на действительность.
Описанная здесь ситуация довольно сильно отличается от изначальной! :)
Вообще, готовые отлаженные СКУД с описанными выше функиями стоят на рынке вполне ощутимых денег, а человек делающий все это самостоятельно может смело выставлять почасовой ценник не меньше, чем какой-нибудь 1С-ник.
По опыту могу сказать, что не надо туда ставить разные «роутеры» — у них при интерсивной записи дохнет флэш.
Какой-нибудь одноплатник может быть более удобным, чем нетбук.
Лучше сразу ставить туда нормальную ОС, чтобы не париться с доработками/бэкапами/отчетами и т.п., так как 7 секунд оно будет грузиться или 20 — мало кого волнует в реальности (если свет выключали — то это надолго).
Занятно выглядит в этом плане Raspberry Pi, только основную флэшку надо в ридонли монтировать (а то сдохнет!).
В уличных условях тоже работает.
Про какую-то архитектуру здесь как раз говорить не приходится, так как вместо нее здесь мы видим множество телодвижений для взаимодействия с джанго-админкой.
Управление одним единственным процессом по хттп делается на Питоне строк в пару десятков строк не более:
— берете штатный сервер https://docs.python.org/3.4/library/http.server.html
— штатный json для параметров, чтобы было красиво https://docs.python.org/3.4/library/json.html
— пускаете цикл обработки в отдельной нити https://docs.python.org/3/library/threading.html
— через глобальную переменную передаете параметры из запроса в цикл.
Пол часа делов, и в результате один маленький файл на чистом питоне без зависимостей.
Если есть желание действительно подумать над архитектурой, а не над плясками вокруг джанго-админки, то попробуйте сделать корректную обработку очереди более, чем одним воркером — вот там уже есть над чем подумать!
Не могу здесь судить о целесообразности написания отдельного клиента для реализации нажатия пары кнопок.
Хотя, на мой взгляд то же самое было бы быстрее надежнее переносимее и безопаснее сделать на отдельной странице с несколькими строками джаваскрипта.
В Питоне нет разграничения доступа к членам класса, есть лишь некоторые достаточно условные соглашения.
Про специальные случаи обработки двойного подчеркивания написано здесь — https://www.python.org/dev/peps/pep-0008/
И это никак не то, что вы хотели.
Но больше всего отталкивает в Джанге — это обилие неочевиного спагетти-кода.
То есть когда я писал подобную вещь, у меня весь код многопоточного правильно синхронизированного обработчика очереди занял где-то около страницы на все про все. А тут ради элементарного действие столько писанины…
Нет, признание собственных недостатков — это правильно.
Но скажите, как вы выживаете?
Ведь заказчик уже наверняка давным-давно имеет сильное желание убить исполнителя, который медитирует на бордер-радиус, но не за пол года (!) не исправляет ошибку в логике приложения.
Бэкслэши в DOSе завел Гейтс, когда ему понадобились вложенные директории, а нормальный слэш у него уже был занят под ключи для команд, которые в свою очередь были сделаны совместимыми с 8-битной CP/M. По иронии судьбы спустя три десятка лет пхпшники сделали аналогичный dirty hack.
Вопрос относительно кругозора возник из-за довольно странного применения Django и еще более странного употребления термина «демон».
Чтобы прояснить ситуацию, не могли бы вы описать на словах исходную задачу, которую решали?
Если она, конечно, не была «написать что-нибудь обязательно на джанге».
Отдельно хотелось бы заметить, что в Питоне не стоит без особой необходимости начинать названия методов с подчеркивания, и особенно с двойного подчеркивания!
Извините, а в Итогах там тонкий троллинг насчет «других языков и технологий» или автор действительно обладает именно таким кругозором?
p.s.
Совет начинающим программистам —
Даже если вы виндузятник или пхпист, учитесь сразу пользоваться нормальным прямым слэшем — "/" (он же «дробь»), так как это традиционный способ разделения компонент в тексте, используемый человечеством уже не одну сотню лет. Обратный слэш "\" (он же «забой», хоть это и млао кто помнит) был придуман вовсе не для этого.
Это конечно, похвально, когда люди пятаются изучать что-либо новое. Но как-то надо быть чуть более самокритичным :)
У вас выбор получился не «абсолютно правильным», а просто первым попавшимся.
PostGIS довольно хооршо зарекомендовал себя за многие годы, но сейчас редкая СУБД не умеет работать с GoeJSON'ом, а формулы расчета рассояний на сфере гуглятся на раз.
Рекомендую просто для расширения кругозора посмотреть насколько изящнее выглядит ваш запрос в терминах RethinkDB, почитать про аналогичные индексы 2d и 2dsphere в MongoDB — там прямо в доке расписано, как устроены эти индексы и чем отличаются.
Тоже присматриваюсь к этому чипу. Как у него с энергопотреблнием в реальных условиях? Интересуюсь в плане возможности запитать от солнечной энергии.
В качестве хобби имею некоторый опыт в построении сети не «домашних», а как раз-таки, весьма «уличных» метеостанций — http://meteo38.ru, http://angara.ws — если кому интересно, могу поделиться опытом эксплуатации разных видов arduino и raspberry pi в условия от -35 до +35 градусов.
Этот параметр не зря называется «относительная влажность», так как напрямую зависит от температуры. То есть, если вы нагреете кусок воздуха (из улицы в комнате, например), то относительная влажность его уменьшится.
Почему управляющая система способна заносить карту в стоплист по определенному событию или условию?
Или почему энергичный телесюжет с нарезкой из камер наблюдения, полицейских машин и преступников в наручниках уменьшает убытки от фрода на порядок лучше многих сугубо технических решений?
На практике фродовое приложение моментом выкинут из стора, как только это понадобится. На официальное приложение можно напустить обфускатор и оно перестанет ломаться одним if'ом. Ради чего потом кому-то надо будет тратить немало времени, чтобы сломать его? Только ради любви к искусству трудиться более одного раза обычно лень.
Это я все к тому, что разработчикам системы все эти вещи известны лучше, чем нам всем вместе взятым, а риски давно известны и оценены.
Хорошо, опишите тогда возможный сценарий зарабатывания заметных денег на этом.
Ключевые моменты:
— деньги нельзя получить из системы, их можно только сэкономить,
— онлайновый дабл-спенд пресекается на раз-два, причем, с перспективой маскишоу и последствиями,
— офлайновый дабл-спенд ограничен временем (5 дней, если не ошибаюсь) и он все-равно виден в логах по результатам дня
— пользовательское телефонное приложение ломается всегда по определению, но сделать в очередном релизе привязку по номеру телефона не так уж сложно.
С readonly-root живут на улице уже более года, некоторые станции слеланы на «малине» — http://meteo38.ru/
Я просто перешел по ссылке в начале статьи, потыкал в менюшку, пробовал найти банкоматы по своему адресу.
Насколько я помню, с версии 3.0 в ТурбоПаскале появился встроенный отладчик. Но только с версии 4.0 (скриншот в начале статьи), которая по интерфейсу полностью отличалось от предыдущей, мы получили то, что в последствии многие годы было стандартом де-факто «турбопаскаль».
Если найдутся желающие попробовать «настоящий турбопаскаль», то он есть здесь — http://penzin.info/retro/
Скриншотик закиньте сюда, если не сложно :)
IBM сильно пиарит блокчейн, но у них под этим лежит своя, причем, довольно специфическая задача с прицелом на сбыт массы ихнего железа в первую очередь. То есть это все интересно, но нас как-то не очень касается.
Вообще, готовые отлаженные СКУД с описанными выше функиями стоят на рынке вполне ощутимых денег, а человек делающий все это самостоятельно может смело выставлять почасовой ценник не меньше, чем какой-нибудь 1С-ник.
По опыту могу сказать, что не надо туда ставить разные «роутеры» — у них при интерсивной записи дохнет флэш.
Какой-нибудь одноплатник может быть более удобным, чем нетбук.
Лучше сразу ставить туда нормальную ОС, чтобы не париться с доработками/бэкапами/отчетами и т.п., так как 7 секунд оно будет грузиться или 20 — мало кого волнует в реальности (если свет выключали — то это надолго).
Занятно выглядит в этом плане Raspberry Pi, только основную флэшку надо в ридонли монтировать (а то сдохнет!).
В уличных условях тоже работает.
Управление одним единственным процессом по хттп делается на Питоне строк в пару десятков строк не более:
— берете штатный сервер https://docs.python.org/3.4/library/http.server.html
— штатный json для параметров, чтобы было красиво https://docs.python.org/3.4/library/json.html
— пускаете цикл обработки в отдельной нити https://docs.python.org/3/library/threading.html
— через глобальную переменную передаете параметры из запроса в цикл.
Пол часа делов, и в результате один маленький файл на чистом питоне без зависимостей.
Если есть желание действительно подумать над архитектурой, а не над плясками вокруг джанго-админки, то попробуйте сделать корректную обработку очереди более, чем одним воркером — вот там уже есть над чем подумать!
Хотя, на мой взгляд то же самое было бы быстрее надежнее переносимее и безопаснее сделать на отдельной странице с несколькими строками джаваскрипта.
В Питоне нет разграничения доступа к членам класса, есть лишь некоторые достаточно условные соглашения.
Про специальные случаи обработки двойного подчеркивания написано здесь — https://www.python.org/dev/peps/pep-0008/
И это никак не то, что вы хотели.
Но больше всего отталкивает в Джанге — это обилие неочевиного спагетти-кода.
То есть когда я писал подобную вещь, у меня весь код многопоточного правильно синхронизированного обработчика очереди занял где-то около страницы на все про все. А тут ради элементарного действие столько писанины…
Но скажите, как вы выживаете?
Ведь заказчик уже наверняка давным-давно имеет сильное желание убить исполнителя, который медитирует на бордер-радиус, но не за пол года (!) не исправляет ошибку в логике приложения.
Вопрос относительно кругозора возник из-за довольно странного применения Django и еще более странного употребления термина «демон».
Чтобы прояснить ситуацию, не могли бы вы описать на словах исходную задачу, которую решали?
Если она, конечно, не была «написать что-нибудь обязательно на джанге».
Отдельно хотелось бы заметить, что в Питоне не стоит без особой необходимости начинать названия методов с подчеркивания, и особенно с двойного подчеркивания!
p.s.
Совет начинающим программистам —
Даже если вы виндузятник или пхпист, учитесь сразу пользоваться нормальным прямым слэшем — "/" (он же «дробь»), так как это традиционный способ разделения компонент в тексте, используемый человечеством уже не одну сотню лет. Обратный слэш "\" (он же «забой», хоть это и млао кто помнит) был придуман вовсе не для этого.
У вас выбор получился не «абсолютно правильным», а просто первым попавшимся.
PostGIS довольно хооршо зарекомендовал себя за многие годы, но сейчас редкая СУБД не умеет работать с GoeJSON'ом, а формулы расчета рассояний на сфере гуглятся на раз.
Рекомендую просто для расширения кругозора посмотреть насколько изящнее выглядит ваш запрос в терминах RethinkDB, почитать про аналогичные индексы 2d и 2dsphere в MongoDB — там прямо в доке расписано, как устроены эти индексы и чем отличаются.
В качестве хобби имею некоторый опыт в построении сети не «домашних», а как раз-таки, весьма «уличных» метеостанций — http://meteo38.ru, http://angara.ws — если кому интересно, могу поделиться опытом эксплуатации разных видов arduino и raspberry pi в условия от -35 до +35 градусов.
Тем более, когда факт и умысел налицо.
Почему управляющая система способна заносить карту в стоплист по определенному событию или условию?
Или почему энергичный телесюжет с нарезкой из камер наблюдения, полицейских машин и преступников в наручниках уменьшает убытки от фрода на порядок лучше многих сугубо технических решений?
На практике фродовое приложение моментом выкинут из стора, как только это понадобится. На официальное приложение можно напустить обфускатор и оно перестанет ломаться одним if'ом. Ради чего потом кому-то надо будет тратить немало времени, чтобы сломать его? Только ради любви к искусству трудиться более одного раза обычно лень.
Это я все к тому, что разработчикам системы все эти вещи известны лучше, чем нам всем вместе взятым, а риски давно известны и оценены.
Ключевые моменты:
— деньги нельзя получить из системы, их можно только сэкономить,
— онлайновый дабл-спенд пресекается на раз-два, причем, с перспективой маскишоу и последствиями,
— офлайновый дабл-спенд ограничен временем (5 дней, если не ошибаюсь) и он все-равно виден в логах по результатам дня
— пользовательское телефонное приложение ломается всегда по определению, но сделать в очередном релизе привязку по номеру телефона не так уж сложно.