Руслан Семагин
Ещё не определился. Сложный выбор.
Слово "архитектура" в этой простыне выглядит как случайное недоразумение.
А советы "архитектора"..., ну, уволил бы сразу.
Денис, пора таки прекращать срамиться на технические темы, лучше по старинке, про общую водяную воду.
Без обид, ну правда же...
Николай, а атаку идти не стоит. Я с Вами не дискутирую. Прочитайте внимательно мой комментарий, и найдите в нём желания бесплатного, или что-то в этом роде. Написано же, это пример, иллюстрация того как иногда бывает проснувшись утром, и когда к этому не готов. Всё. Ничего больше.
Ещё раз, в хорошей архитектуре не может быть такого узкого места, каким является облако когда оно одно и всё, ничего больше. Это исключительно моё мнение, и я его не навязываю.
Я работал в компании, средний счёт которой был на уровне 100 тысяч долларов месяц. И никто не жаловался.
Так работайте на здоровье, вопрос то в чём?
Бояться облаков действительно не стоит, но и важно понимать, что облако не может в хорошей архитектуре являться единственным хранилищем данных, единственным сервисом и т.д.
По поводу "хорошего трафика", это да, но ситуации бывают разные.
Приведу конкретный пример (см. скриншот), один клиент в прошлом году получил списание в пользу гугла за использование облачных сервисов в размере 14000 долларов США за один календарный месяц. Да, это не опечатка.
Там было списание за несколько картографических сервисов, сумма накапала за месяц, списана единовременно по окончании отчётного периода.
У человека была привязана бизнесовая карта, это та, которая напрямую к расчётному счёту привязана, плюс деньги были списаны в минус, банк это позволяет вполне.
Этот пример конечно не относится конкретно к FireBase, это просто иллюстрация того, как бывает иногда в реальности.
И это главная ошибка.
Своевременная отправка возражений должна быть как угодно, тем более уже что называется назрел конфликт.
Возражения имеются ввиду на бумаге с отправкой сканов и оригиналов в догонку.
"...но блин почему Денис Гордиенко везде заявляет обратное...." - ну, продавать себя никто не запретит в принципе, поэтому и нужно вникать в детали и информацию брать из разных источников. И главное не пренебрегать формальностями.
Итого в целом:
Не устаю повторять (в том числе клиентам), нельзя на базе какой-либо коробки построить большой проект. На чудо не нужно надеяться.
Коробка - это чисто поиграться в стартапера, не более.
Можно использовать лишь тогда, когда человек лично может и готов делать какие-либо работы по проекту. Всегда когда начинаются доработки, это как правило несколько порядков от стоимости коробки в конечном счёте, к чему большинство не готовы, ни морально, не финансово.
Коробка может хорошо если как говорится посмотрели, всё подходит как есть и ничего не надо, или надо мало и можете сами - можно брать.
Это искренне и честно, моё субъективное мнение.
А самое главное - что это (доработки) лишено всяческого смысла, потому что за доработками тянется балласт различных составляющих (платформа, неиспользуемые функции и пр.), что в результате зачастую не приносит ничего кроме головной боли и бесконечного сложного дебага.
Общее:
Чудес не бывает, если вы имеете «имперские амбиции» и не имеете денег - можно хоть сто коробок купить - результат будет нулевой.
Доработки готового ПО - это заблуждение, потому что даже имея деньги результат всё равно будет нулевой, потому что никакой разработчик не примет проект «как родного», и не будет над ним сидеть 24/7, а будет только выполнять конкретные требования, и будет это делать до поры до времени пока не надоест, а оно 148% надоест. Потому что частный проект - это частный случай, разработчик к нему не прикипит на вечно.
Так называемые «доработки силами стороннего программиста» - это ещё большее заблуждение. Большинство - интроверты. Подходы, квалификация, методы… - у всех разные. Вникать в нечто написанное десятком других ДО - никто не будет, и всё пойдёт по бесконечному кругу. Наверняка не раз слышали стандартный ответ: «нужно всё переписать».
«Подбор программиста в штат» - ещё большая дичь. Потому что хороший специалист работу не ищет, она его ищет сама. Хороший специалист если не трудоустроен, то ведёт свою деятельность самостоятельно, имеет широкий кругозор, интересуется и осваивает новые технологии/ЯП и т.д., и не пойдёт работать в конкретный непонятный микро-проект, на непонятном и ограниченном стеке, написанный хз кем и как.
Извиняюсь если много собрал и несколько сумбурно.
Безотносительно темы:
Единая проблема многих заказчиков - посредственный подход к оформлению и проработке деталей проекта, игнорирование и зачастую «юмористическое» отношение к составлению технического задания, в надежде на то, что «вроде всё проговорили значит проект будет соответствовать ожиданиям…» - Нет, он не будет соответствовать ожиданиям.
Вообще никакой проект не будет соответствовать ожиданиям без скрупулёзно составленного технического задания на уровне фанатизма.
Отсутствие фанатизма при составлении технического задания и соблюдении всех формальных процедур возможно, и приходит со временем в процессе длительной работы, когда люди уже достаточно хорошо знают друг-друга, понимают кто что может выдать, каковы компетенции, чего ожидать, с учётом накопленного опыта взаимодействия по текущему/прошлому проекту.
Составление технического задания это всегда больной вопрос для заказчика, потому что разработчик его (ТЗ) ждёт, а никакой заказчик его дать самостоятельно не способен, за редкими исключениями.
Соответственно, если своими силами, или в результате коллегиального обсуждения ТЗ составить не удаётся - лучше его заказать. Да, это отдельная статья расходов, но оно того стоит, т.к.:
Составив раз - это хорошая основа для собственного переиспользования в будущем с поправкой на проект.
В процессе его (ТЗ) разработки, как правило, заказчику и/или исполнителю раскрываются детали о которых они ранее не думали и не учитывали (если составитель не имеет цели что-либо скрыть/умолчать).
Корректное, не расплывчатое ТЗ с чёткими формулировками и техническими/технологическими требованиями однозначно дисциплинирует исполнителя, и с высокой степенью вероятности сильно укрепляет позиции добросовестного заказчика в случае судебных разбирательств или предварительной претензионной работы, и в случае судебного разбирательства существенно повышает шансы на взыскание/компенсацию.
Тоже самое что в п.3, только для исполнителя.
Есть и минусы:
Зачастую такой подход с учётом новых деталей проекта даёт увеличение стоимости проекта.
Наличие ТЗ не предусматривает и не учитывает изменения взглядов заказчика на проект, особенно если разработка занимает продолжительный период времени. Т.е. Если в процессе, условно через полгода заказчику проект «разонравился» - придётся заплатить.
По теме:
Конечно, наверняка за 8 (или сколько там) месяцев материала у вас сильно больше чем эти несколько скриншотов. Соответственно детали скрыты, поэтому что-то конкретное тут сложно понять. Но, если всё что я написал выше не ваш случай, и всё было надлежащим образом оформлено, то нужно более основательно подойти к вопросу и продолжить разбирательства.
Но если в суде ставился вопрос наличия проводимых работ в рамках абонентского обслуживания в принципе, и если либо подписанные акты, либо автоматически принятые например в следствие истёкшего срока возражений по актам - то хз что тут оспаривать. Для арбитража то всё равно, есть текст договора, если фактические обстоятельства - результат решение.
Оснований настаивать на экспертизе я так понимаю у вас не было, в плане того что если вы оспаривали время, то на какие вопросы должен ответить эксперт?
Если речь о технической экспертизе, то это наверное отдельный иск, не об абонентском обслуживании. Опять таки, на какие вопросы должна ответить экспертиза? Т.е. например прописаны некие требования, они не соблюдены и т.д.
Если не было никаких конкретных требований, то экспертиза для вас автоматически в результате обернётся расходами без удовлетворительного результата.
Экспертиза не отвечает просто на вопрос что там в проекте говнокод или не говнокод, т.к. Это неформальное понятие всё таки :)
Чисто по человечески всё разумеется понятно конечно же.
Иными словами, FireBase это хороший инструмент, для реализации каких-либо задач, но он не может являться единственным хранилищем несмотря на все увиденные вами преимущества. Как-бы мир разработки немного сложнее, и очередей из проектов где только FB на горизонте не видно. Не задумывались об этом?
https://youtu.be/LM18xGeZPZ8