Касательно задания. Мы хотим привлечь разработчиков, которым интересен и важен продукт, который они делают, поэтому и задание продуктовое. Несмотря на то, что у нас в кросс-функциональных командах есть и выделенные продакты, и дизайнеры, мнение любого члена команды будет услышано. И здесь мы оставили большую свободу для творчества: участники могут решать, как делать сортировки, пагинации карт и другие логические вещи. Отсюда задача с переосмыслением главного экрана.
По поводу оценки пользователей: лучшие идеи мы проанализируем с командой и пригласим ребят поработать совместно уже над продакшн-версией.
И скидка в 45% — это не приз. Приз — это 1_000_000 рублей :) Скидка в 45% на курсы представляется для всех участников. А пользоваться ли ей, решать вам. Могу сказать о себе: мне часто приходится погружаться в другие стэки, хотя я изначально из мобильной разработки. К примеру, в своё время погружаться в машинное обучение я начинал как раз с небольших курсов для новичков, чтобы понять основные концепции.
Мы сейчас активно нанимаем специалистов на iOS и Android, за последние полгода команда мобильной разработки выросла почти в 2 раза, до 25 человек, под развитие новых продуктовых направлений. Если с помощью конкурса мы сможем найти ещё таланты, то будем считать, что всё не зря :)
Спасибо за хороший фидбэк)
— Платить 5$ в месяц и стать участником программы можно. А вот выводить деньги на карты РФ у меня не получилось. У них вывод денег идет через stripe, по факту штаты.
— Смысл отправлять статьи на рецензии кураторам есть. Только работает немного иначе, статья так или иначе проходит через кураторов и они решают курировать ли статью или нет. Если курируют, то очень повезло и это халявный промоут, если же нет, то можно написать им письмо на yourfriends@medium.com, но это очень редко работает, чтобы непринятую изначально статью закурировали. Но попытаться явно стоит.
Видел платное решение на 124 landmarks.
Но, повторюсь, что увеличение количества landmarks не приведет к улучшению работы алгоритма. Есть ряд параметров, которые более важны. Такие как обработка хаотичности камеры, работа с тенями, поворотами и тд.
Да, для грамотной работы нужно не только направление высчитывать, но и стабилизировать работу с поиском landmarks, так как камера в руках человека при всех переменах света, дерганиях и тд, является максимально хаотичным процессом. MSQRD в этом плане очень крутые.
Что происходит, если один и тот же label в сториборде может иметь разный текст? Как решается это в данном подходе?
Именно поэтому мы и решили сделать систему консистентной, а тут как говорится «лес рубят, щепки летят».
Даже если что-то поломают, то у нас проект просто не соберется. Именно в этом прелесть данного подхода.
Про локализацию storyboard, также указано, что эту проблему мы решаем протянув аутлеты в код, вместо того, чтобы локализовывать сами сториборды. Причины также указаны почему так сделано.
Но в целом, естественно всегда присутствует человеческий фактор) Вопрос лишь к сведению его к минимуму
К вопросу про время компиляции — безусловно увеличивается, ровно как и любой run script в билд фазе. Однако, в сравнении с swiftlint статическим анализатором, то время на порядок меньше занимает.
Что касается увеличение времени запуска, то опять же смотря какого. Если имеется в виду холодный запуск приложения, то естественно да, так как все строка хранятся в static memory. Но при замерах, которые мы проводили разница в проекте с 1000 строк просто микроскопическая что находится в пределах статистической погрешности.
Да, и если интересует жестко вопрос оптимизации времени запуска приложения, особенно на свифте, то рекомендую посмотреть видео-запись доклада с прошедшей конференции мобиуса (видео будут через неделю), там это детально расписано и получаются конкретные цифры, а не абстрактные. (Не знаю можно ли в комментах рекламировать видео или нет :)
У нас есть code-review абсолютно для всех репозиториев. Как правило такие коммиты смотрят разработчики, которые участвуют в проекте, поэтому дублирование находится на этом этапе, так как pull request просто реджектится для исправления.
Любое решение имеет место быть.
Плюсы нашего в отличии от нативного указаны в статье.
Главные из них:
— кроссплатформенность
— ошибки при изменении сразу находятся на этапе компиляции, а не в продакшене у юзера
— отсутствие магических строк в сторибордах и коде.
А что использовать в своих проектах, это решать каждой команде в зависимости от потребностей и нужд. Есть огромное количество проектов, которые не имеют и намека на локализацию и при добавлении нового языка это выльется в большое количество человеко-часов.
Создание сабклассов под эту задачу смысла вообще не имеет. В сториборде имеется в виду, что вы локализуете конкретно каждый сториборд, есть такая нативная фича, что под сторибордами создаются файлики с элементами и текстами. Но опять же есть куча минусов помимо указанных выше. Самый главный — нельзя вставить динамический текст без написания это в коде.
Что же касается разброса локализации в коде, то скорее это огромный минус чем плюс. При появлении нового языка, вам вместо одного места, в которое нужно добавить новые данные, необходимо искать все места, где нужно что-то менять.
Вопрос скорее риторический. Хотя iOS появилась далеко не вчера, многие вопросы до сих пор остаются нерешенными и неудобными, так как над системой работают такие же люди как и мы.
Касательно задания. Мы хотим привлечь разработчиков, которым интересен и важен продукт, который они делают, поэтому и задание продуктовое. Несмотря на то, что у нас в кросс-функциональных командах есть и выделенные продакты, и дизайнеры, мнение любого члена команды будет услышано. И здесь мы оставили большую свободу для творчества: участники могут решать, как делать сортировки, пагинации карт и другие логические вещи. Отсюда задача с переосмыслением главного экрана.
По поводу оценки пользователей: лучшие идеи мы проанализируем с командой и пригласим ребят поработать совместно уже над продакшн-версией.
И скидка в 45% — это не приз. Приз — это 1_000_000 рублей :) Скидка в 45% на курсы представляется для всех участников. А пользоваться ли ей, решать вам. Могу сказать о себе: мне часто приходится погружаться в другие стэки, хотя я изначально из мобильной разработки. К примеру, в своё время погружаться в машинное обучение я начинал как раз с небольших курсов для новичков, чтобы понять основные концепции.
— Платить 5$ в месяц и стать участником программы можно. А вот выводить деньги на карты РФ у меня не получилось. У них вывод денег идет через stripe, по факту штаты.
— Смысл отправлять статьи на рецензии кураторам есть. Только работает немного иначе, статья так или иначе проходит через кураторов и они решают курировать ли статью или нет. Если курируют, то очень повезло и это халявный промоут, если же нет, то можно написать им письмо на yourfriends@medium.com, но это очень редко работает, чтобы непринятую изначально статью закурировали. Но попытаться явно стоит.
И, на самом деле, это подходит к любой редактуре — это лишь набор советов, а прислушиваться или нет, остается на усмотрение автора.
И попробуйте grammarly — интересно мнение.
Но, повторюсь, что увеличение количества landmarks не приведет к улучшению работы алгоритма. Есть ряд параметров, которые более важны. Такие как обработка хаотичности камеры, работа с тенями, поворотами и тд.
Именно поэтому мы и решили сделать систему консистентной, а тут как говорится «лес рубят, щепки летят».
Про локализацию storyboard, также указано, что эту проблему мы решаем протянув аутлеты в код, вместо того, чтобы локализовывать сами сториборды. Причины также указаны почему так сделано.
Но в целом, естественно всегда присутствует человеческий фактор) Вопрос лишь к сведению его к минимуму
Что касается увеличение времени запуска, то опять же смотря какого. Если имеется в виду холодный запуск приложения, то естественно да, так как все строка хранятся в static memory. Но при замерах, которые мы проводили разница в проекте с 1000 строк просто микроскопическая что находится в пределах статистической погрешности.
Да, и если интересует жестко вопрос оптимизации времени запуска приложения, особенно на свифте, то рекомендую посмотреть видео-запись доклада с прошедшей конференции мобиуса (видео будут через неделю), там это детально расписано и получаются конкретные цифры, а не абстрактные. (Не знаю можно ли в комментах рекламировать видео или нет :)
NSLocalizedString(LocKey_main_continue, @"")
А у нас просто String.lockLeyMainContinue
Но идея в целом похожа
Плюсы нашего в отличии от нативного указаны в статье.
Главные из них:
— кроссплатформенность
— ошибки при изменении сразу находятся на этапе компиляции, а не в продакшене у юзера
— отсутствие магических строк в сторибордах и коде.
А что использовать в своих проектах, это решать каждой команде в зависимости от потребностей и нужд. Есть огромное количество проектов, которые не имеют и намека на локализацию и при добавлении нового языка это выльется в большое количество человеко-часов.
Что же касается разброса локализации в коде, то скорее это огромный минус чем плюс. При появлении нового языка, вам вместо одного места, в которое нужно добавить новые данные, необходимо искать все места, где нужно что-то менять.