Развитие ядер для запуска приложений за 2019 год. Часть 1
Денис Гордиенко, руководитель Bright Mobile, об итогах развития собственных продуктов в 2019 году и планах на 2020. Рассказываю что и почему не получилось в ушедшем году и какие сделали выводы. В этой части буду говорить про ядро для маркетплейсов услуг, я…
33 показа
1.3K1.3K открытий
Ох, это называется как прижали к стенке начал крутить задом.
Вот вроде бы как попытался что-то ответить, а получилось вновь словоблудие.
Денис, вы ещё раз и внимательно перечитайте документ который опубликован ранее, имейте совесть, за вас были приложены определённые усилия по его получению.
Ещё раз, по факту вы не можете использовать FireBase как единственное или основное хранилище с учётом тех ограничений на операции которые обозначены в документе, если это конечно не проект где все сплошь одни анонимы.
Соответственно, вместо того чтобы в очередной раз пудрить мозг и лить воду, вы должны сообщать примерно в таком ключе:
Да, мы разрабатываем ПО которое как есть из коробки на текущий момент не соответствует действующему законодательству, и вы (клиент) должны это знать, иметь ввиду, и принимать решение на свой страх и риск. Или вот есть такой иной конкретный вариант решения.
И всё. Предельно же просто кажется. И вопрос автоматически закрывается.
А не заниматься очковтирательством.
Просвещение и предложение реализации это часть профессии, если только деятельность не сводится к тупому выгребанию бюджета.
Но представлять в таком ключе, мол чего там, надо дело делать, на кой чёрт нам думать о законодательстве, ведь мы стартеры и пр. - это по меньшей мере не разумно и смешно, и разумеется никак не тянет на сколь либо серьёзный подход.
Хотя конечно, учитывая что в реальной жизни ~99% покупателей такого рода ПО - заканчивают ничем потому что даже ничего и не начинают - им это как говорится зайдёт нормально. Но до первой же абузы. Потом начнутся страдания.
Для вашего сведения дополнительно сообщу, что номер телефона в связке с любыми другими данными, например с упомянутым именем - есть персональные данные. Если вновь есть сомнения - вы уж в этот раз самостоятельно думаю справитесь запросив информацию или нагуглив практику.
Что касается совершенно дурацкого и не умного вывода «…а то ведь можно совсем уйти в дебри и пойти регистрироваться оператором персональных данных, соблюдать закон о мессенджерах…» - вы не поверите, это не дебри как вы выразились, это прямая обязанность владельца проекта, и об этом разумеется он (владелец) также должен знать, но в этом случае скорее сам, т.к. это не связано с конкретной реализацией о которой он без уведомления не будет даже догадываться (ваш случай). Так что будет владелец это соблюдать или не будет - его дело, но представлять это как некую чушь по меньшей мере глупо и не серьёзно с вашей стороны.
Поэтому, не нужно тут приплетать кого-либо или чью либо культуру общения, отвечайте строго за себя и по существу. Ваша привычка перекладывать с больной головы на здоровую и при любом случае переводить стрелки и съезжать с темы известна давно и всем кто интересуется.
Так что ок, принимается. Единственное что, с удовольствием бы почитал/посмотрел про вашу реализацию как вы выразились «дублирующего сервера», чувствую вот там будет где разгуляться, учитывая ваш уровень владения предметом.
Осталось теперь подтянуть терминологию в видео, а то иногда прям совсем позор.
Руслан, подскажите ссылочки на проекты Ваших клиентов, получивших статус оператора персданных и полностью соответствующих всем законам
А что касается технических вопросов... Как научитесь у себя в решении делать регистрацию через приложение или хотя бы не перезагружать экран по кнопке Назад, так и поговорим с Вами про архитектуру.
Хотя за 60 тыс вполне неплохой софт уровня добротного дипломного проекта. Жаль только, что Вы пытаетесь самоутвердиться за счет моих статей, интересно было бы почитать Ваш авторский материал без подобной токсичности, ведь есть, наверное, чем поделиться, не только ж чужие разработки засирать умеете?
с сентября персональные данные, это и телефон и почта - это официально, можно даже без имени