Pull to refresh
4
0
Send message

Поясните про JWT. Его подпись не проверяется бэкэндом, или JWT подписывается на стороне клиента? Если второе - то получается, что по-сути клиент способен просто отсылать любые данные с score и тд, по своей воле, без всяких проверок на валидность именно игровых данных со стороны бэка?

if (not expire) or (expire_time < datetime.now(timezone.utc)): raise HTTPException(status_code=status.HTTP_401_UNAUTHORIZED, detail='Токен истек')

Проверка лишняя. jwt.decode уже проверяет срок жизни токена. Первый except JWTErrorэто отловит.

from time import sleep
from datetime import datetime, timezone, timedelta

from jose import jwt


def create_access_token(data: dict) -> str:
    to_encode = data.copy()
    expire = datetime.now(timezone.utc) + timedelta(seconds=3)
    to_encode.update({"exp": expire})
    return jwt.encode(to_encode, "mysecret")


if __name__ == "__main__":
    token = create_access_token({"some": "data"})
    print(token)
    sleep(5)
    print(jwt.decode(token, algorithms=["HS256"], key="mysecret"))

>>eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzb21lIjoiZGF0YSIsImV4cCI6MTcyMTMwMTQ5MH0.KjLGf3chNy5pvx-vsYY_nKbSMNML0-LTR6PfD8dAXJA
>>Traceback (most recent call last):
>>...
>>jose.exceptions.ExpiredSignatureError: Signature has expired.

Анализ статьи:

  1. Структура и стиль:

    • Статья очень структурирована, каждая часть логически вытекает из предыдущей, что характерно для генеративных моделей.

    • Использование формальных определений и комментариев в коде, а также пояснений к каждому шагу.

  2. Повторение шаблонов:

    • В тексте присутствуют определенные шаблоны, такие как подробные описания методов, классов, параметров и возвращаемых значений.

    • Например, многократное объяснение структуры gRPC запроса и ответа.

  3. Общее качество текста:

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

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

Для тех, кто не понял, что здесь вообще происходит - тут написана реализация сервера FastAPI, который делает только то, что дёргает ещё один сервер, уже gRPC.

Очень слабо для статьи. Нету даже указания направления python разработчика (подразумевается backend). Так же не хватает:

  • временных рамок, сколько и на какие направления нужно тратить (хотя бы в условных сторипоинтах)

  • четкого распределения, что и в каком порядке нужно учить, что можно учить параллельно

  • Если вы уж решили просто дать ссылки, то не поленились бы давать ряд материалов по теме, с описанием, почему именно этот материал, и что полезного можно из него подчерпнуть. Учить джангу по одному плейлисту с ютуба - невозможно.

  • Некоторые материалы совсем нерелевантные - ну какой RabbitMQ начинающему разработчику?


    Зато ссылку на свой телеграмм канал не забыли вставить, конечно же.

Добавлю: -Python компилируемый или интерпретируемый? (После очевидного ответа "интерпретируемый", следует вопрос -А что такое файлы .pyc, который появляются, когда запускаешь python файл?)

TLDR: у некой пациентки №1 в течении шести минут после отключения аппарата жизнеобеспечения наблюдалась мозговая активность.

На этом полезный текст статьи заканчивается. Зачем упоминать что "Джимо Борджигин начал изучать этот вопрос в 2015 году" аж два раза - не ясно, тем более, что внятных результатов никаких так и нету.

"Внетелесные" опыты при клинической смерти очень легко объясняются нарушениями работы мозга. Даже здоровый, полностью функционирующий мозг подвержен всяческим когнитивным искажениям восприятия - что уж говорить про мозг без доступа к кислороду.

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

Понятие "завтра", "вчера" и все остальные значит тоже выкинем на помойку, так как в разных часовых поясах "завтра" будет наступать то днём, то вечером, то ночью?
Кстати, "вечер, утро, полдень" тоже уже ничего описывать не уже не будут, и от них избавиться придётся, получается?

У зацикливания есть ощутимый минус если программа упадет, то самостоятельно в следующей период она не запуститься.

Поэтому лучше использовать APSCheduler:

from apscheduler.schedulers.background import BlockingScheduler

# Creates a default Background Scheduler
sched = BlockingScheduler()

