Мне не нравятся вакансии, в которых очень мало написано про используемые технологии, архитектуру и т.п… В вашей текущей iOS вакансии на ХХ, если отбросить все лишнее, остается лишь swift. Но этого мало, почти все вакансии содержат столько же информации…
Вы используете ваш Mapper в отрыве от HTTP Client? Ведь обычно каждый сетевой запрос имеет фиксированный контракт. Добавить ассоциированный тип и сразу в него парсить. И вот уже из двойной прослойки можно выбрасывать SignalProducer<Data, Error> и сразу получать SignalProducer<MappingResult, Error> на выходе. А потом еще поверх вашего swagger файла написать парсер, который сразу будет генерировать enum с описанием сетевых запросов и ответов.
Очень очень позабавил факт того, что выпускники-разработчики СФУ получают больше, чем получают конкретно в СФУ ИКИТ. А забавным является то, что ИКИТ — институт информационных технологий. Резюмируя: разработчики из филфака эконома и т.п. получают больше, чем разработчики из института информационных технологий. Очень надеюсь что это ошибка. В противном случае профильное образование у нас в городах миллионниках крайне бесперспективное.
мобильные приложения должны быть более персонализированными
Соглашусь на 100% с этим высказыванием, но…
Приложение само понимает
За годы разработки iOS приложений я понял простую истину: приложение должно быть максимально тупым. Соответственно, само приложение ничего понимать не должно. Если вы реализуете данный концепт, то вам будет невообразимо трудно поддерживать/тестировать ваше приложение. Когда механизм даст сбой или вам потребуется его изменить, то вам придется выпускать обновление. А люди не очень любят обновляться. Я бы 100 раз подумал перед тем, как реализовывать вашу концепцию. Придется раздувать штат разработчиков под все платформы, где вы хотите эту «персонализацию» и т.п.
помимо контента предоставлять людям персонализированный UI?!
Может стоит посмотреть в сторону концепции, где приходящий с бэкэнда контент и есть UI. А персонализированный или нет — это уже дело умелых рук бэкэндщиков.
Например, в приложении OZON на главной показывается специальный персонализированный баннер с вашими текущими заказами, если они у вас есть. А если у вас нет текущих заказов — баннер скрывается. Или в клиенте Альфа-Банка на главной показывается телефон личного менеджера для определенных тарифных планов. Чем не персонализация?
Я не призываю менять свое мнение, но почему бы не подумать в сторону персонализации через бэкэнд. А сделать гибкий динамический UI под динамический бэкэнд — это уже дело техники. Вот, например, интересный подход.
P.S.
Так же есть триггеры: пришло пуш уведомление
Может все-таки WebSocket использовать вместо пушей? И тестировать и контролировать гораздо проще.
В каждой функции типа getNewMovies будет происходить одно и то же. Поэтому, данную обработку ответа к конкретному типу я бы вынес тоже в сетевой слой. Ну либо в слой поверх сетевого (тут каждому уж свое). Вот, почитать: habr.com/ru/post/338380
Я его продал, хотел еще больше мощи. Сделал хакинтош на i7-8700K. Покупал я миник тогда т.к. альтернативы не было. Вообще никакой! А сейчас она есть. Поэтому, не советовал бы брать. Сейчас есть смысл купить новый мак мини с i7-8700B на борту, 1100$ в минималке за i7 хорошая цена.
Автор, если не сложно, отпишись куда-нибудь спустя некоторый продолжительный период времени и расскажи: приходил ли кто-нибудь по твою душу и как вообще дела обстоят.
Может и больше, но шансы измеряются тысячными процента… Вот чем занимается типичный разработчик: ссылка.
А что не так с этим вопросом? Отличный вопрос и крайне важный.
Мне не нравятся вакансии, в которых очень мало написано про используемые технологии, архитектуру и т.п… В вашей текущей iOS вакансии на ХХ, если отбросить все лишнее, остается лишь swift. Но этого мало, почти все вакансии содержат столько же информации…
SignalProducer<Data, Error>и сразу получатьSignalProducer<MappingResult, Error>на выходе. А потом еще поверх вашего swagger файла написать парсер, который сразу будет генерироватьenumс описанием сетевых запросов и ответов.Соглашусь на 100% с этим высказыванием, но…
За годы разработки iOS приложений я понял простую истину: приложение должно быть максимально тупым. Соответственно, само приложение ничего понимать не должно. Если вы реализуете данный концепт, то вам будет невообразимо трудно поддерживать/тестировать ваше приложение. Когда механизм даст сбой или вам потребуется его изменить, то вам придется выпускать обновление. А люди не очень любят обновляться. Я бы 100 раз подумал перед тем, как реализовывать вашу концепцию. Придется раздувать штат разработчиков под все платформы, где вы хотите эту «персонализацию» и т.п.
Может стоит посмотреть в сторону концепции, где приходящий с бэкэнда контент и есть UI. А персонализированный или нет — это уже дело умелых рук бэкэндщиков.
Например, в приложении OZON на главной показывается специальный персонализированный баннер с вашими текущими заказами, если они у вас есть. А если у вас нет текущих заказов — баннер скрывается. Или в клиенте Альфа-Банка на главной показывается телефон личного менеджера для определенных тарифных планов. Чем не персонализация?
Я не призываю менять свое мнение, но почему бы не подумать в сторону персонализации через бэкэнд. А сделать гибкий динамический UI под динамический бэкэнд — это уже дело техники. Вот, например, интересный подход.
P.S.
Может все-таки WebSocket использовать вместо пушей? И тестировать и контролировать гораздо проще.
А как ваши коллеги из FINCH отнеслись к этому подходу? Это общие наработки компании или личный вклад?
getNewMoviesбудет происходить одно и то же. Поэтому, данную обработку ответа к конкретному типу я бы вынес тоже в сетевой слой. Ну либо в слой поверх сетевого (тут каждому уж свое). Вот, почитать: habr.com/ru/post/338380А можно подробнее про скорости компиляции. Как было, как стало? На каких машинах разработка ведется?