Комментарии / Профиль ophermit / Хабр

Python developer

Профиль Публикации 4Комментарии 32Закладки 18

Космическая ошибка: $370 000 000 за Integer overflow

ophermit 16 авг 2016 в 23:10

[Dan Simmons mode]
Не иначе, как происки ИскИнов. Теперь будет принято однозначное решение, дабы исключить «человеческий фактор».
[/Dan Simmons mode].

P.S.

Чтобы штурмовать небеса, нужно хорошо знать язык Ада.

Как ни крути. Спасибо за отличную статью, и за шикарную цитату, конечно!

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 8 авг 2016 в 16:52

Про какую-то архитектуру здесь как раз говорить не приходится, так как вместо нее здесь мы видим множество телодвижений для взаимодействия с джанго-админкой.

Почему же так категорично? Если абстрагироваться от Django (и от всего остального), получаем:

клиент — посылает команды;
сервер — принимает команды, ставит в очередь;
очередь;
скрипт — выбирает команды из очереди.

Или это тоже нельзя назвать архитектурой?

В моем случае, для реализации очереди используется БД. Если я правильно понял, вы предлагаете архитектуру, в которой очередь хранится не в БД, а в памяти, так?

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 8 авг 2016 в 09:31

Не могу здесь судить о целесообразности написания отдельного клиента для реализации нажатия пары кнопок.

Мыслите глобальнее — кнопок может быть произвольное количество. А для того, чтобы понять суть архитектуры, достаточно примера на одной кнопке. Так что, здесь я даже «перестарался» :)

Про специальные случаи обработки двойного подчеркивания написано здесь — 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.

Посмотреть

Ответы на вопросы с PyObject. Часть 2

ophermit 7 авг 2016 в 18:42

И вот тут, в случае неудачи, в дело вступает грязный хак. Я так и не смог придумать, как исключить возможность рекурсии, потому что необходимо проверить наличие атрибута get_KEY, которое происходит через вызов __getattr__ объекта

А как на счет такой реализации?

class XDictAttr(dict):
    """
    >>> class X(XDictAttr):
    ...     def get_foo(self):
    ...         return 5
    ...     def get_bar(self):
    ...         return 12
    ...     def get_get_z(self):
    ...         return 42
    ...     def get_get_get_get_get_foo(self):
    ...         return 4242

    >>> x = X({'one': 1, 'two': 2, 'three': 3})
    >>> x
    X: {'one': 1, 'three': 3, 'two': 2}
    >>> x['one']
    1
    >>> x.three
    3
    >>> x.bar
    12
    >>> x['foo']
    5
    >>> x.get('foo', 'missing')
    5
    >>> x.get('bzz', 'missing')
    'missing'
    >>> x.get_bar()
    12
    >>> x.get_foz()
    Traceback (most recent call last):
    ...
    AttributeError
    >>> x.get_get_z()
    42
    >>> x.get('get_z')
    42
    >>> x.get_z
    42
    >>> x.get_get_get_get_get_foo()
    4242
    >>> x.get_get_get_get_foo
    4242
    >>> x.get('get_get_get_get_foo')
    4242
    """

    def __repr__(self):
        return '%s: %s' % (self.__class__.__name__, super(XDictAttr, self).__repr__())

    def _get_attr_with_prefix(self, attr):
        if hasattr(self, 'get_%s' % attr):
            return getattr(self, 'get_%s' % attr)()
        else:
            raise AttributeError

    def __getattr__(self, attr):
        try:
            return self._get_attr_with_prefix(attr)
        except AttributeError:
            try:
                return super(XDictAttr, self).__getitem__(attr)
            except KeyError:
                raise AttributeError

    def __getitem__(self, key):
        try:
            return self._get_attr_with_prefix(key)
        except AttributeError:
            return super(XDictAttr, self).__getitem__(key)

    def get(self, key, default=None):
        try:
            return self._get_attr_with_prefix(key)
        except AttributeError:
            return super(XDictAttr, self).get(key, default)

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 6 авг 2016 в 14:20

Чтобы прояснить ситуацию, не могли бы вы описать на словах исходную задачу, которую решали?

