Увидел недавно комментарий к статье про сравнение MVVM и MVI (прикиньте, их до сих пор пишут), и кое-кто написал следующее:

Есть один метод обработки событий аля handleAction то это MVI, а если несколько разных методов это MVVM

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

Поэтому попробую объяснить… Вот у вас есть ViewModel, вы используете MVVM и решили, сейчас я добавлю единый state и у меня будет MVI. Нет не будет, у вас будет MVVM просто с единым state вместо нескольких полей, вот и все.

Главных отличий MVVM от MVI 2: реактивный подход для обработки событий, и state который меняется последовательно и только в одном месте.
Реактивный подход означает, что вы не просто делаете большой switch и в зависимости от action вызываете те или иные функции. Вы этот action отправляете в очередь, где он уже позже обработается. В этом и проявляется реактивность, мы обрабатываем все поступившие action по очереди, друг за другом, и прикладываем к обработке текущий state, но об этом далее.

Ключевое отличие между MVI и MVVM с единым state – изменение этого самого state в одном конкретном месте последовательно. Если у вас несколько мест где меняется state, то вся идея unidirection data flow идет лесом. Если два метода будут одновременно менять state, то он может оказаться в некосистентном состоянии, нет никаких гарантий. Даже если вы поставите lock и в один момент времени state будет менять только один поток, все равно вы не контролируете порядок, это не реактивный подход. Когда по коду раскидано изменение состояние, ты попробуй отдебажить все это дело, когда у тебя куча асинхронщины.

Вся идея именно в том, что action отправляются в очередь, накладываются на текущий state, генерируется новый state в одном месте и все повторяется заново. Поэтому все чуть сложнее чем просто зафигачить один единый state во ViewModel.

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

Меня в край уже заебал Яндекс. Это просто немыслимо, меня умудрилось расстроить каждое приложение экосистемы. Думали я только Gradle могу хейтить? Сегодня я сделаю исключение!

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

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

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

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

Ну как вам UX? Правда здорово? Я думал я с ума сойду от ярости! Это же блять ваш банк, ну сука сделайте вы сами еще один запрос и сами добавьте свою же карту! Ну это же абсурд, они не могут двумя командами договорится чтоли?

Чтобы вы понимали, у нас только что упал кубернетес который находится угадайте где?) Правильно на серверах Яндекса. Это правда так совпало, не то, чтобы я ждал когда все наебнется чтобы выпустить пост. Ну или они возможно так мстят, обидчивые однако...

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

Ktor, я взял, потому как он казался легковесным и простым, все на kotlin и корутинах. Для меня как для мобильного разраба бесспорный плюс. Правда в этой простоте и кроется недостаток. Недостаток которому подверженны Compose и корутины в целом. Простые вещи делать страшно просто, а сложные вещи в разы геморнее, чем в том же Spring.

DI завязан на koin, который как вы знаете я очень люблю и уважаю, нет готовых инструментов, чтобы хранить сессии в редис и для авторизации нужно оборачивать функции обработки запросов в другие функции (почти как Compose только для бэка). В Spring такие вещи уже давно решены и делаются одной аннотацией.

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

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

Я на канале никогда не писал про игры, но про эту не могу не написать, настолько она откликнулась в моей душе. Я уже давно видел рофлы про опилки в суп и детский труд, но не вдавался в подробности откуда это. Итак – frostpunk.

Если вдруг про нее не слышали. Суть сюжета: Температура на всей планете снижается быстрыми темпами, упала до -20 и продолжает уменьшаться. Вы с группой людей отправляетесь на север в поисках убежища. Гениальное решение верно? Да! Ведь именно на севере расположен генератор тепла, вокруг которого вы возводите поселение.

Тебе как руководителю группы нужно построить город и организовать добычу ресурсов так, чтобы всем всего хватило, все не поубивали друг друга и не замерзли к херам. Задача не из легких, коммунальщики в Питере до сих пор не научились.

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

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

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

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

В случае, если я захочу сменить компанию, вероятнее всего я буду собеситься как обычный Android разработчик. Мне на собесе придется отвечать на вот эти ебучие вопросы: "А сколько методов в классе Object?", "Расскажи сколько раз вызывается onMeasure в CustomView", "А как бы ты ускорил RecyclerView?", "А ты знаешь что такое Json?"– господи убейте меня.

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

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

