Игорь Маркин

Можно хоть в консоли (а если конкретно - в редакторах vim/neovim), хоть в блокноте.
Про версия просто позволяет ускорить создание нового проекта (сама активирует окружение, скачивает нужные библиотеки и создает новый шаблон), имеет автокомплит специфических для джанго вещей, а так-же имеет поддержку синтаксиса js/html.
Собственно, из-за первых двух пунктов, использовать про версию как раз не рекомендуется - чтобы вы в первую очередь полагались не на умную программу а на свои знания.

Создаю свой мессенджер, задача такова что нужно сделать список абсолютно всех мелодий которые есть в мире, так же как в вк, как это можно реализовать?

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

1) Хранилище. По примерным оценкам в мире в цифровом виде около 500 000 000 оригинальных музыкальных композиций. Учитывая ремиксы и каверы - можно смело брать миллиард. Средний вес композиции среднего качества - 5 Мб. То есть порядка 5 петабайт, если хранить не в лучшем качестве. Учитывая что это должно иметь какое-то резервное хранение (у нас тут серьезный сервис все-таки), умножаем на 2 (10 петабайт). При стоимости около 2 центов за гиг в месяц, 10 000 000 Гб * $0,02 = $200 000 в месяц хранение. Ну, бюджетненько в целом.

2) БД, которая хранит данные обо всех этих композициях. Стоимость хранения будет поменьше, но думаю к 20-50К все равно где-то выйдет.

3) Другой вопрос - где брать эти данные, так как не все музыкальные файлы содержат полное описание композиции. На перебор 1 миллиарда записей и сортировки их по жанрам, альбомам, исполнителям, дате выпуска и т.д. уйдет некоторое время. Допустим 50% композиций будут иметь нормальное описание, остается все те же 500 миллионов композиций на обработку. Пусть на каждую понадобится 2 минуты работы, внести данные в поля (хотя их еще как-то найти надо, но допустим), тогда получим 1 миллиард минут. Это 1900 лет работы, или 16 666 667 часов. Час работы самого дешевого индуса - 3 бакса/час. 16 миллионов * 3 - давайте округлим до 45 миллионов. Даже если сократить этот пункт в 10 раз - выйдет под 4 миллиона. Рабский труд сегодня дорог как никогда...

4) Теперь платформа которая будет всем этим ворочать, так как у нас в сервисе должны же какие-то пользователи завестись вроде. Ну, на сервера можно смело отложить небольшую сумму, тоже где-то 20-30К, для начала сойдет.

5) Прочие накладные расходы, такие как билеты на самолет до Америки с целью договориться где будет стоять ваш датацентр и прочие мелочи мы пока в бюджет не вкладываем, так как там уже инвесторы подтянутся, и смысла заморачиваться с мелочевкой нету. Так же оставляем за кадром вопросы лицензий и отчислений авторам, так как с этим возиться лень, как-нибудь решим потом.

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

По итогу на год:
$200 000 * 12 = $2 400 000 хранилище
$20 000 * 12 = $240 000 бд
$20 000 * 12 = $240 000 сервера приложения
$4 000 000 работы
Итого: чуть меньше 7 миллионов баксов.

event_json = HttpRequest.read()

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

1. Объектная модель языка Python
   
2. Структуры данных вообще и языка Python в частности
   
3. ООП вообще и понятие классов, экземпляров, атрибутов, методов, инициализации экземпляров в частности.
   
4. Реализация конкретного класса User в конкретной версии библиотеки.
   
5. Осмысление места, роли этого класса, его атрибутов, причин такой реализации, последствий для программирования бота;
   
6. Вероятно, базы данных, их связь с классами; поля БД, их связь с атрибутами класса;
   
7. Понимание, как всё это в целом работает, какие пути есть для получения искомых сведений и какие последствия могут возникнуть для работы бота, канала, Телеграма и его пользователей при работе с этими сведениями.
   

Вот вам пример простейшей реализации:

class User:
    def __init__(self, a, b, c):
        self.a = a
        self.b = b
        self.c = c

    def __repr__(self):
        return f'a:{self.a}\tb:{self.b}\tc:{self.c}'

users = [User(1, 2, 3), User(('z', 'y', 'x'), 5, 6), User('a', 'b', None)]

for user in users:
    print(user)
    print(f'a:{user.a}')
print(users[1].a)
print(users[2].c)

из него можно извлечь некоторые сведения для вас.

Но вовсе не обязательно, что в вашем классе User всё реализовано так просто. Надо посмотреть на него глазами.

Это задача размена монет. Решается динамическим программированием. Вот статья на вики. Там даже код есть, похоже, на питоне. Правда, оно там только количество монет считает. Чтобы найти и сами монеты, вам надо завести еще один двумерный массив и везде, где считается массив m запоминать, а каким именно действием текущее значение набирается (или взять текущую монету, или пропустить). В конце вам надо будет от позиции m[-1][-1] циклом while выполнять записанные ранее действия (или пропустить текущую монету и уменьшить r на 1, или взять и тогда уменьшить r на ее размер).

Попробуйте по-другому. Получите уникальные элементы списка посредством множества (set) и затем посредством метода .count() для списка посчитайте, сколько раз встречается каждый уникальный элемент из множества в вашем списке. Элементы, для которых .count вернёт 1, и есть уникальные.

def print_unic_elements(arr):
    [print(i) for i in set(arr) if arr.count(i) == 1]

Самого задания не будет? Оценивать то нечего толком. В описании куча грамматических ошибок. На этом можно закончить, это уже говорит о плохом подходе. Вот это вообще без комментариев.


Много коммитов с изменением ридми, можно ведь один раз написать грамотно и не редачить по 10 (буквально) раз. Честно говоря, уже на этом бы моменте даже не стал дальше смотреть. Сама "документация" написана тожн абсолютно никак.

SQL запросы составлены неверно. Нейминги переменных разные. Некоторые переменные вообще непонятно зачем существуют, как, например, error в методе авторизации.
https://github.com/chigan0/apptrix.test/blob/main/...

`utils` откуда-то слизаны, там везде почему-то табы, когда в остальном коде пробелы.
Красиво


Английские слова точно так же написаны с ошибками.

Дока не соответствует коду.

?lastname фильтрация по фамилии

В коде:
"last_name" in request.args

JS разработкой не занимаюсь, но первый раз вижу, чтобы форму формировали не через тег form и/или с использованием ajax, а просто пложив инпуты на страницу, без атрибута name и потом собрав их руками в formdata, и через fetch бросить на сервер.

Лишние комментарии в коде, остатки от каких-то тестов. Отступы скачут. И так далее И так далее И так далее. И всё это до теста главного функционала приложения

Потому что все очень плохо, буквально в каждой строчке кода. Полное несоблюдение PEP8 везде, где только можно.
main.py и settings.py принято держать в корне проекта.
Хранить какие либо ключи и/или пароли прямо в .py файле и тем более заливать это в github - отвратительная практика.

Структура проекта отсутствует в принципе:
- Почему у тебя в папке models конфигурация БД?
- Почему у тебя параметр подключения к БД прямо в файле, где происходит подключение, а не в конфиге?
- Зачем вообще файл create_database.py?

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

Inline Bot

Как из содержимого строки сделать название переменной?