🌿 Техники решения алгоритмов: Prefix Sum

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

Так, прежде чем взяться за решение задачи, я сначала хочу определить ее паттерн. Какую технику лучше применить?

Их не очень много, но достаточно, чтобы потратить время. Одна из таких техник — это prefix sum.

🟣 Когда она используется?
Когда нужно работать с суммами элементов подмассивов.

Основная идея — создать массив prefix, где prefix[i] равно сумме всех элементов до i индекса включительно.

Статьи для изучения
🟣Prefix Sums and Applications
🟣Algo & DS(1) — Prefix Sum Series in Swift

Задачи для закрепления:
🔴Product of Array Except Self
🔴Subarray Sum Equals K

📺 Вопросы для подготовки и проведения собесов: Core Data

Сделал сборник вопросов для самопроверки.

В нем затронул:
🟣Что такое Entity?
🟣Как работать с Context'ом?
🟣Чем отличаются реляционные базы от нереляционных?
🟣Как Core Data работает с многопоточностью?
🟣Как работают миграции?
🟣И другие вопросы

💎 Получить доступ можно по телеграм-боту со скидкой или через бусти

🌿 Детальный разбор SOLID: Что такое Dependency Inversion?

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

Первую статью я решил посвятить одному из самых труднопонимаемых принципов SOLID, на котором многие пробуксовывают.

В ней я постарался разобраться:
🟣Что такое DIP?
🟣Что такое модули верхних модулей и нижних уровней?
🟣Что такое зависимость в Swift?
🟣Где происходит инверсия зависимостей?
🟣Чем отличается Inversion of Control от Dependency Injection?
🟣Почему все покрывается абстракциями?
🟣Как найти нарушение в Swift Коде и многое другое

Много кода и примеров.

💎 Получить доступ можно по телеграм-боту со скидкой или через бусти

🖥 Подборка статей про Clean Architecture

Мы уже выяснили, что VIPER не тот Clean, о котором писал Мартин в своей книге. Но у иос разрабов есть заблуждение, что именно о нем хотел сказать он. Знает ли Мартин о существовании VIPER’а, который популярен только у иос-разрабов, и что бы о нем он сказал, остается только догадываться.

Для пруфов я собрал статьи, которые помогут разобраться что же такое Clean и почему нельзя назвать «чище», только если в паттерне UI слоя больше букв:

🟣 Архитектурные паттерны в iOS: привет от дядюшки Боба, или Clean Architecture
🟣Clean swift архитектура как альтернатива VIPER
🟣Оптимальный архитектурный шаблон iOS-приложения
🟣Building Testable and Maintainable iOS Apps with Redux
🟣Developing iOS applications with Uncle Bob’s Clean Architecture

Если у вас на собесах есть вопросы про архитектуры и паттерны, то очень советую дать четкие ответы в методичках или провести с интервьюерами диалог по выравниванию определений. Оценить адекватность вопросов и адекватность ответов на них. Распределить их вес по важности и нужности.

Тема архитектур очень холливарная и часто усыплена карго-культами.

Скиллы vs Грейды: никогда не бегайте за лычками

Прочитал пост у Стаса Цыганова и сразу внутри поднялась острая тема.

Во-первых, грейды не отражают скиллов. В книге "Growth as a Mobile Engineer" мы уже комментировали тему в чем разница роста по карьерной и профессиональной лестнице. Это два разных направления, где ваши скиллы никак не отражают вашу позицию и наоборот. Также мы уже проголосовали, что грейд имеет самую маленькую ценность для определения экспертности и интереса.

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

А самое главное, что матрица может давать ложную надежду, что вот прокачаю эти скиллы и ура – следующий грейд.

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

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

Я же считаю, что мы все просто "другие". Где-то важны одни скилы, где-то другие. Вопрос скиллсетов определяется окружением и личными предподчениями (а также размером дохода 😄)

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

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