💎 Скидка на закрытый контент

Недавно мне сказали, что начали читать мой ноушен чаще, чем хабр. Это сильная мотивация придумывать больше идей, которые будут полезны мне и вам. А также потенциальная точка масштабирования.

Что вы можете получить за подписку?
🟣Большая база вопросов для подготовки к собесам, провалидированная экспертами из крупных компаний
🟣Сотня задач на кодинг-алгоритмы с разбором и комментариями
🟣Десяток уникальных статей про кишки и не очень iOS SDK
🟣Задачи на проектирование и систем дизайн: чаты, избранное, DI
🟣Задачи на рефакторинг
🟣Роадмап iOS разработчика
🟣Чат с крутейшими практикующими разрабами, где тебя не будут булить за глупые вопросы
🟣Многое другое

Предложение ограниченное (для старых подписчиков тоже действует скидка)

🚘🚘Подписку можно оформить через бусти или бота

SwiftUI: советы по оптимизации

Нативная разработка — это чаще лучший пользовательский и технический опыт. Приложения на нативе в 9 из 10 случаев смотрятся плавнее и красивее, но все зависит от рук разработчика. Любое приложение можно сделать медленным и забагованным, если у тебя руки рака.

Хорошего инженера от плохо отличает, что хороший хочет делать работу хорошо. И у этой оценки всегда растущие требования. Одно из них — оптимизация.

Мы знаем много советов по оптимизации UIKit, но со SwiftUI все не так очевидно.

Автор статьи собрала десяток советов, которые не всегда были бы очевидные:

🟣Для моделей используйте структуры вместо классов
🟣Избегайте AnyView
🟣Чаще используйте Lazy элементы
🟣Используйте @Stateи @Binding вместо @ObservedObject или @EnvironmentObject
🟣Используйте ForEach с явным id

И многие другие.

🌿 Mobile System Design: Проектируем чат как в телеграме

Чаты — это отдельный вид приложений. В нем нужно учитывать многие детали:
🟣Трафик
🟣Кэширование и его очистку
🟣Частоту обновления
🟣Скорость
🟣Масштабирование

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

В ноушене я попробовал набросать частую задачу из собеседований и жизни. Когда-нибудь в будущем выложу в гитхаб.

🌄 А я напоминаю, что завтра заканчивается скидка на ноушен. Подписку можно оформить через бусти или бота

#metal #advancedui

🎶 Смотреть со звуком

Metal in Action: Audio Player. Round V

Ультимативна версия визуализатора для аудиоплеера. Такая, что пришлось дунгрейднуть количество циклов volumetric rendering'a. Процедурное здесь все, кроме UI.

Дюна... одно из самых любимых произведений. Я старался объединить ключевые концепции этой вселенной: Арракис — можно увидеть на фоне с процедурными песчаными бурями, меланж — окутывает Арракис, блестит, развевается по волнам дюн и светится голубым при активных битах. Пустыня и приближение Шай-Хулуда видны в постоянном дрожании песков, синхронизированном под ритм музыки.

Буквы отрендерены через Signed Distance Function и поворачиваются по мере прогресса трека. Благо, это лишь одна функция и поворот на 90 градусов clockwise 🐭

Поверхность Арракиса, точнее песчаная буря, зависит от битов трека, на основе которых происходит вычисление хеш функции для Fractal Brownian Motion и создает уникальный паттерн для движения бурь; Настраивается практически все, а все что нельзя настроить - можно всегда переписать 😂

🏛 Polymorphic Blueprint

💎 Серия статей про билд систему

Быстрая скорость работы билда — главная цель крупных проектов. Будь это пайплайны CI/CD или сборка рабочего проекта все это имеет десятки или даже сотни рабочих часов.

Вы почти не увидите сейчас в сеньорных вакансиях, где бы не спрашивали о системах сборки. Это становится также важно, а может и важнее, чем хорошие архитектуры.

Я начал писать серию статей про системы сборок. В первой затронул:
🟣Зачем программисту думать о сборке?
🟣Framework vs Library
🟣Статические и динамические библиотеки
🟣Какие есть системы сборки: Xcode, Bazel, Buck

🌄 Получить доступ можно оформить через бусти или бота

🧬 Задачи на проектирование: кастомный Notification Center

Добавил в открытый доступ первую статью по кастомному Notification Centr'у. Я уже писал о нем ранее, а сейчас решил выложить полную статью в гитхаб.

Создание своего Notification Center встречается в крупные компании Окко, МТС, ВК. Данный пример не эталонный и скорее показывает одно из сотен решений. Он не гарантирует прохождение собеса, а лишь помогает ознакомиться с вариантами решений.

Поставленная задача такая:
🟣Запроектировать класс
🟣Сделать его thread safety
🟣Сделать его memory safety
🟣type safety

