Он же тебя был не рабочим, после тебя заработал с глюками.
Вероятность твоей вины в первой неработоспособности сам оценишь?
Джамперы маловероятно что могут быть на самом деле разъемом с примерами по напряжением и даже в этом случае спалил бы блок питания и сети питания, т.е. после этого вероятность работы была бы ещё меньше
docker это не плюс- а отдельный продукт на основе lxc (точнее там уже что то другое запилили но идея та же)
Песочница - это понятие в it, означающее изоляцию, в твоем случае она должна быть максимальной, ведь ты буквально запускаешь любой чужой код на своем сервере.
не должно быть доступа ни в интернет, ни в локальную сеть сервера (даже если она виртуальная), ни к файлам сервера, ограничены должны быть оперативная память, нагрузка на диски и процессор (через счетчики, к примеру на каждого пользователя выделяешь определенное количество секунд процессорного времени и количество IOPS дисковых операций, при превышении убиваешь процесс и блокируешь работу аккаунта (временно). можно задать разные лимиты и на первых замедлять скорость.
lxc не нагружает сервер, мизерные накладные расходы по памяти и все
как частный случай - запускай все в докере, но внимательнее настраивай все, например сети внутри быть не должно
Тогда ты ограничен списком библиотек поддержки (java,python,nodejs,php,.net) google drive (либо сам запросы формируй, недавно был вопрос по этой теме, как ни странно не все там хорошо документировано)
Без относительно выбора языка, твоя схема работы имеет фатальную уязвимость, злонамеренный пользователь (а таковы есть практически всегда), сможет вытащить из кода приложения данные о доступе к google drive и делать все что угодно, скачивать весь json, портить его (атака на отказ работы приложения - ddos) и подменять в нем значения, или к примеру пользоваться твоим хранилищем в своих нуждах за твой счет.
настоятельно рекомендую изменить бакэнд приложения.
описанный мной способ не требует js, так как при наличии скриптов можно просто вызвать ajax запрос нужное количество раз ну и вообще как угодно формировать запросы.
мое мнение (с ним не согласятся многие, может и правы) - не использовать формат даты sql, по ситуации, используй числа! например номер дня с какого то момента времени, например unixtime, тогда подобная проблема в принципе бы не вылезла (есть правда проблемы с високосными секундами но на нее похоже многие забили)
В твоем случае
- либо правь данные в базе
- либо при сравнении в sql запросе преобразуй дату в нужный формат, отрезая время, фукции смотри в документации к БД они у всех разные
- либо вместо равенства запиши поиск на интервале >= начало дня и < начало следующего дня
для следующих шагов в науке понадобится не просто усилие всей планеты, а нужно их оптимизация, чтобы не тратили две трети своих сил на производство мусора (запланированное устаревание и аналоги)
к сожалению население планеты не может с более простыми вещами договориться, типа углеводороды поменьше жечь (я не про автомобили, там адекватные гибриды идеальны по всем параметрам), а уж такие глобальные как смена экономического строя и подавно... нереальны
mayton2019, я про то что не совсем там все плохо, понимание есть, просто оно на столько тяжелое для использования что грубо говоря если хочешь получить настоящую картину, подключай суперкомпьютер и считай свою схему из десятка другого элементов
само собой так если и делают то только при разработке микросхем на топовом техпроцессе, или для сверхвысоких частот,.. в остальных случаях подходят старые упрощения и формулы до постквантовой теории
p.s. кстати основную задачу, для которой колайдер строили, уже решили, буквально несколько лет назад доказали массу бозона хигса.
полагаю 'его' еще будут строить, и старичка юзать до упора, читал что нашли способ решать те же задачи с такого же уровнем энергии но в меньших масштабах, т.е. новую вундервафлю будут строить только не удивлюсь если в космосе а не на земле.
добавлю что можно ввести авторизацию, если боишься действий анонимов