🧬 Поток и самурайская философия

Я не случайно выбрал 2025 аркой самураев и начал с книги потока. Ведь эти две темы имеют очень много точек пересечений. Да и вообще вся эстетика японских самураев очень часто находит реинкарнации в массовой культуре: от корней киберпанка до проработки главного супергероя комиксов — бэтмена.

Но это не только эстетичная обертка, но и крутой сборник упражнений для развития. Давайте общими мазками разберем сравнения и как я вижу эти концепции, которые помогут как в жизни, так и в учебе:

🕐 Концепция потока была разработана психологом Михаем Чиксентмихайи. Это состояние, при котором человек полностью погружается в выполнение задачи, испытывая радость, эффективность и полное слияние с процессом.

Основные характеристики Потока:
🔘Полное сосредоточение на задаче.
🔘Исчезновение ощущения времени.
🔘Чувство контроля и уверенности.
🔘Гармония между сложностью задачи и уровнем навыков.
Пример: художник настолько увлечён рисованием, что забывает про всё вокруг.

⚔️ Самурайская философия, основанная на кодексе Бусидо, подчёркивает дисциплину, уважение, мастерство и осознанность. Самураи стремились не только к физическому совершенству, но и к внутреннему равновесию.

Основные принципы:
🔘Сосредоточенность: Полное присутствие в моменте.
🔘Осознанность: Понимание своих действий и их последствий.
🔘Мастерство: Постоянное стремление к улучшению.
🔘Гармония с окружающим миром: Действия с учётом природы и других людей.

Пример: воин, упражняясь в фехтовании, полностью сосредоточен на движении, как на медитации.

Выбрав любой из путей можно прокачивать навыки:
- Глубокой концентрации
- Удовольствие от процесса
- Улучшение памяти и понимания
- Развитие навыков решения проблем
- Экономия временем

Карьерный фреймворк от Dropbox

Еще одна матрица компетенций, которая поможет определить разные ожидания от инженеров.

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

Интересные особенности фреймворка:

🔘описывает не только технические ожидания, но и лидерские и командные
🔘фреймворк помогает также оценивать и горизонтальный рост
🔘универсальность помогает развиваться абсолютно любой роли (дизайнер, менеджер, разраб)
🔘фреймворк сфокусирован на результатах и навыках, а не на стаже

Непопулярные инструменты в управлении памятью: Unmanaged

Продолжаю рубрику непопулярных решений в управлении памятью. В прошлом посте мы изучали метод withExtedndedLifetime. Сегодня поиграемся с кое-чем интересным. С MRC в Swift.

Unmanaged — это специальный тип в Swift, который позволяет работать с объектами, не управляемыми ARC (Automatic Reference Counting). Его задача — вручную управлять временем жизни объектов (увеличивать или уменьшать их счетчик ссылок), особенно при взаимодействии с кодом на C или Objective-C, где автоматическое управление памятью отсутствует.

Какие задачи решает?
🟣Старые C/Objective-C API: Например, работа с CoreFoundation, где ARC не применяется.
🟣Низкоуровневый код: Если нужно добиться максимальной производительности или работы с памятью.
🟣Тонкая настройка времени жизни объектов: Например, если объект создается в одном потоке, а освобождается в другом.

Полезные статьи:
- How to use Swift's Unmanaged
- Unmanaged by nshipster

🥲 100 вопросов для подготовки к собеседованию по управлению памятью

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

В текущей подборке:
🟣20 базовых вопросов для разогрева
🟣15 вопросов про SideTable
🟣10 Autorelease Pool
🟣15 про Reference vs Value Type
🟣10 Memory Layout
🟣10 Unsafe Pointers
🟣10 Stack & Reference promotion
🟣10 Copy-on-Write

P.S. С комментариями от Глеба Лукьянеца 😬

Это большая подборка вопросов без ответов. Можно использовать ее для подготовки к проведению и прохождению собеседований

Где вы такое видели? Я нигде. Впереди еще больше.

💎 Поддержать или получить доступ к материалам можно в бусти
🧬 И в боте трибьюта если вы не из СНГ (рекомендовано)

Инженер ли ты? Или какой главный навык оценивают на собесе

Даже правильный ответ на собесе не гарантирует успех.

