Согласен, что вещи могут показаться абстрактными. Как я выше описывал есть кастдев разработчиков и его результаты являются той самой метрикой. Она не единственная и в манифесте адвоката прописаны другие на которые я влияю.
Если говорить про dev -адвокаты -релы -помощники -коучи, то я согласен тут лишь от части. Да, такое бывает, не исключаю и сам сталкивался. Манифестом эту проблему в том числе постарался минимизировать, чтобы роль не была абстрактной и била в намеченные цели / метрики.
Если говорить конкретно про меня, то я наоборот из разработки и менеджмента мероприятий подался в адвокаты.
Спасибо за комментарий. Можете называть роль "менеджер по процессам". Юридичискими вопросами я не занимаюсь, но помогаю разработчикам заанбордится, влиться в комьюнити, довести до реализацию инициативу, понять как расти в компании. То есть в какой-то мере защищаю их интересы.
Под Computer Science имеется ввиду не матан, а общие знания об архитектурах ПК, ОС, компиляции, теории языков программирования и вот этого всего. С матаном порой пересекается, но совсем не об этом в первую очередь.
По поводу UIRefreshControl. Пофиксить его некоторые баги нельзя, особенно если хочется юзать спокойно с любыми наследниками UIScrollView без особенных UIViewController. Я навидался кривого поведения с ним (даже эпловых аппов), немного посмотрел как он устроен внутри через hopper и выкинул его нафиг. Так что совет всегда юзать его не самый лучший. Я бы сказал так, если пофиг на баги и хочется быстро поддержать рефреш — юзать, если хочется хорошо, то не стоит)
Так же могу дополнить, что демок больше десятка. Демо — это приложение с подключенными к нему необходимыми модулями и необходимой для них частью core-слоя. Ничего лишнего, только нужный юниту функционал.
1.) В монорепозитории один продукт — Авито. Так же в нем есть другие приложения, которые используются в качестве демок для более быстрой работы над проектом, так как демки содержат меньше кода и собираются быстрее.
2.) Для демок заведены отдельные таргеты в том же воркспейсе, что дает быстрый доступ ко всем демкам.
3.) Так как все наши зависимости живут в монорепозитории, то они объявлены как “development pod” и прописаны в “podfile” статическими путями. Они не версионируются, опять же потому, что все живет в одном репозитории и вся кодовая база проекта синхронизирована сама по себе. Изменения core-слоя происходят достаточно редко и они минимальны, так как мы стараемся делать простые интерфейсы, а на случай больших изменений у нас всегда есть фича тоглы)
Почему мы используем такую схему работы с проектом? Около года назад у нас были репозитории для каждого отдельного модуля/слоя, но это замедляло разработку, так как при изменении зависимости тебе нужно было сделать минимум 2 пулл реквеста и, скорее всего, порешать конфликты. Было долго и мучительно. Так как проект у нас один и он не шарит код с другими аппами, то схема с монорепой убрала всю боль и не принесла новой. В общем, нам это хорошо зашло)
А как же рассказать про Localizable.stringsdict? Ведь так часто требуется локализация с плюрализацией. Сколько отважных разработчиков положило головы создавая свои велосипеды, а ведь можно было…
Возможно я не прав. Пока не стал ковырятся с собственным тулчейном, но скажу, что в качестве Any (id) оказалось возможным передавать в objective-c функцию и чистые swift классы, и енамы, и структуры, и даже кортежи и дженерики. Внутри функции все это спокойно кастится к NSObject и можно вызвать любой метод NSObject протокола. Больше, конечно, ничего сделать нельзя толкового, так как такой тип в objc не может быть представлен, но факт есть факт. Сдается мне, что SwiftObject представляет в objc не только классы, но и абстракцию над типами, которые не могут быть в нем представлены другим образом. Интересно было бы изучить этот вопрос.
Круто, что собрали свой тулчейн и поковырялись в исходнидниках свифта, но в чем суть то оказалась? Доказать, что NSObject уродлив? (с этого началось и этим же закончилось) Или показать Ваше исследование? В итоге получилось немного сумбурно.
Ззаметил в статье несколько неточностей как по мне:
Формально конечно базовый класс остался и только для IOS платформы
все классы Swift которые явно не наследуются от NSObject теперь неявно наследуются от SwiftObject класса. Сразу сделаю поправку, что это имеет место только для IOS платформы. На non-IOS платформах (Linux например) такого нет так как нет необходимости.
А как же тогда macOS, watchOS, tvOS? Под них тоже вполне можно использовать Objective-C с тем же Foundation и NSObject. Писали бы тогда что это справедливо для платформ, в которых есть необходимость взаимодействовать с Objective-C рантаймом.
все классы Swift которые явно не наследуются от NSObject теперь неявно наследуются от SwiftObject класса
Разве? Больше похоже, что это класс, который представляет Swift классы которые наследуются от NSObject в Objective-C рантайме.
На сколько мне известно, не NSObject классы в рантайме Objective-C вообще не могут быть представлены. Пробовали ли Вы посмотреть во что компилится чистый Swift класс есть ли в нем все эти методы? Может у свифтовых структур и енамов они тоже есть?
Зачем эпплу ко всем свифт классам привязывать NSObject методы, если в рантайме Objective-C эти классы представлены быть не могут и в будущем, возможно, свифт будет жить без наследия objc? Как то недальновидно ведь.
Ну вот почему нет книги в нормальном формате для читалок? Тяжко же пдф масштабировать постоянно. Либо видишь только кусок страницы. либо шрифт мелкий. Когда же уже можно будет скачать книжку в удобочитаемом формате и наслаждаться ею сполна?
Все профессии важны, все профессии нужны. И пока еще нужны, и те, кто пишет велосипеды сам, и те, кто на них катается. Так что каждый решает сам, писать ли ему мобильное приложение под iOS или идти придумывать Swift в Apple. И в итоге выбирает материал для изучения в зависимости от интересов и способностей.
На киевском 2 вида электричек: морозно-освежающие и слегка испепеляющие. Либо ты замерзнешь пока доедешь до дома, либо можешь расплавить подошву ботинок об обогреватель. Что Вам больше по душе, выбирайте сами. Ах, да, про сиденья, туалеты и прочую утварь говорить вообще смысла нет. Это, конечно, хорошо, что мониторинг, все дела. Только вот не там, где нужно опять.
Спасибо за комментарий. Все так, вы абсолютно правы!)
Как говорится, кто не рискует...
Согласен, что вещи могут показаться абстрактными. Как я выше описывал есть кастдев разработчиков и его результаты являются той самой метрикой. Она не единственная и в манифесте адвоката прописаны другие на которые я влияю.
Если говорить про dev -адвокаты -релы -помощники -коучи, то я согласен тут лишь от части. Да, такое бывает, не исключаю и сам сталкивался. Манифестом эту проблему в том числе постарался минимизировать, чтобы роль не была абстрактной и била в намеченные цели / метрики.
Если говорить конкретно про меня, то я наоборот из разработки и менеджмента мероприятий подался в адвокаты.
Спасибо за комментарий. Можете называть роль "менеджер по процессам". Юридичискими вопросами я не занимаюсь, но помогаю разработчикам заанбордится, влиться в комьюнити, довести до реализацию инициативу, понять как расти в компании. То есть в какой-то мере защищаю их интересы.
Об этом можно почитать, например, здесь - https://abhimuralidharan.medium.com/method-swizzling-in-ios-swift-1f38edaf984f
По поводу UIRefreshControl. Пофиксить его некоторые баги нельзя, особенно если хочется юзать спокойно с любыми наследниками UIScrollView без особенных UIViewController. Я навидался кривого поведения с ним (даже эпловых аппов), немного посмотрел как он устроен внутри через hopper и выкинул его нафиг. Так что совет всегда юзать его не самый лучший. Я бы сказал так, если пофиг на баги и хочется быстро поддержать рефреш — юзать, если хочется хорошо, то не стоит)
2.) Для демок заведены отдельные таргеты в том же воркспейсе, что дает быстрый доступ ко всем демкам.
3.) Так как все наши зависимости живут в монорепозитории, то они объявлены как “development pod” и прописаны в “podfile” статическими путями. Они не версионируются, опять же потому, что все живет в одном репозитории и вся кодовая база проекта синхронизирована сама по себе. Изменения core-слоя происходят достаточно редко и они минимальны, так как мы стараемся делать простые интерфейсы, а на случай больших изменений у нас всегда есть фича тоглы)
Почему мы используем такую схему работы с проектом? Около года назад у нас были репозитории для каждого отдельного модуля/слоя, но это замедляло разработку, так как при изменении зависимости тебе нужно было сделать минимум 2 пулл реквеста и, скорее всего, порешать конфликты. Было долго и мучительно. Так как проект у нас один и он не шарит код с другими аппами, то схема с монорепой убрала всю боль и не принесла новой. В общем, нам это хорошо зашло)
Ззаметил в статье несколько неточностей как по мне:
А как же тогда macOS, watchOS, tvOS? Под них тоже вполне можно использовать Objective-C с тем же Foundation и NSObject. Писали бы тогда что это справедливо для платформ, в которых есть необходимость взаимодействовать с Objective-C рантаймом.
Разве? Больше похоже, что это класс, который представляет Swift классы которые наследуются от NSObject в Objective-C рантайме.
На сколько мне известно, не NSObject классы в рантайме Objective-C вообще не могут быть представлены. Пробовали ли Вы посмотреть во что компилится чистый Swift класс есть ли в нем все эти методы? Может у свифтовых структур и енамов они тоже есть?
Зачем эпплу ко всем свифт классам привязывать NSObject методы, если в рантайме Objective-C эти классы представлены быть не могут и в будущем, возможно, свифт будет жить без наследия objc? Как то недальновидно ведь.