Да, справедливо, в целом я немного прихуел, но стоит пояснить. Я последние 2 года работаю в команде инфры: пайплайны, билды, метрики, эмуляторы для тестов вся вот эта фигня. Иногда я даже встречаю название своей позиции: mobile devops. Хотя по идее это не совсем devops, но да похер. По большому счету мне интересно продолжать этим заниматься.

Однако так уж вышло, что таких спецов оочень редко ищут вне команды. В подавляющем числе случаев в такие команды попадают люди, которые уже давно на проекте и один раз имели не аккуратность сказать, что им хотелось бы чуть глубже покапать gradle. При этом если ты приходишь с рынка тебе вероятнее всего скажут: неее какой к черту yaml, нам нужно фичи делать, ты про покрас кнопок что-то слышал? Хотя больших проектов на рынке, где мои скилы пригодились довольно много.

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

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

Да и как тут устоишь, если сама вселенная намекает!

Cейчас период, когда релизы заморожены, все получили свои новогодние премии и в работе столько же смысла сколько в сюжете хентая. Кто-то проходит advent of code, кто-то уже просто чилит на работе, а я же решил провести небольшой эксперимент.

Я уже упоминал о боте, которого делаю на работе, я расскажу про него подробнее в своих проебах, но сейчас важно что он написан на ktor. Почему я вообще взял ktor? Изначально это был страшно мелкий проект, буквально один запрос. Как мобильный разраб, который последние лет 6 пишет на kotlin я решил, а почему бы и бэк не написать на чистом kotlin?

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

В преддверие праздника, ко мне явился призрак прошлого опыта: а что если, чисто ради прикола, попробовать часть функционала реализовать на Spring Boot? И вот чтобы вам передать мои ощущения, представьте, что вы разработчик, который всю жизнь писал веб сервисы на голом C, и тут вам показали Java.

Большая часть задач, над которыми мне в ktor приходилось что-то придумывать в spring решаются подключением зависимости. Даже код менять не нужно! Я столько времени потратил на подбор либы для конфигурации, а в spring оно из коробки работает. Причем сразу со всем форматами, ему вообще похую.

Правда у этого есть своя цена. Ты теряешь контроль, крайне высокий уровень магии, чтобы отследить откуда что вызывается, нужно прям знать что искать. Уровень магии высокий, но не до уровня магии в gradle, все еще далеко!

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

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

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

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

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

Короче, в этом году я все таки решил их накидать. Итак, погнали, в этом году:

👉 Посетил 9 городов в 5 разных странах. Путешествие года – Будапешт с Руинбарами и гуляшом
👉 2 раза выступал на митапе. Причем несмотря на то, что я мобильный разраб выступал на бэкендовских митапах. Возможно стоит задуматься…
👉 Сериал года – Хильда. Из всех мультсериалов которые я смотрел, он ближе всех к вайбу Гравити Фолз
👉 Игра года – Frostpunk. Про него делал отдельный пост.
👉 Покупка года – ортопедические стельки на заказ. Потрясающая тема, со временем действительно стал ощущать, что нагрузка в спине стала ниже при долгих прогулках и при этом любая обувь автоматически становится удобной. Да, пока другие айтишники покупают тачки и квартиры, я покупаю стельки… дэээ
👉 Софт года – Raycast. Это замена стандартного маковского Spotlight, только на стеройдах. Я через него делаю почти все, даже список МРов смотрю.
👉 Пожал 115 кг, это больше проеб года, чем достижение, тут есть куда рости 😄
👉 За год набрал 500 подписчиков. Это буквально в 2 раза меньше чем в прошлом, но учитывая, что за год я ни одной статьи не написал и делал большие паузы в постах, в целом результат норм. Нагоню в следующем
👉 Проект года – вот тут пусто. На работе я делал прикольные штуки, но прикол в том, что ни одну не успел довести до ума, они все больше прототипы, чем продакшен реди.

Это финальный пост этого года. Всем огромное спасибо, что продолжаете меня читать, всех обнял, приподнял, вы все очень клевые ❤️ С наступающим вас Новым годом! Желаю чтобы в следующем году было чуть легче.

Ну что как у вас начался рабочий год? Лично у меня с сообщение от мака: "Братан, помнишь у тебя прога такая была, Docker, ну так вот, больше нет это на самом деле вирус". Обожаю разработку, ничего не трогал, а оно сломалось.

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