На днях я проводил очередной собес и уже немного устал писать очередной отрицательный фидбэк кандидату. Ребята все приятные, неконфликтные. Часто даже выдают правильные ответы, но с совершенно пустыми глазами или без понимания своих же сказанных слов. Даже немного грустно. Это подвело сформулировать меня какой ключевой навык учат оценивать интервьюеров.

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

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

Интервьюеры оценивают инженерное мышление. Если кандидат имеет соображалку, то он может скомбинировать из кусков осознанной информации — уникальную. А если это просто набор пустых фрагментов, то непонятно куда это класть и всовывать.

Инженер может проанализировать A, B, C, D решения. Оценить их самостоятельно. Вычленить, разбить на атомы и собрать заново. Ему интересен процесс. В этом его разница от нейросети. Он может понимать контекс и делать ВЫБОР. А также нести ответственность за свое решение.

Ключевые черты инженера:
🟣 Любопытство и желание постоянно учиться. Способность анализировать проблемы и находить эффективные решения. Готовность адаптироваться к изменениям и новым условиям.
🟣Стремление к созданию новых решений, которые упрощают сложные задачи или улучшают существующие системы. Любой код можно улучшить и сделать вторую версию, привести к редизайну.
🟣Умение задавать вопросы, проверять предположения и рассматривать проблему с разных точек зрения.
🟣Теоретические знания должны всегда быть связаны с реальными задачами и их решениями. Если большинство знаний кандидата основано на чужом опыте, то это плохие навыки. Подробнее можно изучить в таксономии Блума
🟣Постоянное совершенствование. Развитие навыков, поиск новых инструментов и методов для повышения своей эффективности.

Именно это — ядро той самой мифической "инженерности". Без которого все наши навыки и знания сильно упадут в цене.

😏 Самая популярная задача на управление памятью

Начнем понедельник с разминки.

После 100 вопросов на управлении памятью (это только первая часть) есть амбициозная задача сделать 100 задач на управление памятью. Кстати, этот сборник помог все же мне сократить содержание будущей книги на две: одна техническая, а другая профессиональная

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

А задача выше из документации. Удивительно, но говорят и с ней бывают проблемы. Она же очень хорошо подходит для разминки и стартовой точкой для обсуждений устройства ARC. Почему и когда происходит очистка, есть ли тут retain cycle и другое.

Скидывайте свои любимые задачи

🧬 Управление памятью: SideTable, RefCount, HeapObject, Object Lifecycle

Продолжаем углубляться в тему управления памятью. На этот раз мы углубимся в исходники Swift и узнаем для чего нужны:
🟣SideTable: когда создается и зачем нужна
🟣RefCount: какие бывают счетчики ссылок
🟣Зачем нужен HeapObject
🟣Object Lifecycle и жизненного цикла объекта:
🟣И другое

С этим материалом вы закрепите понимание более глубоких вещей и хорошо прокачаетесь. До конца января я хочу еще разборать темы с Copyable, borrowing and consuming, Memory Safety и другие непопулярные вещи. Поэтому статей будет больше.

Предыдущие статьи:
🔘Управление памятью в iOS: Stack, Heap, RAM
🔘Управление памятью: MRC/MRR, ARC, Auto Release, Memory Leaks
🔘100 вопросов для подготовки к собеседованию по управлению памятью

Наверное, это уже самый объемный публичный материал про память в рунете.

💎 Поддержать или получить доступ к материалам можно в бусти
🧬 И в боте трибьюта если вы не из СНГ (рекомендовано)

Размер имеет значение: исследование виртуальной памяти в iOS

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

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

При отладке крупного iOS-приложения на устройстве автор столкнулся с постоянными сбоями приложения сразу после запуска. Это мешало выявлению и исправлению ошибок.

Автор выяснил, что в iOS размер виртуального адресного пространства зависит от объема физической памяти устройства. Например, устройства с более чем 3 ГБ ОЗУ имеют адресное пространство 15,375 ГБ, из которых только 7,375 ГБ доступны для процесса. Остальная часть зарезервирована системой.

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

В iOS 14 было введено право Extended Virtual Addressing, позволяющее процессу использовать полное 64-битное адресное пространство. Добавив это право в файл прав приложения для отладочных сборок, автор смог устранить сбои, связанные с нехваткой памяти, и продолжить отладку.

🏥 Вывод:
Понимание особенностей виртуальной памяти в iOS и использование новых возможностей системы, таких как Extended Virtual Addressing, могут помочь разработчикам эффективно решать проблемы, связанные с ограничениями памяти при разработке и отладке приложений.