Yura, интересно. А как именно не работает? Есть какие-то сообщения об ошибке? Пробовали в цикл вложить вывод дополнительной информации? Посмотреть как формируется массив, нет ли ошибок на этом этапе?
Я бы прошелся по всей цепочке с самого начала чтобы понять где именно проблема.
Интересно, только для меня стало новостью что reduce это не чистая функция или я не один такой тупой? :)
(Да, да, я в курсе, что объекты передаются по ссылке, а не по значению, но будь я разработчиком, то постарался бы проверить не дали ли мне в аргументах объект и не нужно ли его клонировать вместо того, чтобы работать с оригиналом)
DevMan, а что тут такого? Очередь это один из вариантов коллекции, физически обычно реализуется через двунаправленный список. Да, в Яве, скажем, это интерфейс, которые реализуют несколько разных типов данных, но это уже детали.
Сергей Соколов, я же писал, родной массив хорош как стек, где у него сложность добавления и выборки O(1), но если использовать его как очередь (FIFO), то нужно использовать shift, а у него сложность O(n). У нормальной реализации очередей (через двунаправленный список) сложность put/get должна быть O(1).
javedimka, а в чем именно проблема? Для интереса посмотрел примеры на стековерфлоу, вполне работают, например вот отсюда. Все запускается, отрабатывает параллельно.
Серьезно интересно что не так с питонячьей реализацией асинхронности.
Alex, и в чем проблема? День разбит на секции, значит нумеруем секции. В одной таблице держим расписание вида:
Дата, Номер секции начала интервала, Номер секции конца интервала, Тип интервала.
Во вторую пишем записи в виде:
Дата, Номер секции начала интервала, Номер секции конца интервала, Клиент (ссылка на таблицу клиентов), Тип услуги (ссылка на таблицу услуг), Кто оказывает (при необходимости, ссылка на таблицу работников)
Если отойти от секций, то в "Начало интервала" и "Конец интервала" можно просто писать время.
Самое главное, это понять что хранение данных, их представление в программе и способ их демонстрации пользователю это три совершенно разные вещи. Храним так, чтобы было удобно делать выборки и расширять в дальнейшем функционал программы, представляем в программе так, чтобы было удобно реализовывать бизнес-логику, показываем пользователю так, чтобы было удобно щелкать мышкой. Разделяем все по уровням абстракции и спокойно работаем.
Под "онлайн записью" имеется в виду запись на получение каких-то услуг? Тогда нужно конкретизировать какие именно данные хотите хранить и какой будет объем (подозреваю что мизерный -- порядка десятков тысяч записей в год, но мало ли). Интервалы и график работы это самое простое, особенно если нет необходимость упарываться в нормализацию.
А каков размер картинки? Потому что 5-6 мб для джипега это очень много. Сейчас специально посмотрел немного своих фото: фотографии экранного разрешения получаются порядка 100-300 кб.
ettaluni, тогда просто пишем фронт на HTML/CSS/JS или берем какой-нибудь фреймворк типа React/Vue. Данные с ноды дергаем с помощью fetch/axios, а на бэке, соответственно, делаем REST API, который отдает нужные данные на фронт. Google по запросу "rest api node js" выдает массу полезных ссылок.
Я бы прошелся по всей цепочке с самого начала чтобы понять где именно проблема.