Очень простой сборник. Для новичков идеально. Лучше всегда такое держать под рукой. Иногда рефрешить знания

https://tproger.ru/articles/sobesedovanie-ios-razrabotchika-voprosy-i-zadanija/

Хорошая статья по решению проблем читателей писателей с опять же замером производительности всяких мутексов

Как можем заметить NSLock в большинстве кейсах в разы (!) медленнее при записи и при чтении, чем барьер GCD и POSIX тредов

https://dmytro-anokhin.medium.com/concurrency-in-swift-reader-writer-lock-4f255ae73422

Изменения в структуре

Обычно такой текст пишут когда набирают красивую цифру подписчиков. Благодарят всех, пишут о ценности каждого. Но я напишу сейчас. Посмотрю в гугле какой там сегодня рандомный праздник и скажу, что в честь него. Как алкаш, который ищет повод, чтобы бахнуть очередную.

В сентябре прошлого года этот канал был создан как сборщик материалов. Тогда я был преподом в одной онлайн школе у 10 человек. Потом я написал пару статей и вот нас уже чуть больше 400.

Пора усиляться. Дальнейшие планы такие:

1️⃣ Добавить ранжирование контента на грейды. К каждой записи прекреплять тэг на какой уровень та или иная статья подходит.

2️⃣ Больше авторского контента. Делать библиотекой чужих статей ради вашего внимания и паразитировать на чужой работе особой мотивации нет. Буду выделять крутые статьи, или юзать как вводные, но приоритетней все же мутить свое:
- Разбор известных/инструментов либ и задачи их применения
- Марафоны по темам как с многопоточкой. Возможны сразу несколько марафонов в нескольких потоках (впереди UI и анимации, проектирование и много чего)

3️⃣ Возможно, как нас станет еще чуть больше, то будем делать закрытые чаты и создавать недельные интенсивы с домашним заданием и онлайн проверкой.

4️⃣ Мб в далекой перспективе усиление контентологов и создание какого-то свое микро-комьюнити, где важно качество, а не кол-во

5️⃣ Думаю о редизайне. Пздц конечно говорю будто это сайт и у меня какой-то бренд бук свой, но подумать об удобном формате материала и слоге стоит

С рандомным праздником Вас всех! Ценю, люблю.

Swift Concurrency Manifest

🟡 lvl: mid+

Отличный материал понять корни Swift Concurrency. С крутыми рефами и разборами проблем. Интересно почитать куда разрабы копали и где искали рефернсы, искали обоснования сложностям новых языковым конструкций.

Виден путь сделать язык не только популярным инструментом для мобильных разработок, но и взять рубежи на серверные проблемы

https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782

#lvl_mid

Тесты — это отдельная тема для споров.

В авито прям почти полный отказ от ручного тестирования , где QA специалист занимается в последнюю очередь ручными прогонами. Мб как-нибудь лучше об этом расскажу в марафоне про тестирования. Пока же можете почитать у моего тимлида тут

Считаю мощнейшим инструментом, который:
- Экономит время и деньги на ручное тестирование
- Дополнительно документирует код
- Ускоряют time-to-market
- Вся команда лучше заботится о качества

Вот еще крутейшая статья от @akaDuality

А еще мы ищем хорошего автотестера в нашу команду 💖 Если у вас есть такой, то пишите

MainActor

🟢 lvl: jun

MainActor — это глобальный актор, который использует main очередь для выполнения своей работы. Раньше нам приходилось DispatchQueue.main.async (1), чтобы обновлять ui. MainActor помогает с помощью компилятора делать это за нас автоматически.

Если же нужно выполнить код на главном акторе, то можно выполнить `MainActor.run` (2)

#lvl_jun

SwagGen

🟡lvl: mid-

Я большой сторонник адекватной автоматизации. Если есть силы сократить деньги и время на рутинных задачах — только вперед.

Кажется, что создание апи-моделей и описание нетворк слоя одно из самых рутинных и монотоных занятий. Скучнее только локализация на 18 языков ручным вводом из гугл-переводчика

Если ваша апи-документация в сваггере, то отличный повод затащить в проект генератор моделей и запросов. Юзал это на боевых проектах и видел в продуктах магнита

#lvl_mid

Локализации

Поговорим еще о теме автоматизации и о чехах.

Если приложение небольшое, то хватит пару Localizable.strings и ручками можно сидеть переводить в гугл переводчике. Есть история, когда будучи еще джуном и вебером нас заставили сидеть переводить текста в гуглпереводчике на четыре языка. Это было в одном риелторском агенстве

