Comments 33
Извините, а в Итогах там тонкий троллинг насчет «других языков и технологий» или автор действительно обладает именно таким кругозором?
p.s.
Совет начинающим программистам —
Даже если вы виндузятник или пхпист, учитесь сразу пользоваться нормальным прямым слэшем — "/" (он же «дробь»), так как это традиционный способ разделения компонент в тексте, используемый человечеством уже не одну сотню лет. Обратный слэш "\" (он же «забой», хоть это и млао кто помнит) был придуман вовсе не для этого.
p.s.
Совет начинающим программистам —
Даже если вы виндузятник или пхпист, учитесь сразу пользоваться нормальным прямым слэшем — "/" (он же «дробь»), так как это традиционный способ разделения компонент в тексте, используемый человечеством уже не одну сотню лет. Обратный слэш "\" (он же «забой», хоть это и млао кто помнит) был придуман вовсе не для этого.
Для троллинга есть другие ресурсы, а это Хабр.
На счет кругозора — все на свете уметь нельзя. А я не имею привычки «авторитетно заявлять» о тех отраслях \ технологиях, о которых знаю только по наслышке.
К примеру, возьмем стандартный способ разработки под Android — не имея опыта создания приложений в Android Studio я не представляю, сколько времени уйдет на создание такого примитивного приложения с нуля. Включая установку и настройку среды.
Вот и возник вопрос к коллегам, имеющим опыт — возможно они смогут предложить такую же быструю реализацию аналогичной архитектуры, используя другие технологии.
P.S. За совет — спасибо, начинающие программисты учтут. Все никак не могу отделаться от дурной привычки, которая въелась еще со времен DOS. Хоть и безболезненно переключаюсь на "/" в Linux-консоли.
На счет кругозора — все на свете уметь нельзя. А я не имею привычки «авторитетно заявлять» о тех отраслях \ технологиях, о которых знаю только по наслышке.
К примеру, возьмем стандартный способ разработки под Android — не имея опыта создания приложений в Android Studio я не представляю, сколько времени уйдет на создание такого примитивного приложения с нуля. Включая установку и настройку среды.
Вот и возник вопрос к коллегам, имеющим опыт — возможно они смогут предложить такую же быструю реализацию аналогичной архитектуры, используя другие технологии.
P.S. За совет — спасибо, начинающие программисты учтут. Все никак не могу отделаться от дурной привычки, которая въелась еще со времен DOS. Хоть и безболезненно переключаюсь на "/" в Linux-консоли.
Бэкслэши в DOSе завел Гейтс, когда ему понадобились вложенные директории, а нормальный слэш у него уже был занят под ключи для команд, которые в свою очередь были сделаны совместимыми с 8-битной CP/M. По иронии судьбы спустя три десятка лет пхпшники сделали аналогичный dirty hack.
Вопрос относительно кругозора возник из-за довольно странного применения Django и еще более странного употребления термина «демон».
Чтобы прояснить ситуацию, не могли бы вы описать на словах исходную задачу, которую решали?
Если она, конечно, не была «написать что-нибудь обязательно на джанге».
Отдельно хотелось бы заметить, что в Питоне не стоит без особой необходимости начинать названия методов с подчеркивания, и особенно с двойного подчеркивания!
Вопрос относительно кругозора возник из-за довольно странного применения Django и еще более странного употребления термина «демон».
Чтобы прояснить ситуацию, не могли бы вы описать на словах исходную задачу, которую решали?
Если она, конечно, не была «написать что-нибудь обязательно на джанге».
Отдельно хотелось бы заметить, что в Питоне не стоит без особой необходимости начинать названия методов с подчеркивания, и особенно с двойного подчеркивания!
Чтобы прояснить ситуацию, не могли бы вы описать на словах исходную задачу, которую решали?
Все достаточно банально — доработка существующего проекта на Django и две порции требований. 1-я порция — реализовать управление скриптом из админки. После завершения работ над 1-й, поступила 2-я порция — сделать мобильный клиент.
Отдельно хотелось бы заметить, что в Питоне не стоит без особой необходимости начинать названия методов с подчеркивания, и особенно с двойного подчеркивания!
А вот отсюда, пожалуйста, поподробнее. Если не использовать подчеркивания, то какая альтернатива для разграничения доступа членам класса?
… и еще более странного употребления термина «демон».
Может быть, не совсем подходящий термин. Предлагайте свой вариант.
Не могу здесь судить о целесообразности написания отдельного клиента для реализации нажатия пары кнопок.
Хотя, на мой взгляд то же самое было бы быстрее надежнее переносимее и безопаснее сделать на отдельной странице с несколькими строками джаваскрипта.
В Питоне нет разграничения доступа к членам класса, есть лишь некоторые достаточно условные соглашения.
Про специальные случаи обработки двойного подчеркивания написано здесь — https://www.python.org/dev/peps/pep-0008/
И это никак не то, что вы хотели.
Но больше всего отталкивает в Джанге — это обилие неочевиного спагетти-кода.
То есть когда я писал подобную вещь, у меня весь код многопоточного правильно синхронизированного обработчика очереди занял где-то около страницы на все про все. А тут ради элементарного действие столько писанины…
Хотя, на мой взгляд то же самое было бы быстрее надежнее переносимее и безопаснее сделать на отдельной странице с несколькими строками джаваскрипта.
В Питоне нет разграничения доступа к членам класса, есть лишь некоторые достаточно условные соглашения.
Про специальные случаи обработки двойного подчеркивания написано здесь — https://www.python.org/dev/peps/pep-0008/
И это никак не то, что вы хотели.
Но больше всего отталкивает в Джанге — это обилие неочевиного спагетти-кода.
То есть когда я писал подобную вещь, у меня весь код многопоточного правильно синхронизированного обработчика очереди занял где-то около страницы на все про все. А тут ради элементарного действие столько писанины…
Не могу здесь судить о целесообразности написания отдельного клиента для реализации нажатия пары кнопок.Мыслите глобальнее — кнопок может быть произвольное количество. А для того, чтобы понять суть архитектуры, достаточно примера на одной кнопке. Так что, здесь я даже «перестарался» :)
Про специальные случаи обработки двойного подчеркивания написано здесь — https://www.python.org/dev/peps/pep-0008/За это — спасибо. Понял, что происходит на самом деле.
И это никак не то, что вы хотели.Хотя тут же пишут: «If your class is intended to be subclassed, and you have attributes that you do not want subclasses to use, consider naming them with double leading underscores and no trailing underscores.»
Но больше всего отталкивает в Джанге — это обилие неочевиного спагетти-кода.Это тема для отдельной дискуссии, и туда можно будет подтянуть еще парочку технологий и языков.
А тут ради элементарного действие столько писанины…Вот и мы и вернулись к тому, с чего начали — к моему, как вы выразились, «тонкому троллингу». Так, собственно, как реализовать подобную архитектуру с меньшим количеством писанины? Не обязательно на Python.
Про какую-то архитектуру здесь как раз говорить не приходится, так как вместо нее здесь мы видим множество телодвижений для взаимодействия с джанго-админкой.
Управление одним единственным процессом по хттп делается на Питоне строк в пару десятков строк не более:
— берете штатный сервер 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://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
— через глобальную переменную передаете параметры из запроса в цикл.
Пол часа делов, и в результате один маленький файл на чистом питоне без зависимостей.
Если есть желание действительно подумать над архитектурой, а не над плясками вокруг джанго-админки, то попробуйте сделать корректную обработку очереди более, чем одним воркером — вот там уже есть над чем подумать!
Про какую-то архитектуру здесь как раз говорить не приходится, так как вместо нее здесь мы видим множество телодвижений для взаимодействия с джанго-админкой.Почему же так категорично? Если абстрагироваться от Django (и от всего остального), получаем:
- клиент — посылает команды;
- сервер — принимает команды, ставит в очередь;
- очередь;
- скрипт — выбирает команды из очереди.
Или это тоже нельзя назвать архитектурой?
В моем случае, для реализации очереди используется БД. Если я правильно понял, вы предлагаете архитектуру, в которой очередь хранится не в БД, а в памяти, так?
Использовать стандартные IPC, наверное религия не позволяет?
TL;DR:
«как я научился из джанги посылать команды в терминал».
скучно, сэр.
«как я научился из джанги посылать команды в терминал».
скучно, сэр.
Сделайте нормальный интерфейс, не позорьте Kivy!
Помнится мне что подобные штуки для администрирования раньше делали через jabber, а теперь и telegram сгодится. Вроде как для админа gui не нужен.
Согласен, хороший вариант. Если допустимо использование сторонних сервисов, получаем минус Android-app и минус админка.
Не спорю) Хоть и не админ, предпочитаю больше консоль, чем GUI. Когда на рабочем месте. А с мобильного девайса удобнее и быстрее сделать операцию в один клик, чем подключаться к терминалу.
Вроде как для админа gui не нужен.
Не спорю) Хоть и не админ, предпочитаю больше консоль, чем GUI. Когда на рабочем месте. А с мобильного девайса удобнее и быстрее сделать операцию в один клик, чем подключаться к терминалу.
UFO just landed and posted this here
Не знаком с этими технологиями, возьму на заметку. Если в двух словах — в чем преимущество?
UFO just landed and posted this here
Понял о чем речь, но не думаю, что для данной архитектуры это будет помехой:
Узким местом здесь является обращение к БД. Но ее используем для реализации очереди задач, что позволяет достигнуть асинхронности. Если мы можем в реализации отказаться от очереди (админкой можно пожертвовать), то — да, БД действительно будет оверхэдом.
Проблемы могут возникнуть разве что при использовании в промышленных масштабах, при огромном количестве соединений — здесь недостатки Django дадут о себе знать.
В целом — спасибо за совет, Tornado — интересное решение, нужно будет повнимательней рассмотреть его под микроскопом.
- клиент не держит соединение открытым до завершения выполнения команды — он отправляет запрос на добавление команды в очередь, а далее — с периодичностью в одну секунду отправляет запросы для проверки состояния;
- запросы от клиента — довольно легковесные операции (добавить запись в БД, получить запись по ID);
- демон работает отдельным процессом и взаимодействует с Django посредством ORM — его работа не зависит от Django-сервера.
Узким местом здесь является обращение к БД. Но ее используем для реализации очереди задач, что позволяет достигнуть асинхронности. Если мы можем в реализации отказаться от очереди (админкой можно пожертвовать), то — да, БД действительно будет оверхэдом.
Проблемы могут возникнуть разве что при использовании в промышленных масштабах, при огромном количестве соединений — здесь недостатки Django дадут о себе знать.
В целом — спасибо за совет, Tornado — интересное решение, нужно будет повнимательней рассмотреть его под микроскопом.
Для подобных задач я использую бота для Telegram. Самого бота можете писать на практически любом, удобном вам языке, ну а сам Telegram уже готов на все популярные платформы.
Ответ выше.
Тот кто знает C# могут сделать Android и/или IOS приложение на Xamarin.
Серверную часть на VS.
Серверную часть на VS.
Ок, сколько времени займет разработка?
Смотря что вы от этой разработки хотите.
Hello world в телеграмм на с++ займёт 2-5 минут(сам проверял)
остальное по желанию и возможностям.
из печального опыта: уж казалось бы, ну сколько можно потратить времени на систему учета «Прохода сотрудников в столовую по rfid-карточкам»? День, неделя, месяц?
я седьмой месяц пилю уже 5ю версию на bash,php,js,html,css…
Ну ладно бы заказчики были неадекватные и с придирками, так НЕТ, они говорят: «ну нас в принципе всё устраивает, кроме пары багов в логике первых версий».
Всё дело в том что я над каждой строчкой CSS могу часами медитировать:
то border-radius какой-то не такой
то цветовая гамма, хоть глаз выколи
а вот этот кусок логики лучше на php оставить или на js переложить?
а вот эти строки в bash работают чуть быстрее, чем первая версия, но выглядят ужасно
3 часа искал инфу как в sqlite hex в int получить, пока не узнал, что это такая ЛЁГКАЯ эмбедед БД, что такой изврат ей ни к чему, нету его в коде sqlite. посоветовали писать своё расширение.
и так в каждой мелочи :( знал бы что из этого будет… дизайн бы сразу отдал дизайнеру, логику архитектору, а код бы настрочил за неделю с тестами.
Hello world в телеграмм на с++ займёт 2-5 минут(сам проверял)
остальное по желанию и возможностям.
из печального опыта: уж казалось бы, ну сколько можно потратить времени на систему учета «Прохода сотрудников в столовую по rfid-карточкам»? День, неделя, месяц?
я седьмой месяц пилю уже 5ю версию на bash,php,js,html,css…
Ну ладно бы заказчики были неадекватные и с придирками, так НЕТ, они говорят: «ну нас в принципе всё устраивает, кроме пары багов в логике первых версий».
Всё дело в том что я над каждой строчкой CSS могу часами медитировать:
то border-radius какой-то не такой
то цветовая гамма, хоть глаз выколи
а вот этот кусок логики лучше на php оставить или на js переложить?
а вот эти строки в bash работают чуть быстрее, чем первая версия, но выглядят ужасно
3 часа искал инфу как в sqlite hex в int получить, пока не узнал, что это такая ЛЁГКАЯ эмбедед БД, что такой изврат ей ни к чему, нету его в коде sqlite. посоветовали писать своё расширение.
и так в каждой мелочи :( знал бы что из этого будет… дизайн бы сразу отдал дизайнеру, логику архитектору, а код бы настрочил за неделю с тестами.
Нет, признание собственных недостатков — это правильно.
Но скажите, как вы выживаете?
Ведь заказчик уже наверняка давным-давно имеет сильное желание убить исполнителя, который медитирует на бордер-радиус, но не за пол года (!) не исправляет ошибку в логике приложения.
Но скажите, как вы выживаете?
Ведь заказчик уже наверняка давным-давно имеет сильное желание убить исполнителя, который медитирует на бордер-радиус, но не за пол года (!) не исправляет ошибку в логике приложения.
Но скажите, как вы выживаете?
лучше Вам этого не знать
заказчик давным-давно имеет сильное желание убить исполнителя
печальная констатация факта :(
а вообще всё пошло не так, когда вместо ТЗ мне дали пачку 100 rfid карт с фразой:
1) система должна просто фиксировать время прохода этих карт
2) в любой момент система должна вывести сумму проходов конкретной карты в указанный период
всё.
Неделю их мучил, что это явно не полная инфа для ТЗ… вообщем остальное ТЗ пришлось писать самому, а я не бог и не могу предусмотреть всех очевидных и не очень очевидных подводных камней, например:
— система должна управлять турникетом, т.е. давать ему сигнал на открытие
— необходима возможность блокировать карту
— пользователь может «потерять» карту, просит новую, а оказывается, что он прежнюю карту передал другому лицу
— карт оказалось не 100, а уже за 600 перевалило
— 1я версия работала на роутере mr3020: OpenWrt Atheros AR9331@400MHz 32MБ-рам 4MБ nand-флэш + 4ГБ usb-flash
— 5я уже работает на нетбуке 2ядра 1,66ГГц 1ГБ-рам 500ГБ хдд + OpenWrt грузится с usb-flash за 7 секунд
— пользователей нужно «сортировать» в группы
ФАТАЛИТИ: нужно считать не проходы КАРТ — а проходы ПОЛЬЗОВАТЕЛЯ, у которого в профайле может быть и несколько карт
Мелкие «баги» логики были устранены еще в 1й-2й версиях, но вот учёт не по картам, а по пользователям в корне ломает всю логику. Потому уже и 5ю версию пилю. Да еще и пользователей стало явно больше чем может «переварить» малыш mr3020.
Спросите почему не взял одну из 100500 готовых систем? Да потому что: а чё там считать-то 100 карт, сам справлюсь + спортивный интерес.
Почему не бросил проект, когда ТЗ начало «уходить в сторону»? Принципиальная упёртость: меня так просто не сломать, победа будет за мной!
На всё про всё осталось 1-2 недели, далее за мной действительно «придут» гневные заказчики других проектов, т.е. мотивация более чем существенная, а первый заказчик к счастью не скупой и платит за все эти «форс-мажоры», ведь при нормальном ТЗ всё могло сложится иначе, по крайней мере быстрее.
В редкие часы отдыха продумываю план статьи для хабра про эту «чудо-систему».
Описанная здесь ситуация довольно сильно отличается от изначальной! :)
Вообще, готовые отлаженные СКУД с описанными выше функиями стоят на рынке вполне ощутимых денег, а человек делающий все это самостоятельно может смело выставлять почасовой ценник не меньше, чем какой-нибудь 1С-ник.
По опыту могу сказать, что не надо туда ставить разные «роутеры» — у них при интерсивной записи дохнет флэш.
Какой-нибудь одноплатник может быть более удобным, чем нетбук.
Лучше сразу ставить туда нормальную ОС, чтобы не париться с доработками/бэкапами/отчетами и т.п., так как 7 секунд оно будет грузиться или 20 — мало кого волнует в реальности (если свет выключали — то это надолго).
Занятно выглядит в этом плане Raspberry Pi, только основную флэшку надо в ридонли монтировать (а то сдохнет!).
В уличных условях тоже работает.
Вообще, готовые отлаженные СКУД с описанными выше функиями стоят на рынке вполне ощутимых денег, а человек делающий все это самостоятельно может смело выставлять почасовой ценник не меньше, чем какой-нибудь 1С-ник.
По опыту могу сказать, что не надо туда ставить разные «роутеры» — у них при интерсивной записи дохнет флэш.
Какой-нибудь одноплатник может быть более удобным, чем нетбук.
Лучше сразу ставить туда нормальную ОС, чтобы не париться с доработками/бэкапами/отчетами и т.п., так как 7 секунд оно будет грузиться или 20 — мало кого волнует в реальности (если свет выключали — то это надолго).
Занятно выглядит в этом плане Raspberry Pi, только основную флэшку надо в ридонли монтировать (а то сдохнет!).
В уличных условях тоже работает.
Мы для управления устройствами на ESP8266.ru сделали IoT Manager для телефончика. Работает по MQTT.
Пользователи не только рулят устройствами, но и мониторят сервера.
Пользователи не только рулят устройствами, но и мониторят сервера.
Sign up to leave a comment.
Пульт управления серверным демоном своими руками