асинхронно и параллельно не одно и то же, особенно в рамках Flutter, но согласен пачки данных не такие большие чтоб уделять этому внимание. Однако есть такой показатель как "H" вместо "4G" на телефоне, не все наши клиенты работают в крупных населённых пунктах.
*прошу прощения за сбои в форматировании, подправил статью Не понял про клиента, если имеется ввиду фронт, то их 2 web и мобильный Flutter.
Алгоритм не нужно изобретать каждый раз, т.к.: utils и repo реализована как дженерик и выделяется в библиотеку. Поэтому к новому модулю подключается библиотека и далее используется как: Repository<Pays> payList
Repository<Mail> mailList
На web перенести данный код не составит труда, тоже 1 раз.
Есть некое лукавство "Если сравнить с первым вариантом, то наш клиент сильно обгонит своих конкурентов" - он не может обгонять т.к. сидит и ждёт пока вы создадите что-то похожее на плохой автомобиль.
Т.е. точка 1 на шкале III равна точкам 3 на шкалах I и II Т.о. пользователь на шкале I может играться с колесом, видеть что строится шасси, пользователь на шкале II уже отмахал пару сотен км на самокате - велике - мопеде, а пользователь на шкале III сидит и слушает менеджера как он будет обгонять всех на свете, пока инженеры собирают фактически готовый автомобиль
только "краны", фактически это свободные подвесы, ракета давит на них своим весом и таким образом они её зажимают. Когда подъёмная сила становится больше силы тяжести, ракета начинает движение вверх, перестаёт давить на краны и они за счёт противовесов отклоняются... просто механика, без электроники и электрики
да, в статье особенно ужасны диаграммы, коорые не отображают реальных связей и отношений между элементами. Не указанны принципиальные отличия и новичку может показаться что все варианты одинаковые.
своими подходами к реализации UI и бизнес логики
Qt QML очень пхож на .net WPF
а Flutter очень близок к React
я работал со всеми 4мя технологиями, и первые 2 это реальная боль: тебе из бизнеслогики приходится оперировать элементами UI — this.intut.value = "..."; подход застрявший в энтерпрайзе 10ти летней давности.
Во Flutter же в widget передаётся модель данных, на основании которой строится UI.
А по поводу что у Qt нектар по сравнению с Flutter посмотрите на скриншот, разницы в вёрстке нет joxi.ru/xAeppljHM4Lve2
Частенько бывает, что modelView собирается из нескольких запросов dto, а бывает наоборот с бэка в dto приходит данных больше чем нужно для modelView и тогда вычищается дабы не тащить ворох данных на эран.
И это не из-за криворукости бэкендера, просто на каждое предстваление одних и тех же данных глупо создавать десяток однотипных api.
*простите за некропостинг
1) нет разницы десктоп или что либо другое (за исключением мелочей) 2) нет разницы приложение будет дёргать api "где-то в интернете" или "местный сайт"
Меня мучает вопрос: почему ковид так подкосил производителей чипов? Ведь это сверхчистое производство, там все ходят как космонавты, при входе их пылесосят, опрыскивают, а при выходе всю снарягу утилизируют...
Понятно, что работники потом идут в общественный транспорт, но разве нельзя организовать служебные автобусы, ведь на этих производствах не глупые люди работают?
Но с другой стороны производители чипов сейчас считай, что нефтяные магнаты, дефицит им на руку, можно получать большую прибыль при меньших продажах, затратах.
Да и CEO не проблема. Cоздайте html страницу с CEO содержимым и импортируйте её в index.html или прям в индексе разместите СЕО. Робот прочтёт а пользователь не увидит.
Простите, а в чём сложность XML для веб-разработчиков? HTML по нотации и есть XML... т.е. очень странно что человек понимает вложенность тега "table", "tr" и работу с их атрибутами, но мозг взрывается когда нужно работать с XML с данными карточки пользователя.
Помню как на десктопе здорово было указать адрес soap сервиса в VS и получит готовый клиент - просто вызывай методы.
Яндекс.Практика учит, что тимлид не должен работать работу, ему нужно устранять препятствия которые возникают на пути его линейных разрабов и обеспечивать коммуникацию с другими отделами/заказчиком(если нет отдела общения с заказчиком).
*кажется именно это и описано в основной части статьи, не увидел сильной завязки на топикстартере. Общение с заказчиком и настройка колхоза, проба новых граблей… линейный разраб не должен отвлекаться на это (ну грабли время от времени всем хочется попробовать иногда можно). Но фрагментарно общаться с заказчиком нескольким девелоперам одновременно это порождать многие проблемы в недопонимании.
Ещё кучу лет назад были статьи как люди переезжали на Кипр и прочую Европу для разработки ПО в области онлайн казино и подобных мобильных слотАвтоматов.
Т.ч. ворвались давно.
нельзя залететь сразу во флаттер без знание какой либо оси
Для «с нуля» как раз не нужно знать ОС. Тем более есть куча либ на pub.dev/packages
серьезную разработку а не про баловство
и то и другое определение это сферические кони в вакууме.
Вы скажите конкретно, что бы вы хотели сделать, а флатер не может этого вам обеспечить и вам нужно лезть в ОС. Сеть, уведомления, свои виджеты, карты, сложные анимации — всё это делается флатером и либами.
Или первая функция, которую вы хотите реализовать это оплата через applePay?
Также пользователи имеют возможность принять участие в агротуре: посмотреть, как организовано производство, поучаствовать в экскурсиях и мастер-классах.
Улавливание метана на городских очистных сооружениях - вот неиссякаемый источник.
асинхронно и параллельно не одно и то же, особенно в рамках Flutter, но согласен пачки данных не такие большие чтоб уделять этому внимание.
Однако есть такой показатель как "H" вместо "4G" на телефоне, не все наши клиенты работают в крупных населённых пунктах.
*прошу прощения за сбои в форматировании, подправил статью
Не понял про клиента, если имеется ввиду фронт, то их 2 web и мобильный Flutter.
Алгоритм не нужно изобретать каждый раз, т.к.: utils и repo реализована как дженерик и выделяется в библиотеку.
Поэтому к новому модулю подключается библиотека и далее используется как:
Repository<Pays> payListRepository<Mail> mailList
На web перенести данный код не составит труда, тоже 1 раз.
Есть некое лукавство "Если сравнить с первым вариантом, то наш клиент сильно обгонит своих конкурентов" - он не может обгонять т.к. сидит и ждёт пока вы создадите что-то похожее на плохой автомобиль.
Т.е. точка 1 на шкале III равна точкам 3 на шкалах I и II
Т.о. пользователь на шкале I может играться с колесом, видеть что строится шасси, пользователь на шкале II уже отмахал пару сотен км на самокате - велике - мопеде, а пользователь на шкале III сидит и слушает менеджера как он будет обгонять всех на свете, пока инженеры собирают фактически готовый автомобиль
только "краны", фактически это свободные подвесы, ракета давит на них своим весом и таким образом они её зажимают.
Когда подъёмная сила становится больше силы тяжести, ракета начинает движение вверх, перестаёт давить на краны и они за счёт противовесов отклоняются... просто механика, без электроники и электрики
Qt QML очень пхож на .net WPF
а Flutter очень близок к React
я работал со всеми 4мя технологиями, и первые 2 это реальная боль: тебе из бизнеслогики приходится оперировать элементами UI — this.intut.value = "..."; подход застрявший в энтерпрайзе 10ти летней давности.
Во Flutter же в widget передаётся модель данных, на основании которой строится UI.
А по поводу что у Qt нектар по сравнению с Flutter посмотрите на скриншот, разницы в вёрстке нет
joxi.ru/xAeppljHM4Lve2
И это не из-за криворукости бэкендера, просто на каждое предстваление одних и тех же данных глупо создавать десяток однотипных api.
*простите за некропостинг
1) нет разницы десктоп или что либо другое (за исключением мелочей)
2) нет разницы приложение будет дёргать api "где-то в интернете" или "местный сайт"
т.е. идея одна: берёте и делаете
Меня мучает вопрос: почему ковид так подкосил производителей чипов? Ведь это сверхчистое производство, там все ходят как космонавты, при входе их пылесосят, опрыскивают, а при выходе всю снарягу утилизируют...
Понятно, что работники потом идут в общественный транспорт, но разве нельзя организовать служебные автобусы, ведь на этих производствах не глупые люди работают?
Но с другой стороны производители чипов сейчас считай, что нефтяные магнаты, дефицит им на руку, можно получать большую прибыль при меньших продажах, затратах.
Да и CEO не проблема. Cоздайте html страницу с CEO содержимым и импортируйте её в index.html или прям в индексе разместите СЕО. Робот прочтёт а пользователь не увидит.
Зашёл посмотреть картинки, а тут одна вёрстка ?
Порадуйте людей, какое же волшебство творит этот Magento 2 UI Components
Простите, а в чём сложность XML для веб-разработчиков? HTML по нотации и есть XML... т.е. очень странно что человек понимает вложенность тега "table", "tr" и работу с их атрибутами, но мозг взрывается когда нужно работать с XML с данными карточки пользователя.
Помню как на десктопе здорово было указать адрес soap сервиса в VS и получит готовый клиент - просто вызывай методы.
Хорошая аналогия... и кажется да, предприниматели любят страдать.
*кажется именно это и описано в основной части статьи, не увидел сильной завязки на топикстартере. Общение с заказчиком и настройка колхоза, проба новых граблей… линейный разраб не должен отвлекаться на это (ну грабли время от времени всем хочется попробовать иногда можно). Но фрагментарно общаться с заказчиком нескольким девелоперам одновременно это порождать многие проблемы в недопонимании.
Т.ч. ворвались давно.
Для «с нуля» как раз не нужно знать ОС. Тем более есть куча либ на pub.dev/packages
и то и другое определение это сферические кони в вакууме.
Вы скажите конкретно, что бы вы хотели сделать, а флатер не может этого вам обеспечить и вам нужно лезть в ОС. Сеть, уведомления, свои виджеты, карты, сложные анимации — всё это делается флатером и либами.
Или первая функция, которую вы хотите реализовать это оплата через applePay?
Какая — никакая но уверенность.