Андрей Семейкин, 3 часа назад ты опубликовал этот пост. За это время ты мог уже наводнить код логгированием и понять на какой строке у тебя процесс аварийно выпадает в kernel.
Но мы до сих пор топчемся на месте при том что ты "неплохо" знаешь.
Dr. Bacon, да я не против. Пускай берет что угодно. Может на данном этапе ему вообще безразличен выбор типа БД. А раздличия появятся под нагрузкой. Что-то будет медленно отдаваться. Или при расчете биллинга в конце месяца.
Короче я на самом деле ОК с любым решением просто потому что здесь - сферическая задача в вакууме.
Андрей Семейкин, ты лучше вноси изменения по чуть-чуть. Тоесть добавил строку - проверил.
Я не знаю есть ли в Arduino дебаггер. Но желательно-бы им воспользоваться. И есть ли доказательство
успешной компилляции? Возможно у тебя она просто не проходит и ты видишь старый бинарник.
Добавь логгирования побольше.
В сериалах и фильмах обычно дизайн происходящего на экране создают художники по эффектам. А они - не особо заморачиваются достоверностью. Тоесть маловероятно что вы в сериале найдете что-то полезное для себя.
Лучше вот где-то в Reddit, Gitter, Slack, IRC, Telegram. Ну или на святой земле... Здесь.
Adamos, я знаю. Но вы завязываетесь на частный случай. Кстати битовая маска не сработает для суммы например 900 р где нужно будет учесть 500 + 100 + 100 + 100. Тоесть одна банкнота несколько раз. Нужен ассоциативный список или map.
Битовые маски все-таки предполагают ограничения. По идее мы должны в коде хард-кодить такой связный список 500 -> 100, 100 -> 50 и последовательно обходить и вести учот суммы.
Выбор merge или rebase может быть продиктован решением команды. Тоесть если команда решила мержить а автор будет ребейзить ради своего удобства - наверное это неправильно.
rezedent12, у тебя слишком много хотелок. Объективно, если то что ты написал - очень хорошее то портировать его на 2-3 платформы не так трудно. Нужно только брать правильные абстракции при разработке и не заниматься максимализмом. Быть скромнее короче.
А если твоя программа никому особо не интересна - то будь она даже кросс-платформенной - ну и будет такой лежать на задворках гитхаба.
Не понимаю как спроектировать базы данных так как у таблицы заказа есть поле user_id что бы оно ссылалось на первую базу данных с юзерами
В рамках микросервисной архитектуры - это невозможно. Ссылочная целостность не поддерживается. Каждый микро-сервис имеет свою независимую БД и связывать их вобщем-то нельзя. Если даже мы их как-то свяжем - то получается схема при которой 2 сервиса зависят от связки двух БД. Это - слабое место в системе. И при отказе одной из БД оба сервиса станут недоступны.
Тут такие вопросы. А что такое SpreadsheetApp? Это библиотека поддержки листов Excel? Это UI приложение? Каким образом оно должно работать с Python? В браузере? Или это оконное приложение? Я думаю что преобразование - это путь в никуда. Умножить те ошибки что были на новые ошибки что будут.
Вобщем я думаю что ничего никуда преобразовывать не надо. Нужно просто заново поставить бизнес-задачу (и ответить на все вопросы выше) и реализовать ее на Python.
Вобщем тут надо думать. Думать. А так вот... топнуть ножкой и сказать что я дескыть просто хочу преобразовывать - это какой-то юношеский максимализм.