Выше в коментариях я расшифровывал смысл строк "стал невольным сместителем", это означает, что решение было принято до того как автор стал руководителем, и смысл автору вникать в технологии, от которых в компания отказываются и без него? А вот причины разумеется изучены и изложены в этой статье, вы кстати ее читали?
Если бизнес уже согласился, значит ему это выгодно, я кажется упоминал в статье какую выгоду получит бизнес.
Довольно смело пишите за автора, готов взять секретарем)
Возможно вы и правы, ТСД, которые мы кстати использем для Web версии пунков выдачи заказов, стоит адаптировать и под мобилки, уверен мы еще вернемся к этой теме, могу только сказать что мобильный телефон удобен как раз своей мобильностью, а приделывать к нему еще и сканер, да еще который может привести к потери автономности мобилки - все это уменьшит преимущества, ну мы просто спрашивали наших сотрудников, которые пользуются приложением. Тем не менее спасибо за идею, возможно сотрудники ПВЗ изменят свое мнение и мы вернемся к теме ТСД.
Я бы сказал что это было рациональное обоснование того выбора, который был сделан в пользу Flutter в самом начале, ведь он более чем оправдан. Сейчас это уже не обоснование, а констатация фактов пройденого опыта, эксперемент завершен, проект продолжается с новыми силами.
Про плагин камеры согласен, еслиб это была одна проблема и было в компании куча энтузиастов ее решить никто бы не парился, и учитывая что плагинов пришлось бы еще немало написать, тут я планы не могу рассекречивать, но они правда есть, смысл во Flutter потеряется бы довольно быстро
народу стало меньше, я не стал этим козырять ибо сравнивать с Flutter проектом некорректно, он шел не по роудмапу, а по иттерационным изменениям, нам проще так как знаем точку, в которую должны придти.
Я бы сказал что выбор не странноватый, а спорный. Мне тоже показалось так, пока все не взвесили и со стороны бизнеса тоже.
вижу кажется 2 вопроса: - Почему вас только камера беспокоит, там по тексту много разных компонент и инфраструктурных вопросов поднималось, не хочется перестраивать процессы по автотестам ни библиотеки аналитики через плагин тащить, ни гайды дизайнеров расшаренные на натив, не хочется при редизайне заного рисовать компоненты визуальные, которые шарятся по командам на натив. - Бизнеслогика есть во всех приложения, много ли, мало ли ее - в этом вся разница. На мой взгляд ее не достаточно в нашем приложении для того чтобы скрещивать Native и еще что то, ну например KMM. Бизнеслогику можно вынести на сторону сервисов. Если тащить все таки в клиенты, то получим франкинштейн, до такой необходимости и неизбежности опять же недотягиваем
"Ну и замечание про "экс-бэкенд" не понял –" Это был сарказм адресованный async await. Ведь в Native он появился позже, чем в Dart, ИМХО полезность фичи прям очевидна, но увы больше в бэкенд разработке.
"Невольно став сместителем существующего..." видимо необходимо расшифровать. Решение уже было принято до меня, а я лишь был назначен на это место, чтобы данное решение грамотно воплотить в жизнь. Это не первый опыт, когда меня нанимали для того чтобы драйвить команду переходить на Native
Разумеется не только, был упомянут функционал только уже реализованный на Flutter и довольно общий, в будующем надо было бы подключать собственную аналитику и многие другие платформенные компоненты, характерные для нашей компании и реализованные на Native.
Согласен — две крайности. Они тут полезны в том что мы хотим понять. Я считаю что оба программиста молодцы, а вот косячник — менеджер.
Программисты вообще всегда молодцы, живут в своем мирке и как знают мирок свой так и пишут.
А вот менеджеры, блин, ну неужели они не могу объяснить какой будет проект:
1) прототип для показа — который выкинут и надо код писать быстрее пусть с утечками памяти немасштабируемый и т.д. (Маркус тут даже перестарался, все можно было написать в main()),
2) серезный проект с ТЗ, которого действительно утверждено — надо показать это ТЗ, диаграмки состояний нарисовать, объяснить как в дальнейшем может развиться система. Какие перспективы сопровождения (Борис не виноват что ему не предоставили полной информации, однако он правильно начал с минимумом абстракций, а потом их наращивал, основной бедой его был повар, который является инициатором выпечки — он фабрика, а не плита, плита — инструмент, который на ровне с рецептом должен использоваться поваром и просто поддерживать температуру определенную, из-за неправильного повора рецепт вперся в плиту зачем-то и пошло поехало, Борис действительно не мог остановиться и развернуть архитектуру вовремя из-за косноязычности менеджера, кирпичи выпекать стало не кому выходит, кстати хороший паттерн чтобы не плодить под пирожки своих поворов — мост / Bridge)
3) стартап, в котором надо делать быстро и с возможность масштабирования. Тут любой подход хорош, единтсвенное надо реализовывать его качественно. Если разобратся в подходах данных программистов, то Борис пишит объектно-ориентированный код, а Маркус — процедурно-ориентированный, ну и кто сказал что последний сложно тестировать? Можно и нужно поколоть его основные методы на составляющие и их так же легко тестировать как объекты. Разница их подходов лишь в том, что у Бориса есть модель объектов, она более наглядна, чем математическая модель Маркуса. А код один и тот же, просто дайте процедурнику объектно ориентированный код, он его поймет, но напишит все посвоему и криво. А если наоборот, то объектник начнет все рефакторить излишни пытаясь структурировать. Так что лучше не мешать программистам, а грамотно менеджерам ставить задачки))
так программно иммено user и создает zip, так что проверку проходит легко. Атрибут запрета мы не выставляем, дабы можно было переносить документы на другое устройство
Да, в Documents. В сохранности остаются файлы только там. Но если закешированные файлы вы попытаетесь сохранить сразу туда, то из Apple Store вероятней всего придет письмо, о том что не следует держать такое обилие файлов, вероятнее всего вам необходимо перевести все в cashes. Вот тут и приходит на выручку zip
Извините, конечно! В данном контесте речь конечно не о бизнеслогике, а о решении. Тоесть один парсер — одно решение, другой парсер или протокол — это другое решение. В данном контексте как раз таки паттерны позволили
«Но это не позволяет заменять одни решения на другие. Возможно речь об интерфейсах?»
так что еще как позволяет!
Согласен: в данной задаче использовался Заместитель для того чтобы изолировать реализацию парсинга. А вот медиатор кстати скорее в задаче кеширования, для того чтобы подменить данные, загружаеммые с сервера локальными. Композитор используется на стыке взаимодействия поставщика данных и кешером с одним и тем же парсером/сериализатором.
Цель наша, да, пиар — какие мы крутые разработчики, создаем крутой продукт.
Поделились опытом, тестами и исходниками.
А вы тут какую цель преследуете? Можит мы вам не подходим по интересам?
>> Многие разработчики используют шаблоны проектирования. Но это не позволяет заменять одни решения на другие. Возможно речь об интерфейсах?
Речь о бизнеслогике. Если нужно кешировать не на день, а до удачного получения соединения с интернет в нескольких логически связанных отделениях, то пишется потомок одной из ветки классов ответственного за кеширование, далее он объявляется ведущим в выборке данных одного или нескольких логических отделений. Занимает это пару строчек кода, а работает на данном принципе кеширования все приложение.
>> Это не назначение паттерна прокси. Это всего лишь следствие его применения.
Согласен, у паттернов нет назначений, но мы легко находим им применение
дык разные Java были. Google чудь не засудили за то что она взяла проваславную Java
Выше в коментариях я расшифровывал смысл строк "стал невольным сместителем", это означает, что решение было принято до того как автор стал руководителем, и смысл автору вникать в технологии, от которых в компания отказываются и без него? А вот причины разумеется изучены и изложены в этой статье, вы кстати ее читали?
Если бизнес уже согласился, значит ему это выгодно, я кажется упоминал в статье какую выгоду получит бизнес.
Довольно смело пишите за автора, готов взять секретарем)
Возможно вы и правы, ТСД, которые мы кстати использем для Web версии пунков выдачи заказов, стоит адаптировать и под мобилки, уверен мы еще вернемся к этой теме, могу только сказать что мобильный телефон удобен как раз своей мобильностью, а приделывать к нему еще и сканер, да еще который может привести к потери автономности мобилки - все это уменьшит преимущества, ну мы просто спрашивали наших сотрудников, которые пользуются приложением. Тем не менее спасибо за идею, возможно сотрудники ПВЗ изменят свое мнение и мы вернемся к теме ТСД.
Я бы сказал что это было рациональное обоснование того выбора, который был сделан в пользу Flutter в самом начале, ведь он более чем оправдан. Сейчас это уже не обоснование, а констатация фактов пройденого опыта, эксперемент завершен, проект продолжается с новыми силами.
Про плагин камеры согласен, еслиб это была одна проблема и было в компании куча энтузиастов ее решить никто бы не парился, и учитывая что плагинов пришлось бы еще немало написать, тут я планы не могу рассекречивать, но они правда есть, смысл во Flutter потеряется бы довольно быстро
народу стало меньше, я не стал этим козырять ибо сравнивать с Flutter проектом некорректно, он шел не по роудмапу, а по иттерационным изменениям, нам проще так как знаем точку, в которую должны придти.
Я бы сказал что выбор не странноватый, а спорный. Мне тоже показалось так, пока все не взвесили и со стороны бизнеса тоже.
вижу кажется 2 вопроса:
- Почему вас только камера беспокоит, там по тексту много разных компонент и инфраструктурных вопросов поднималось, не хочется перестраивать процессы по автотестам ни библиотеки аналитики через плагин тащить, ни гайды дизайнеров расшаренные на натив, не хочется при редизайне заного рисовать компоненты визуальные, которые шарятся по командам на натив.
- Бизнеслогика есть во всех приложения, много ли, мало ли ее - в этом вся разница. На мой взгляд ее не достаточно в нашем приложении для того чтобы скрещивать Native и еще что то, ну например KMM. Бизнеслогику можно вынести на сторону сервисов. Если тащить все таки в клиенты, то получим франкинштейн, до такой необходимости и неизбежности опять же недотягиваем
"Ну и замечание про "экс-бэкенд" не понял –"
Это был сарказм адресованный async await. Ведь в Native он появился позже, чем в Dart, ИМХО полезность фичи прям очевидна, но увы больше в бэкенд разработке.
"Невольно став сместителем существующего..." видимо необходимо расшифровать. Решение уже было принято до меня, а я лишь был назначен на это место, чтобы данное решение грамотно воплотить в жизнь. Это не первый опыт, когда меня нанимали для того чтобы драйвить команду переходить на Native
Разумеется не только, был упомянут функционал только уже реализованный на Flutter и довольно общий, в будующем надо было бы подключать собственную аналитику и многие другие платформенные компоненты, характерные для нашей компании и реализованные на Native.
Программисты вообще всегда молодцы, живут в своем мирке и как знают мирок свой так и пишут.
А вот менеджеры, блин, ну неужели они не могу объяснить какой будет проект:
1) прототип для показа — который выкинут и надо код писать быстрее пусть с утечками памяти немасштабируемый и т.д. (Маркус тут даже перестарался, все можно было написать в main()),
2) серезный проект с ТЗ, которого действительно утверждено — надо показать это ТЗ, диаграмки состояний нарисовать, объяснить как в дальнейшем может развиться система. Какие перспективы сопровождения (Борис не виноват что ему не предоставили полной информации, однако он правильно начал с минимумом абстракций, а потом их наращивал, основной бедой его был повар, который является инициатором выпечки — он фабрика, а не плита, плита — инструмент, который на ровне с рецептом должен использоваться поваром и просто поддерживать температуру определенную, из-за неправильного повора рецепт вперся в плиту зачем-то и пошло поехало, Борис действительно не мог остановиться и развернуть архитектуру вовремя из-за косноязычности менеджера, кирпичи выпекать стало не кому выходит, кстати хороший паттерн чтобы не плодить под пирожки своих поворов — мост / Bridge)
3) стартап, в котором надо делать быстро и с возможность масштабирования. Тут любой подход хорош, единтсвенное надо реализовывать его качественно. Если разобратся в подходах данных программистов, то Борис пишит объектно-ориентированный код, а Маркус — процедурно-ориентированный, ну и кто сказал что последний сложно тестировать? Можно и нужно поколоть его основные методы на составляющие и их так же легко тестировать как объекты. Разница их подходов лишь в том, что у Бориса есть модель объектов, она более наглядна, чем математическая модель Маркуса. А код один и тот же, просто дайте процедурнику объектно ориентированный код, он его поймет, но напишит все посвоему и криво. А если наоборот, то объектник начнет все рефакторить излишни пытаясь структурировать. Так что лучше не мешать программистам, а грамотно менеджерам ставить задачки))
Вывод из статьи: менеджеры виноваты во всем
Да, в этой книге очень хороший перевод, трудно не согласиться
«Но это не позволяет заменять одни решения на другие. Возможно речь об интерфейсах?»
так что еще как позволяет!
Поделились опытом, тестами и исходниками.
А вы тут какую цель преследуете? Можит мы вам не подходим по интересам?
Речь о бизнеслогике. Если нужно кешировать не на день, а до удачного получения соединения с интернет в нескольких логически связанных отделениях, то пишется потомок одной из ветки классов ответственного за кеширование, далее он объявляется ведущим в выборке данных одного или нескольких логических отделений. Занимает это пару строчек кода, а работает на данном принципе кеширования все приложение.
>> Это не назначение паттерна прокси. Это всего лишь следствие его применения.
Согласен, у паттернов нет назначений, но мы легко находим им применение