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

Когда-то я читал книгу Стивена Кинга "Как писать книги". Главное, что там мне запомнилось, кроме истории как он подтерся ядовитым плющем — это мысль, что хороший писатель делает постоянно две вещи: много читает и много пишет.

Эта мысль отражает весь цикл развития любого эксперта — впитывание и генерация знаний. Для производства хорошего продукта — нужно много впитывать. Это затрагивает любую область. Поэтому, помимо базы знаний, я собираюсь изучить множество книг и других источников. Заглянуть в каждый угол. Собрать сборник лучших источников и переварить их, чтобы дать апгрейд. Собрал интересные статьи и книги по теме "Управление памятью":

🟣ARC Documentation. Забавно, как мы игнорируем доку. Возможно, из-за ее сложности или неполности, но банальные примеры или информации из документаций, многих разрабов вгоняют в ступор.

🟣Исходники Swift'а. Конечно же, главный навык определять сеньора — это умение читать исходники. Зачем нам пересказы, если мы можем изучить первоисточники?

🟣Advanced Memory Management Programming Guide. Знать историю — важно. Для этого есть старая дока, которая для многих даже лучше, чем современная.

🟣Секции WWDC. Видео-формат дает дополнительное закрепление и фиксацию знаний.

🟣Блог Mike Ash'а. Наверное, самое громкое имя, на которое ссылаются все авторы статей про память. Это он рассказал миру про side table, memory layout и многое другое, за что вы не любите собесы

Вопросы для собеседований: RunLoop | ч. 1

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

🟣Что такое RunLoop?
🟣Какие основные задачи решает RunLoop?
🟣Как работают таймеры?
🟣Как RunLoop взаимодействует с очередями?
🟣И другие вопросы

💎 Получить доступ по скидкам можно тут или тут

👩‍💻Уникальное интервью с разработчицей из Apple

Знакомьтесь, Серафима. Это уникальная история, где девушка в 22 года получила первую работу в компании мечты.

За счет таланта и упорства. Без накрутки и обмана. Контрибьютив в swift и занимаясь своими проектами. В штат, а не контракт. Занимаясь развитием SwiftUI и Swift Concurrency.

Это как пройти игру на самых сложных настройках раньше всех. Когда Сима зашла в наш чат все мужики ущемились.

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

Также я уговорил Симу создать свой телеграм канал. Потому что Готэму нужны новые герои.

Подписывайтесь, Сима обещала что будет делиться новостями и фишками про SwiftUI и другими советами прямо из кухни.

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

После общения с такими людьми мотивация творить разрывает.

🧬 Задачи для собеседований: Управление памятью и Capture List

Самая главная тема в управлении памятью — захват ссылок. Нет ни одной другой практической темы. Мне всегда казалось очень странным, что кандидат рассказал про всякие кишки: sidetable, unsafe pointer, WeakObject, жизненный цикл объекта. Но не смог решить простую задачу с захватом ссылок. Прошлый квиз подтвердил, что эта тема требует отдельного разбора.

Лучший формат обучения — задачи с комментариями. Теория, лекции и вопросы — это лишь дополнительная вода, которая помогает усвояемости.

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

В этой подборке с ответами и комментариями я собрал:
🟣популярные классические задачи на захват Reference & Value типов, которые часто дают на собесах
🟣уникальные авторские задачи с комментариями, которые мы придумали лично
🟣практические задачи, которые встречаются в реальной жизни.

💎 Получить доступ можно на бусти и в телеграмм.

Техники устранения коллизий в разных языках программирования

Разница между кодером и инженером — в понимании "базы". Для кодера многое в работе компьютера — магия. Какие-то гномы крутят колесики в комьютере и наш код чудесным образом выполняется. В этом канале мы не приветствуем этот путь.

Computer Sience — это масштабная и глубокая наука. Она объясняет нам как работают привычные инструменты. Чем шире и глубже кругозор, тем лучше и крепче знания для решения рабочих задач. Даже вчера, созваниваясь со своим менти, он рассказал, что изучив работу управления памятью в Rust'е он лучше стал понимать как работает память в Swift'е.

Вдохновившись этим я решил собрать разные подходы решения одних проблем из разных языков. Начнем с решения коллизий:

Для нас хэштаблицы это магическое место, куда можно складывать элементы и брать оттуда за единицу времени. Есть некая хэш функция, которая вычисляет номер ячейки, но бывает так, что для нескольких разных объектов хэш функция вернет одно и тоже число. Если у вас 100 попугаев и 80 клеток, значит в какой-то клетке будет несколько попугаев. Это и называется коллизия.

🔗 Separate chaining

В данном подходе используется вместо одной ячейки используется двухсвязанный список. Соотвественно когда добавляется элемент, высчитывается номер ячейки, находится соответствующий список и добавляется в конец объект. Такой подход используется во многих языках программирования, в том числе в Java, Go, C++.

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

Посчитает ассимптотику по времени.
🟣Поиск элемента: в среднем O(1), в худшем случае O(N)
🟣Добавление элемента: в среднем O(1), в худшем случае O(N)
🟣Удаление элемента: в среднем O(1), в худшем случае O(N)

В Java есть оптимизация, если список разрастается и становится больше определенного количество элементов, то список превращается в сбалансированное двоичное дерево. Соотвественно сложность уменьшается до O(log N)

📂 Open addressing

Второй подход называется открытая адресация. Подход предполагает, что количество элементов для вставки не больше, чем количество ячеек в таблице. Если при вставке элемента оказывается, что ячейка уже занята, то смотрим на ячейку +1, если свободна то вставляем туда, иначе проверяем +2, +3 и так далее. Есть мини оптимизации, позволяющие не линейно прыгать по ячейкам в поисках свободного слота, а квадратично.

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

Сложность по времени.
🔘Поиск элемента: в среднем O(1), в худшем случае O(N)
🔘Добавление элемента: в среднем O(1), в худшем случае O(N)
🔘Удаление элемента: в среднем O(1), в худшем случае O(N)

Такой подход тоже находит свою реализация в языках программирования, таких как Python, Ruby, Rust.