Название прекрасное, разработчики судя по Github с Негерии, но жалко что не из СНГ, было бы гораздо вайбовее. Представьте аналог докера Colima и еще сделать аналог кубера под названием Gulag c оркестрацией контейтеров медом репрессии.

Недавно мне пришлось повозиться с системой написанной на node.js. Помните я много гадостей писал про Gradle. Что в нем много магии, у него странно работают кеши, что он жрет чудовищно много памяти. Ко мне пришло осознание, что я с жиру бесился. Gradle по сравнению c npm технология будущего. Фронтендеры, объясните мне, вы с этой херней как живете вообще?

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

Ладно gradle жрет дофига, но он хотя бы работает и говорит что ему не нравится (ну почти всегда)!

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

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

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

Смотришь одного, вроде все норм, ничего не продает и то, что он говорит даже вроде как логично. Затем смотришь другого, уже врача и оказывается, что первый все напутал и все вообще по-другому. Потом смотришь третьего и оказывается что этот врач вообще инфоциган, который продвигает свои БАДы, а первый просто питух. Ядрена, мать…

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

- А кофе полезный? Конечно полезный, 3 чашки в день для сердца вообще отлично…
- А кофе вредный? Конечно вредный, ты че дурачок, ты в себя черную жижу заливаешь, еще и сон потом плохой…

Штош, подумал я, хотя бы в IT нет такой проблемы. Ну тут сложно напиздеть, ведь все проверяется, любой код можно запустить, чтобы проверить что да, вот эта система действительно работает. Потом вспомнил что у нас есть такие вещи как чистый код, охрененная куча абстракций чтобы один и тот же код запускался одинаково, а еще у нас самый популярный язык это JS…

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

Однако когда больше изучаешь историю и причины его создания, все встает на свои места. Изначально язык разрабатывался под конкретные проблемы гугла. Им нужно было сделать инструмент, который бы позволял очень быстро создавать CRUD при этом был простой как сапог и быстрый как алкаш за 5 минут до закрытия КБ.

Почему именно новый язык? С++ слишком сложный, Python слишком медленный, а Java перегруженная, долго стартует и жрет дохрена.

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

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

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

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

Отсюда выходит и поддерживаемость решений. Ты пишешь код, да со страшным синтаксисом что глаза болят, но зато заходишь через 5 лет в этот же код и у тебя вообще никаких удивлений (нуу почти всегда…). Это сильно контрастирует c JS, где ты написал код, а через два месяца оказывается, что уже никто так не пишет и все к херам устарело.

Вы уже попробовали deepseek? Я осознал, что за все время существования канала, ни разу не писал про LLM. Ну так вот, если вдруг каким-то чудом вы миновали волну хайпа. Пацаны с Китая зарелизили модель которая, судя по бенчмаркам не уступает флагманской модели ChatGPT.

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

👉 К ней можно обращаться без VPN. Прям повеяло ветерком свободы, как будто опять в Казахстан съездил.
👉 Больше всего меня позабавил режим "DeepThink". Тут ничего нового, этот режим появился еще в модели o1 ChatGPT. Суть в том, что в модель добавляются токены "рассуждения". Однако если в o1 они скрыты в сервисе, то DeepSeek выдает их вместе с ответом.

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

Итак, Яндекс Музыка. Это крайне эмоциональная тема для меня, ведь я работал на этом проекте года 3 назад. Это кстати было мое первое выгорание, реальность с вертухи мне сняла розовые очки. Когда-то я думал, что во всех командах яндекса, просто нереального качества код, лучшие практики, гайдлайны, доки и т.д. Как говорил Торин: "Я никогда так не ошибался". Про мои впечатления от работы на этом проекте я пожалуй оставлю для другого поста.

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

Плейлисты. Swipe to Dismiss базовая тема, чтобы удалить трек из плейлиста, есть во всех приложениях, является самым базовым жестом. В Я.Музыке отсутствует, хочешь удалить трек нажимай на 3 точки, подожди Bottom Sheet и только потом удаляешь. Далее, вот ты включил плейлист, потом на странице трека решил, что все таки не, трек уже не нравится пожалуй уберу его. Нажимаешь на три точки и видишь, что трек нельзя убрать из плейлиста, только добавить. Чтобы убрать трек во время прослушивания, ты выходишь из страницы трека, идешь в список, нажимаешь на три точки и т.д уже обсудили в начале абзаца.