Все достаточно банально — доработка существующего проекта на Django и две порции требований. 1-я порция — реализовать управление скриптом из админки. После завершения работ над 1-й, поступила 2-я порция — сделать мобильный клиент.

Отдельно хотелось бы заметить, что в Питоне не стоит без особой необходимости начинать названия методов с подчеркивания, и особенно с двойного подчеркивания!

А вот отсюда, пожалуйста, поподробнее. Если не использовать подчеркивания, то какая альтернатива для разграничения доступа членам класса?

… и еще более странного употребления термина «демон».

Может быть, не совсем подходящий термин. Предлагайте свой вариант.

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 5 авг 2016 в 23:23

Понял о чем речь, но не думаю, что для данной архитектуры это будет помехой:

клиент не держит соединение открытым до завершения выполнения команды — он отправляет запрос на добавление команды в очередь, а далее — с периодичностью в одну секунду отправляет запросы для проверки состояния;
запросы от клиента — довольно легковесные операции (добавить запись в БД, получить запись по ID);
демон работает отдельным процессом и взаимодействует с Django посредством ORM — его работа не зависит от Django-сервера.

Узким местом здесь является обращение к БД. Но ее используем для реализации очереди задач, что позволяет достигнуть асинхронности. Если мы можем в реализации отказаться от очереди (админкой можно пожертвовать), то — да, БД действительно будет оверхэдом.

Проблемы могут возникнуть разве что при использовании в промышленных масштабах, при огромном количестве соединений — здесь недостатки Django дадут о себе знать.

В целом — спасибо за совет, Tornado — интересное решение, нужно будет повнимательней рассмотреть его под микроскопом.

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 5 авг 2016 в 18:33

Ок, сколько времени займет разработка?

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 5 авг 2016 в 18:30

Так выглядит быстро разработанный рабочий прототип для наглядного примера, не претендующий на коммерческий продукт. И я по-прежнему не вижу предлагаемых вариантов. Пожалуйста, конструктив в студию.

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 5 авг 2016 в 18:21

Ответ выше.

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 5 авг 2016 в 18:20

Не знаком с этими технологиями, возьму на заметку. Если в двух словах — в чем преимущество?

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 5 авг 2016 в 17:57

Согласен, хороший вариант. Если допустимо использование сторонних сервисов, получаем минус Android-app и минус админка.

Вроде как для админа gui не нужен.

Не спорю) Хоть и не админ, предпочитаю больше консоль, чем GUI. Когда на рабочем месте. А с мобильного девайса удобнее и быстрее сделать операцию в один клик, чем подключаться к терминалу.

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 5 авг 2016 в 16:57

Плюс одна идея в развитие проекта) А можно пример, как по-вашему должен выглядеть такой интерфейс? У меня, как back-end dev'a, с дизайном интерфейсов как-то не очень хорошо складывается.

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 5 авг 2016 в 15:48

Вы забыли о мобильном приложении, сэр. Абзац 3, строка 2.

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 5 авг 2016 в 15:40

В связке Android-приложение — серверный демон? А можно поподробнее?

Посмотреть

Пульт управления серверным демоном своими руками

ophermit 5 авг 2016 в 15:36

Для троллинга есть другие ресурсы, а это Хабр.

На счет кругозора — все на свете уметь нельзя. А я не имею привычки «авторитетно заявлять» о тех отраслях \ технологиях, о которых знаю только по наслышке.

К примеру, возьмем стандартный способ разработки под Android — не имея опыта создания приложений в Android Studio я не представляю, сколько времени уйдет на создание такого примитивного приложения с нуля. Включая установку и настройку среды.

Вот и возник вопрос к коллегам, имеющим опыт — возможно они смогут предложить такую же быструю реализацию аналогичной архитектуры, используя другие технологии.

P.S. За совет — спасибо, начинающие программисты учтут. Все никак не могу отделаться от дурной привычки, которая въелась еще со времен DOS. Хоть и безболезненно переключаюсь на "/" в Linux-консоли.

Посмотреть

Полноценный REST API для перфекционистов за 5 минут

ophermit 22 июн 2016 в 01:15

Спасибо. Полезный инструмент, намного удобнее Django REST Framework. Жаль, нет интеграции с Django.

P.S.