• Как в firebase получить сначала _не_решенные задачи?

    @luna3956
    Арсений Еремеев, Вот изначально скопируйте в users_data/userId/tasks/ все 100 задач и каждой добавьте флаг solved=0. Чтобы выбрать одну из нерешенных задач используйте примерно такое обращение:
    var ref = firebase.database().ref("users_data/userId/tasks");
    ref.orderByChild("solved").equalTo(0).limitToFirst(1)...

    Оно будет выбирать одну из 100 нерешенных задач. Как только решите ее, поменяйте для нее solved на 1 и тогда следующее обращение ref.orderByChild("solved").equalTo(0).limitToFirst(1)... будет выбирать одну из 99 нерешенных задач и т.д.
  • Как в firebase получить сначала _не_решенные задачи?

    @luna3956
    Арсений Еремеев, Если пользователю нужно иметь дело всеми задачами, то с самого начала можно сразу все задачи копировать в личную папку задач пользователя и пометить их флагом solved=0, а как только она решена - менять 0 на 1. Можно конечно и удалять оттуда, но с точки зрения работы с данными, удаление - не самая хорошая практика. Просто помечайте как solved=1 и все. А для выбора нерешенных просто выбираете те у которых solved=0
  • Как в firebase получить сначала _не_решенные задачи?

    @luna3956
    Арсений Еремеев, Если у вас есть общая коллекция задач tasks, то если пользователь должен сначала "взять" себе задачу какую-то, то это самое "взять" заключается в том, что из коллекции tasks вы копируете задачу в личный список задач пользователя, то есть в users_data/userId/tasks/taskKey(ваша новая задача) с флагом solved=0, а как только задача решена - меняете 0 на 1. Если же пользователь не выбирает для себя задачи, а должен иметь дело со всеми задачами из tasks, то вам нужно копировать все задачи из tasks в "users_data/usersID/tasks/сюда" для каждого пользователя с тем же флагом solved.

    Про сортировку не совсем понял вопрос если честно, вам нужно отсортировать общую коллекцию tasks? по каким данным?
  • Как в firebase получить сначала _не_решенные задачи?

    @luna3956
    Арсений Еремеев, аа, не понял из вопроса. Тогда почти то же самое самое, только в ветке пользователя. Я, например, в своих проектах делаю так:
    users_data
        userID
            tasks
                taskKey1
                    taskID
                    taskName
                    solved
                    ...
                taskKey2
                    taskID
                    taskName
                    solved
                    ...
        userID
            tasks
                taskKey1
                    taskID
                    taskName
                    solved
                    ...
                taskKey2
                    taskID
                    taskName
                    solved
                    ...
                ....


    То есть создается ветка users_data, где для каждого пользователя хранятся его индивидуальные данные, в вашем случае - задачи
  • Как набрать начальную аудиторию для нового проекта?

    @luna3956
    Виктор Юрченко, это классическая проблема маркетплейсов. Пользователи не приходят, потому что нет товаров/контента, авторы/продавцы не приходят, потому что нет пользователей. Панацеи нет, к сожалению. Тем не менее, Вам нужно начинать с привлечения авторов. Ищите их на различных площадках(тот же Хабр, Spark, VC), просите их помочь, предлагайте им за то что они будут у вас публиковать свои статьи плюшки в будущем какие-нибудь и тд. Создайте десяток-другой фейковых авторов и статей, создайте видимость активности. И вот когда у вас будет хоть какой-то визуальный намек на то что площадка живая, тогда попробуйте нагнать какой-нибудь трафик(выделите тысяч 10 рублей на рекламу в каких-нибудь группах вк, телеграм и тд) - получите сотню другую пользователей. И так постепенно шаг за шагом наращивайте аудиторию. На самом деле если быть честным очень сложно раскрутить маркетплейс в наше время не вкладывая кучу денег, тем не менее, если сильно захотеть, то можно все. Удачи)
  • Указывать ли нерелевантный опыт в резюме?

    @luna3956
    Дмитрий, указывать, указывать и еще раз указывать. А причины, почему так получилось - уже при личной беседе объясните.
  • Как сделать сравнение диапазонов дат в mysql?

    @luna3956
    skyfly2010, не совсем Вас понимаю. Вы говорите есть таблица с мероприятиями, надо проверить новое мероприятие на предмет пересечения с другими мероприятиями. Второй запрос(который в UPD) правильный и вернет вам все случаи пересечения мероприятий. И на вашем втором рисунке красное мероприятие не проскочет.
  • Как сделать сравнение диапазонов дат в mysql?

    @luna3956
    Если же начало или конец мероприятия налагается на другое мероприятие, то запрос должен вернуться с id того мероприятия(ий),
  • Большие объемы данных для сайта (50-100 ГБ, фотографии). Организация поиска среди них. Облачные хранилища или что-то другое?

    @luna3956
    ivanteterichev, конечно не в ручном, вы пишете код который заливает фотки в хранилище а в табличку в базе данных сохраняет их пути и названия сразу после заливки
  • Большие объемы данных для сайта (50-100 ГБ, фотографии). Организация поиска среди них. Облачные хранилища или что-то другое?

    @luna3956
    ivanteterichev, табличка не будет создана автоматически, это должен сделать программист: создает в базе данных таблицу примерно с такой структурой Images(id, name, link) и при загрузке фотографий в хранилище сохраняет в эту табличку названия фотографий и адреса этих самых фотографий. А какое выбрать хранилище - там я скидывал выше ссылку, сравните цены и выберите наиболее выгодное. На мой взгляд привлекательный вариант
  • Не подключается библиотека или что?

    @luna3956 Автор вопроса
    Internal Server Error появляется только в момент добавления строчки r = requests.get('https://api.github.com/events'), в логи nginx-а никаких ошибок не пишется
  • Как сделать поиск диалогов?

    @luna3956
    Формулируйте вопросы полно. Какие диалоги Вы хотите найти по имени - где пользователь фигурирует в качестве отправителя или получателя? или и те и те?
  • Правильная структура таблиц для поддоменов?

    @luna3956
    maddog670, чтобы получать исчерпывающие ответы, нужно хорошо и полно формулировать вопросы, а то это превращается в гадание.

    Если категория относится к статье, то структура таблиц должна быть такая:

    Domains(id, name, user_id)
    Categories(id, name)
    Articles(id, title, ..., user_id, domain_id, category_id)


    Если же по каким-то фантастическим причинам у вас в каждом поддомене уникальные категории, отличающиеся от категорий в других поддоменах, то домен прокидывается еще и в таблицу категорий:

    Categories(id, name, domain_id)
  • Правильная структура таблиц для поддоменов?

    @luna3956
    maddog670, а ну если Категории не существуют без статей, то конечно добавлять поле нужно только в таблицу Статьи, я просто не вникал в сущности и их связи, поэтому сказал добавить везде. В таблицу категорий добавлять поддомен не надо, так как категория это общая сущность, в отличие от статьи, которая строго привязана к поддомену.

    Зачем вам создавать такую таблицу, она же будет клоном таблицы articles. У вас статья не может существовать сама по себе, к ней всегда будет привязан пользователь-создатель, а значит справочник статей (articles) уже будет иметь вид, который вы описали выше
  • Где найти удаленную стажировку?

    @luna3956
    Для начала заполните в профиле контакты, чтобы с Вами можно было связаться)
  • Как организовать передачу данных между микросервисами (при наличии общей БД)?

    @luna3956
    Александр Михайленко, тут уже не столь важен механизм, если на стороннем апи можно определить авторизованность - то задача сильно упрощена. Делайте запросы сразу на эти сторонние апи, а когда нужно скомпоновать данные с нескольких апи - делайте это через центральный. Единственная задача - это синхронизации данных в центральной и локальных базах. Тут уже как выше говорил - либо реализуете обращения как одну транзакцию(преимущества - избегаем несогласованности, недостатки - увеличивается время запроса и задействуется центральный сервер), либо же обращаетесь к стороннему апи, отдаете пользователю данные и ОТЛОЖЕННО актуализируете данные в центральной базе. Как вариант приходит на ум следующее: чтобы избежать ситуации, когда лимит исчерпан, а на центральной базе он еще есть, можно поставить заглушку на каждом локальном апи и проверять - если для какого-то пользователя например лимит близится к завершению(допустим осталось 20 обращений), то начать делать операции транзакционно(то есть синхронно обновлять информацию в бд, разумеется, перед этим не забыть проверить очередь, в которой могут поджидать не примененные изменения для этой базы), а пока предел лимита еще далеко, то выполнять изменения на центральной базе отложенно.

    P.S на самом деле решений много, и в любом случае каждое из них будет казаться вам сложным и/или громоздким, но с распределенными системами просто не бывает, разве что если посчастливилось с нуля сделать чистые микросервисы.
  • Как организовать передачу данных между микросервисами (при наличии общей БД)?

    @luna3956
    Александр Михайленко, если у вас фигурирует аспект авторизации, которая завязана на центральном апи, то как вы собираетесь из клиента обращаться к сторонним апи, в них же нельзя определить, авторизован пользователь или нет. Точнее можно, если в общей базе данных хранится информация о сессиях и тд.
    Если же нет, то получается в цепочке запросов в любом случае будет задействован центральный апи, на котором сначала будет определяться авторизован ли пользователь и только потом посылаться запрос на сторонний апи.