С русского -> на английский -> казахский -> чешский. Настоящее инженерское решение, не так ли?

Мы кстати неплохо так заработали по той сдельной системе, где были не разработчиками, а копипастерами. (отдельная тема вреда таких мотиваций)

Что получилось сложно представить, но легко предположить, как реагировали чехи. Они, мягко говоря, изумленно удивлялись новым придуманным словам, которые никогда раньше не слышали. Через какое-то время чехи перестали быть нашими партнерами

Какой же сценарий сделать норм локализацию? Для больших продуктов тема непростая. Особенно, когда у вас:
— 10-15 языков, которые ручками вы устанете вбивать
— Локали и валюты
— Системы счисления (мб даже другие измерения)
— Лайаут для текста (араб, иероглифы)

Мне кажется, идеальный вариант локализации — это только ключи, с которыми работает программист. например profile_catalog_price. Программист не должен переводить (упаси господь). Переводы должны генерироваться при билде из админки или в крайнем случае из эксель файла. Иначе любой чех перестанет быть вашим другом, locale_name_curva

Ну а здесь подробное руководство.

https://medium.com/codex/localization-workflow-in-ios-9f96b7f4388c

Но а с лайаутами, локалями и валютами надо поресерчить)

Увидел такую статью тут. Где спрашивают такое у сеньоров? Если на западе задают такие простые вопросы, то пора учить английский

https://tanaschita.com/20190715-ios-interview-questions-and-answers-swift

How Actors Work Internally in Swift

🟡 lvl: mid

Если кому интересно как работают акторы под капотом в свифт, то стоит почитать:
— Что такое глобальные акторы?
— Как создать свой актор?
— Что такое executors?

https://swiftrocks.com/how-actors-work-internally-in-swift

#lvl_mid

Так.

За эти 2 недели уже 5й человек из канала спросил меня по теме менторства. Поэтому я напомню, что да — я менторю людей. У меня даже в описании канала есть ссылка 😄

Чаще помогаю с:
— подготовкой к собеседованиям. Там выявляем точки роста и намечаем план развития.
— тестовым проектам к резюме. Предлагаю и веду проект с кодревью, чтобы оценивать его презентабельность и рыночную ценность.
— помогаю с текущими проектами на работе. Разбираем архитектуру проектов и помогаю с текущими задачами
— Провожу лекции для джунов и мидлов по техническим темам, чтоб подтянуть пробелы

Вы можете посмотреть отзывы и заказать услугу на солвери.
Или написать напрямую в телегу, тут скидка (без коммисий к сервису).

Вообще мотивация простая. Прокачаться самому как ментор, найти крутых коллег, кому-то даже предложить реферальные ссылки. У меня в сумме уже из всех платформ около 300 часов преподавания. Уже около 10м людям с помощью канала и менторства нашли работу. Кому-то даже с зп под 400к и его искали на позицию целый год

так что не стесняйтесь писать.

Подборки статей про оптимизацию

1. UILable может жрать больше, чем вы думаете. Аккуратно работать с DispatchSemaphore(value: 0) и почему для UIVIew не стоит юзать tag

2. Почему изображение длиной 2048 и шириной 1536 с размером изображения 590 КБ использует 10 мб памяти

3. Уже бывалые тут советы от swift-гита

4. Rendering performance и стандартные оптимизации 60 фпс

5. Статья из античных времен про производительность UIKit

Frame vs Bounds

🟢 lvl: jun

Одна из баз базовых на сессиях по UIKit, но почему-то многие часто валятся

🖼 Frame — расположение и размер view с использованием системы координат родительского представления (важно для размещения представления в superview).

Чаще говоря про фрейм вспоминают стену и рамку картину. Стена — это супервьюха, а рамка — это вью

🟩 Bounds — местоположение и размер представления с использованием его собственной системы координат (важно для размещения содержимого View или subview внутри него)

❓Когда использовать frame и когда использовать bounds.
Поскольку frame связывает местоположение view в superview, используйте его при внесении внешних изменений: ширины или вычисления расстояния между view и вериной его родительского view.

Используйте bounds для внутренних изменений: рисования или организации subview в пределах view. Также используйте bounds для получения размера view, если вы сделали какие-то преобразование для него.

Частый вопрос "А когда у нас может поменяться bounds?". Ответ — в ScrollView. На изменении своих координат строится вся модель скроллинга

#lvl_jun