В статье будет 3 примера, которые иттеративно улучшаются в зависимости от поставленых требований: от худшего к лучшему

💎 Больше других задач можно получить тут через бусти или бота

#wwdc24 #swift

🔗 Consume noncopyable types in Swift

Одна из лучших сессий в этом году. К ней будут возвратятся снова и снова, а важность представленных изменений (во многом реализованных в Swift 5.9) довольно велика. Заложенные принципы и концепции фундаментальны и основополагающи для новых семантик, охватывающие эффектом домино все что есть (ибо те, кто поглядывает в текущие снепшоты Swift видят изменения даже базовых вещей).

При проектировании нового типа у вас уже есть контроль над тем, может ли кто-то глубоко копировать (deep copy) его значения. То, чего у вас нет контроля, это может ли Swift автоматически копировать его. Copyable — это новый протокол, который описывает способность типа быть автоматически скопированным. Как и Sendable, он не имеет требований к членам - или же является протоколом-маркером (marker protocol).

• По умолчанию, каждый тип инфериться как Copyable
• Каждый тип пытается автоматически конформить Copyable
• Каждый дженерик параметр автоматически требует, чтобы тип, который вы используете в качестве плейхолдер-типа, был Copyable
• Каждый протокол и ассоциированный тип автоматически требуют, чтобы конкретный тип конформил Copyable
• Каждый boxed тип протокола автоматически композится из Copyable

Но не все типы должны и могут быть копируемыми по умолчанию. Я уже писал несколько раз про некомируемые типы или ~Copyable протокол. Важность этого изменения сложно переоценить, а прочитать Ownership Manifesto будет полезно всем; Возможность копировать или некопировать тесно связана с концепцией владения (ownership). Разработчики Swift не сильно об этом задумывались, а многие до сих не знают, что у value types появился в Swift 5.9 c вводом некопируемых типов появился деинициализатор (SE-0390 Noncopyable structs and enums).

С вводом некопируемости value types и концепцией владения, мы получаем возможность не просто копировать, но и трансферить владение (ownership tranfer) таким типом, поглощать (consume) или одалживать (borrow). Это новые семантики управления владением.

🏛 Polymorphic Blueprint

💎 Вопросы для собеседований | Управление зависимостями | ч. 1

Я продолжаю собирать вопросы для проведения или прохождения собесов. На очереди частый блок, который я задавал, когда хотел по лучше покопать в сторону архитектур.

Управление зависимостями, наверное, самый важный блок. Как и кем будут передаваться данные сильно влияет не только на простоту работы с кодом и модулями, но и на скорость сборки.

В этой подборке вы найдете ответы на вопросы:
🟣 Что такое DI?
🟣 Чем отличается DI от DIP?
🟣 Чем отличается Service Locator от DI?
🟣Что такое статические и динамические модули?
🟣И другие вопросы

🌄 Подробные ответы и вопросы получить тут через бусти или бота

Марафон по проектированию

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

Я давно хочу сделать что-то вроде конфы или интенсивна по той теме, в которой хочу прокачаться. Собрать заинтересованных людей, кто дойдет со мной до конца, а потом тепло вспоминать этот путь вместе. Как облегчение после крутого путешествия, наполненного сложностью и вызовами. Тогда это казалось сложным и амбициозным, но сейчас очередным этапом нашего роста.

Как во время хакатонов или телеграм конкурсов. Я до сих пор не могу найти тот заменитель того чувства, когда мы с пацанами по 12 часов сидели и делали задачи, иногда даже не спав. Я как ветеран боевых действий, воспитанный в военное время. Который вернулся на гражданку, и хочет вернуться назад, не находя себя в спокойной жизни.
Поэтому я следую правилу лидерства и говорю, что если я не смогу найти, то возглавлю.

Такую тему я нашел. Это проектирование интерфейсов.

В рамках этого марафона мы будем в течении недели/две каждый день собираться на созвоны и проектировать приложения:
🟣разбирать частые кейсы на работе
🟣строить схемы и задумываться о корнер кейсах
🟣находить нюансы нашей платформы
🟣разбирать известные библиотеки и инструменты
🟣делать домашние задания и разбирать их
🟣памятные призы и призы за лучшие работы

Марафон будет доступен не для всех. Зеваки и проезжающие мимо не будут приглашены. Тут нет времени следить за каждым, кто захотел отвалиться или пришел потроллить. Ударная группа должна быть более собранная. Уровень подготовки любой.

Если тебе интересно или хочешь помочь с идеями, то ставь + в комменты или пиши в лс @lvbond. Формат и дата еще будут модифицироваться

Ну, а если желающих не наберется, то будет новый контент в ноушене

12 часов в день мы не будем заниматься, но еще подумаем