android,ios, windows, macos, linux, web, аврора(пока в процессе портирования). Ну и да, он очень нравится заказчикам, которые режут косты нанимая вместо 2 разработчиков одного и снижая TTM
Сношение мозга будет обычного размера(это же банк совсем без сношения нельзя). Почти у всех банков в мобильном приложении есть история операций со счетом. В этой истории будет отметка о снятии, у некоторых даже можно мелкую бумажку о снятии в электронном виде с цифровой подписью получить там-же.
Нет смысла делать realtime, нужно делать предсказание и двигаться на упреждение. Нет смысла крутить лазер, нужно крутить отражающие этот лазер. Ну и отдельный модуль с нейросеткой(распознающей людей в комнате) должен управлять гашеткой
Чем пользуются, то и знают. Кто виноват, что macos приятнее работе( клава отличная, дисплей просто великолепен, про тачпад вообще молчу) чем 99% ноутбуков на window? А iphone тупо красивее, а функционал тот же.
Субъективная позиция Более-менее нормальная типизация. Компонентный подход. Большая библиотека плагинов, которые работают работают одинаково на разных осях. Очень удобное асинхронное апи.
Я как-раз кстати прочитал статью. И вы знаете, я не увидел ни одного пункта, в котором были бы описаны причины переходит на натив с точки зрения бизнеса кроме
"захотелось перейти от количественного к качественному: более нативного поведения и вообще, чтобы ставили только пять звёзд"
Это предложение смысловую нагрузку потеряло на вычитке редакторами.
Вы инженер и руководитель, вы в отличии от бизнеса, который почему-то решил перейти на удвоенную трату бюджета и замедление разработки, которое произойдет через полгода, должны понимать что делаете, разбираться в том, что именно нужно переписывать. Бизнесу глубоко неважно, какое поведение у приложения их работников, бизнесу важно, получить заказанную фичу в четкий срок с понятным бюджетом.
Я вообще крайне смелый человек, особенно, когда вижу очевидно ошибочные решения. 90k$/y и поехали
Просто чтобы подытожить: - автор стал руководителем какого-то отдела не ознакомившись с технологией, которая используется на проекте - автор решил просто отказаться от годовых наработок, потому-что ему так удобнее - бизнесу это встанет в ушедших сотрудников (кто после флаттера станет писать на нативе ? Никто) - бизнесу это встанет в ожидание разработки нативных приложений - бизнесу это встанет в просранный HR- бренд, потому-что когда отдел разработки переводят на другие технологии насильно, это очень быстро расходится и вызывает негативные оценки компании Либо руководство озона крайне наплевательски относятся к инструментам, которые обеспечивают из базовую деятельность, либо какая-то внутренняя политика пошла по известному месту.
Мне кажется, что фронтенд не должен проектировать api. Фронтенд должен очень четко описать, что он хочет получить в api. А бэкендер должен очень ответственно и честно объяснить почему лучше сделать по другому.
Нельзя, иначе бан приложения.
Можно пример ? Ну что бы снять некоторую голословность.
android,ios, windows, macos, linux, web, аврора(пока в процессе портирования). Ну и да, он очень нравится заказчикам, которые режут косты нанимая вместо 2 разработчиков одного и снижая TTM
Сношение мозга будет обычного размера(это же банк совсем без сношения нельзя). Почти у всех банков в мобильном приложении есть история операций со счетом. В этой истории будет отметка о снятии, у некоторых даже можно мелкую бумажку о снятии в электронном виде с цифровой подписью получить там-же.
Нет смысла делать realtime, нужно делать предсказание и двигаться на упреждение.
Нет смысла крутить лазер, нужно крутить отражающие этот лазер.
Ну и отдельный модуль с нейросеткой(распознающей людей в комнате) должен управлять гашеткой
лучше final тогда уж
Мне кажется, что он нашел отличный баг благодаря, которому он получил 250k$.
Они, периодически, обеспечиваются выплатами на уровне зарплаты на эти 5 лет, особенно для специалистов такого уровня
Демократия...
Чем пользуются, то и знают.
Кто виноват, что macos приятнее работе( клава отличная, дисплей просто великолепен, про тачпад вообще молчу) чем 99% ноутбуков на window?
А iphone тупо красивее, а функционал тот же.
Нет и не будет
А есть ли хоть какая-то реальная задача и польза от этой игрушки ?
Да. Импортозамещение дашбордов - самая актуальная проблема It отрасли.
Китайская группа хакеров с названием их бэкдора sodamaster… казалось бы при чем тут башкирия ?
Субъективная позиция
Более-менее нормальная типизация.
Компонентный подход.
Большая библиотека плагинов, которые работают работают одинаково на разных осях.
Очень удобное асинхронное апи.
Я как-раз кстати прочитал статью. И вы знаете, я не увидел ни одного пункта, в котором были бы описаны причины переходит на натив с точки зрения бизнеса кроме
"захотелось перейти от количественного к качественному: более нативного поведения и вообще, чтобы ставили только пять звёзд"
Это предложение смысловую нагрузку потеряло на вычитке редакторами.
Вы инженер и руководитель, вы в отличии от бизнеса, который почему-то решил перейти на удвоенную трату бюджета и замедление разработки, которое произойдет через полгода, должны понимать что делаете, разбираться в том, что именно нужно переписывать. Бизнесу глубоко неважно, какое поведение у приложения их работников, бизнесу важно, получить заказанную фичу в четкий срок с понятным бюджетом.
Я вообще крайне смелый человек, особенно, когда вижу очевидно ошибочные решения. 90k$/y и поехали
Просто чтобы подытожить:
- автор стал руководителем какого-то отдела не ознакомившись с технологией, которая используется на проекте
- автор решил просто отказаться от годовых наработок, потому-что ему так удобнее
- бизнесу это встанет в ушедших сотрудников (кто после флаттера станет писать на нативе ? Никто)
- бизнесу это встанет в ожидание разработки нативных приложений
- бизнесу это встанет в просранный HR- бренд, потому-что когда отдел разработки переводят на другие технологии насильно, это очень быстро расходится и вызывает негативные оценки компании
Либо руководство озона крайне наплевательски относятся к инструментам, которые обеспечивают из базовую деятельность, либо какая-то внутренняя политика пошла по известному месту.
Может не стоит изобретать велосипед и просто использовать grpc ?
Мне кажется, что фронтенд не должен проектировать api. Фронтенд должен очень четко описать, что он хочет получить в api. А бэкендер должен очень ответственно и честно объяснить почему лучше сделать по другому.
Gui - просто сокращение механической работы. Что ворчать на него ?
OpenApi дает тот же самый результат, просто менее удобно