def prompt():
    print("Executing Task...")

sched.add_job(prompt,'interval', seconds=5)

sched.start()

... который лишен этого недостатка + куча других плюшек по типу работы с асинхронным кодом.

VPS сервер Аренда сервера мне кажется избыточным решением... 

На самом деле, это - самый очевидный и хороший вариант решения. Никогда не знаешь, насколько поднимут плату всякие Yandex Functions и остальные.

Статья была бы полезной, если автор хотя бы рассказал про установку библиотек и работу скрипта в виртуальной среде типа venv - это очень нужно для работы на VPS серверах. Докер для одного скрипта - действительно избыточно.

"кружочек" - это видеосообщение. Как аудиосообщение, только ещё можно и на прекрасное лико говорящего смотреть. А именно "кружочек" он потому, что видео с пользователем обрезается до круга.

  1. exception_handler  - скорее exception_silencer. Очень плохо использовать такие декораторы и в целом конструкции вида:

    try:             
      return func(*args, **kwargs)
    except Exception as e:
      print(f"An exception occurred: {str(e)}")

при действительной ошибке внутри функции она будет заглушена, никто о ней не узнает - а workflow пойдёт дальше так, как будто функция вернула None - и вся программа поведёт себя непредсказуемо.

  1. validate_input - похоже на какую-то попытку сделать из нетипизированного языка типизированный. Можно подумать, как будто проверять каждый раз тип аргумента - lambda y: isinstance(y, str) - хорошая идея, но это совсем не так. Нужен типизированный язык - есть полно таких языков, не нужно переделывать Python.

  2. timer - давно уже рекомендуется вместо time.time() использовать time.perf_counter()

    Я лично пользовался таким декоратором: соединенные вместе декораторы timer и debug + счетчик отступов:

def performance_debug(f):
    performance_debug.active = 0

    def tt(self, *args, **kwargs):
        turn_on = getattr(self, 'performance_debug', False)
        if turn_on:
            performance_debug.active += 1
            t0 = time.perf_counter()
            tabs = '\t'*(performance_debug.active - 1)
            name = f.__name__
            print('{tabs}Executing <{name}>'.format(tabs=tabs, name=name))
            res = f(self, *args, **kwargs)
            print('{tabs}Function <{name}> execution time: {time:.3f} ms'.format(
                tabs=tabs, name=name, time=(time.perf_counter() - t0)*1000))
            performance_debug.active -= 1
            return res
        else:
            return f(self, *args, **kwargs)
    return tt

Дело тут совсем не в уровне IQ "тупее табуретки", а в удобстве. Вот покупаю я какую-то вещь на БУ площадке, и сразу записываю контакт как "Дмитрий Покупаю Ноутбук". Мне звонит данный человек - и я сразу вижу и вспоминаю, что за контакт и зачем он мне звонит.
Теперь представим, что я записал данные в положенное поле "заметки". Оно не отображается при вызове. При звонке некого "Дмитрия" мне придётся гадать, кто это? Тот человек с БУ площадки, начальник, одноклассник?

Проверил, после релиза Pydantic теперь можно установить pydantic-settings==2.0.0 вместе с последней алхимией == 2.0.17. Боль была временной, внесу update в статью

Да. Думаю, причина в том, что приходится из Python вызывать функции из другого языка программирования - Rust, ведь https://github.com/pydantic/pydantic-core переписан на него.

Есть только одна очень серьёзная причина не использовать Python при разработке: отсутствие возможности защитить свой код. Не всегда это нужно, однако.

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

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

...Если вы используете Python сегодня, я думаю, что вы просто обязаны попробовать...

...Перепишите небольшое приложение или утилиту ...

...начните думать о том ...

Спасибо за советы, особенно про "начать думать" прекрасно

DMX512 рассчитан на 512 каналов, судя по википедии. Как я понятно из статьи, на один канал можно расположить несколько приборов, с другой стороны — один прибор может занять до 20ти каналов.
Как решаются задачи управления с большим количеством каналов? Думаю, на масштабных концертах будет явно больше 512ти. Управляющие мастер-устройства связываются между собой по более «высокому» интерфейсу?

Information

Rating
Does not participate
Registered
Activity