Подкасты. Я в основном Я.Музыку использовал для подкастов. Вот кстати алгоритм как включить подкаст в приложении. Зайти на страницу подкаста, найти нужный выпуск, нажать на выпуск, подождать (ничего не происходит), нажать на стоп, нажать на плей. Выйти из подкаста, зайти обратно, выгрузить приложение, загрузить обратно, снова включить выпуск, вот теперь заработало. Я бы не психовал, если бы так не происходило каждый 2-3 раз. Мне когда рассказали про Apple Podcast, я так ахуел. Что оказывается можно просто нажать на выпуск и он сразу начинает играть, без ожидания кеширования, без задержек, без выгрузки приложения.

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

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

Итак, Astro Bot. Игрой года в 2024 году стал Astro Bot, и я не понимаю, как так вышло.

В чем суть, с релизом PS5 Sony выпустила мини игру ASTRO's PLAYROOM. Платформер про робота, который бегает по внутренностям консоли и знакомит тебя с ее преимуществами. Игра с довольно простыми механиками, приятной рисовкой и кучей логотипов Sony. Вот это самый забавный момент, зачем повсюду логотип Sony? Наверное, чтобы люди вдруг не подумали, что игра про xbox.

Короче, игра настолько всем понравилась, что Sony решила ее допилить и выпустить как полноценный продукт. И не прогадали, игра взлетела. Все от нее в восторге, у меня есть друзья, которые без ума от нее. Правда я не понимаю, почему? Я не говорю что игра плохая, нет. У нее приятный геймплей, она очень разнообразная и красивая, нооо игра года?

Мне когда про нее рассказали, я подумал, наверное, они добавили туда кучу новых механик и полноценный сюжет. Я вроде видел вырезки с Кратосом из God of War. Возможно вся игра это рефлексия Sony об эксклюзивах, которые выходили последние 10 лет?

Неть, это все тот же самый ASTRO's PLAYROOM, только теперь ты бегаешь не по консоли, а по разным планетам. На этом все: никаких новых механик или сюжета. Ну сюжет там есть, на уровне детских мультиков типа Даши Путешественницы.

Неужели у нас год выдался настолько скудным на релизы, что игрой года стал платформер. Ну объективно это сложно назвать AAA игрой, особенно в сравнении с Wukong или Helldivers 2.

Как мне кажется дело в ностальгии. Ну ведь правда, когда в нее играешь, впадаешь в детство. В детство, где у тебя нет забот, нет релизов, нет gradle… Ты не испытываешь эмоциональные перепады из-за сюжета как в том же God of War. При этом у тебя очень быстро меняются миры, эдакий тик-ток на уровне всей игры.

В целом я бы советовал ее пройти, но только нужно выполнить два условия, чтобы она действительно зашла:
👉 Вы должны быть выгоревшим в угли
👉 Начать ее проходить под новый год (в некоторых планетах, там прям подходящая атмосфера)

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

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

Думаю что такое граф объяснять не нужно. Есть точки соединенные линиями. Точки это вершины, линии это ребра. Есть куча видов графов, но сейчас достаточно запомнить только вершины и ребра. Обход графа это просто алгоритм, чтобы посетить все вершины графа в определенном порядке. Есть два основных способа как это сделать:

👉 поиск в глубину
👉 поиск в ширину

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

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

def dfs(graph, start):
    visited = set()
    visited.add(start)

    stack = [start]
    while stack:
        vertex = stack.pop()
        for neighbor in graph[vertex]:
            if neighbor not in visited:
                visited.add(neighbor)
                stack.append(neighbor)

Если же это поиск в ширину, то все, то же самое, только для списка используем очередь:

def bfs(graph, start):
    visited = set()
    visited.add(start)
    queue = deque(start)

    while queue:
        vertex = queue.popleft()
        for neighbor in graph[vertex]:
            if neighbor not in visited:
                visited.add(neighbor)
                queue.append(neighbor)

Давайте на примере конкретного графа, представим, что у нас есть твое генеалогическое древо:

    Ты
   / \
Папа Папа

Ладно, ладно, ну вы сами знали на кого, подписывались, смотрите пример в картинке...

Нафига два разных алгоритма? Разные обходы нужны для разных целей. DFS хорошо подходит для поиска циклов: условие if neighbor not in visited в блоке else мы попадем только если у графа есть цикл. BFS же вроде как подходит для поиска кротчайшего пути, но я на практике такую штуку не реализовывал.