ПРИЧИНА И СЛЕДСТВИЕ

Я уже упоминал в своей истории что я самоучка.

Несколько фактов:
— У меня никогда не было наставника/коуча. Ток друг из интерпрайза, с которым можно перетереть за ITшку.
— Я всегда был вне IT тусовок.
Только хакатоны на начале карьеры, но знакомств результативных я оттуда не выносил
— С 2015 года всю информацию я черпаю только из книг, интернета и анализа реального опыта

За 9 лет пришлось переработать огромное кол-во информации.Обособиться, сформировать свое видение:
❕Cамообразование это игра в долгую. Это как бежать ультра-марафон. Нужно всегда помнить зачем, почему ты это делаешь.

И когда ты долго над чем-то одним работаешь, без целей никуда, потому я начинал с такого:
🔸 Мне нужно обогнать среднестатистического выпускника ВУЗа — нужно найти работу
🔸 Нужно получить исчерпывающий ответ на вопрос: "Как создаются игры в реальности?" — нужно руководить разработкой проекта
🔸 Для максимально быстрого роста, нужно забраться туда, где мне дадут больше, чем я способен унести — стать lead'ом, когда по факту middle

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

При том для меня было важно:
🔹 Никаких подработок и распылений
🔹 Быть уверенным в том, что мои знания/навыки нужны и я не потрачу N лет впустую
🔹 Нужно получать максимально качественные знания

Долго анализируя то, что есть в информационном пространстве, я заметил такие особенности:
🔸Информации много, но качество низкое
🔸Даже если есть качественная информация, чаще всего ее сложно перепроверить самому
🔸Когда информацию можно проверить, часто она расходится

И по опыту изучения и осознания такого объема информации за 9 лет я сформировал главный, краеугольный принцип для себя:
🔻 Избегать следствия и работать только с причиной.

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

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

Этот принцип лежит и в основе этого блога.

Например посты:
▫️Когнитивная сложность ч.1
▫️Когнитивная сложность ч.2
▫️Проклятие знаний
▫️Продуктивность

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

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

Это всю эту информацию планирую сформировать в качественные стримы и курсы для людей, кто уже не вращает кубы 😬

Чтобы у всех у нас была качественная основа для принятия решений на реальных проектах.
Win-win так сказать 😊

Ставь 👍 если разделяешь и ценишь такой подход

Или может я совсем загнался и надумал все себе, напишите в комменты 📞

@UniArchitect #моя_история

РЕЛИЗ FastMigrations.Json.Net

10 месяцев назад я написал пост про версионирование приложения:
ВЕРСИОНИРОВАНИЕ Ч.1
ВЕРСИОНИРОВАНИЕ Ч.2

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

Многие из вас следили за разработкой в режиме реального времени у меня на стримах
👉Ссылка на плейлист👈
(есть субтитры на английском, так что смело закидывайте европейским коллегам 😅)

По итогу, слово сдержал, пользуйтесь на здоровье ❤️
https://github.com/vangogih/FastMigrations.Json.Net
Жмакайте на ⭐️, чтобы не потерять!
Версия 1.0.3 — production ready, можно смело внедрять к себе в проекты 💪

🔻Что изменилось за кадром:
🔸 Сделал CI на github actions, который прогоняет тесты на 5 версиях unity
🔸 Для тестов включил вычисление test coverage и задеплоил результаты на github pages
Кликните на бейджик Coverage, чтобы понять о чем это я 😜
🔸 Сделал отдельную сборку для benchmark'а
Просто чтобы понимать на сколько быстрее. Так-то в 5-7 раз!
🔸 Сгенерил через всемогущий ИИ иконку
Вот оно где будущее, когда прогеры могут нормальный логотипы для своих плагинов делать😂
🔸 Опубликовал плагин в nuget и openupm
🔸 Написал и оформил лучшее readme в своей жизни 🥺

Достаточно много осталось за кадром, но поверьте, по большей части там была монотонная работа, где я 95% залипал в документацию.
Ибо с github actions, pages я работал впервые

🔻Что я лично для себя понял про подобного формата работу:
🔹 Нужно иметь выдержку и самодисциплину
Честно, если бы я не пообещал и не начал всю эту активность со стримами, мне было бы сложно сохранить достаточный уровень мотивации чтобы закончить работу над плагином
🔹 Качественная упаковка open source плагина занимает около 50% времени от самой реализации
Я понимаю что плагин не большой, всего 400 строк кода, но я явно недооценил сколько времени уйдет на оформление, CI/CD и документацию
🔹 Дисциплина кода, коммитов, архитектура даже для маленьких проектов важна
Иначе чтобы сделать нормальный CI/CD без боли, придется перелопатить половину проекта

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

А до этого момента продолжу делиться инсайтами по разработке и архитектуре unity проектов!

Всем огромное спасибо, без вас этого плагина не было бы 😘

Кстати, в репозитории есть открытые Issue, ошибки в readme и xml-doc'ах
Не стесняйтесь внести свой вклад и стать contributor'ом 🫡

@UniArchitect

ЦЕЛЬ

Каналу стукнул год ❤️‍🔥

Много всего получилось сделать за это время:
— 90+⭐️ Шаблон пустого проекта с архитектурой, которую я стараюсь использовать на всех своих проектах
— ~50⭐️ Плагин для миграции json файлов
— 2 статьи на хабр:
- Архитектура unity проектов
- Миграция json файлов
— Написать несколько полезных welcome статей в другие каналы:
- Полиморфизм системы
- UnityEngine.Object == null
- Архитектура и рендер
— Посетить DevGAMM Lisbon
— Помочь найти работу одному крутому senior'у 😎
— Набрать 1400 крутых, активных подписчиков

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

За такой большой промежуток времени сложно быть последовательным если нет принципов по которым ты пишешь статьи.
Я для себя сформулировал их так:
🔸 Удобство чтения
Каждая мысль отделена отступом, каждые важный пункт выделен
🔸 Экономия времени читателя
Статьи должны экономить время, давая максимальную пользу.
Выводы должны быть однозначны и соответствовать выводам из источника.
🔸 Качество важнее времени
Не пытаться выдавить контент в какой-то срок.
Писать по кайфу, когда есть силы и желание. И не важно сколько времени прошло с последнего поста.

Я не планирую заканчивать работать над блогом, а наоборот, хочу его развивать.
Моя цель:
🔻 Создать единое место откуда разработчики с 1+ год коммерческого опыта работы с unity смогут найти всю информацию касательно сложных технических нюансов при работе с unity.

Все мы в знаем о таких блогах как: Catlike Coding, JacksonDunstan, Alan Zucconi
Я как самоучка вычитал все эти блоги вдоль и поперек.
И как никто другой хочу не только брать, но и отдавать.

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

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

Так что это только начало, человек я амбициозный и терпеливый.
Уверен что все получится 💪

Спасибо каждому за то что остаетесь со мной 🥰

Ставь 👍 тебе по кайфу такая движуха!

@UniArchitect

С ПОЛЕЙ РАЗРАБОТКИ: REVERT MERGE COMMIT

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

Ситуация:
Есть баг, которые вы правите перед релизом. У вас в голове два решения:
🔸 По уму, но дольше и большим объемом регресса.
🔹 Поправить точечно, грязно, но быстро, внедрившись в другую систему.

Конечно как и подобает доблесть, выбираем первый вариант. Делаем фикс, примерно в 3-6 коммитов, проверяем в редакторе, отправляем в QA.

И вроде опыта достаточно, много всего знаешь и проверил все перед заливкой, но:
🔹 На мобилках фикс не работает.
Там другое графическое API, отличное от редактора и там твой баг вообще не исправлен, а наоборот приводит к hard lock'ам из-за неправильной сортировки UI элементов в очереди на отрисовку.

И вот вы с лидом (или как лид) думаете как исправить это.
Изменения расползлись по другим веткам, а с момента вашего merge commit'a уже прошло пару дней.

Надумали два путя:
🔹 Удалить фикс всех веток.
Можно сделать как через rebase всех изменений после ваших изменений, а потом force push'ем обновить все ветки.
Можно ручками сделать cherry-pick, а потом force push'ем обновить все ветки.
🔹Сделать revert merge коммита.

Проблема с первым:
🔸Придется блокировать работу во всех ветках на время отката.
🔸Во время rebase могут возникнуть конфликты из-за которых можно накуролесить на --выходные и ++пара бессонных ночей.

Со вторым проблема в том, что ХЗ как сделать revert целого merge'а.
И ответ совсем не очевидный:
git revert -m 2 или 1 <merge_commit_hash>

С revert понятно, а что за магия с 2 или 1?

Приготовьтесь, инфу про git оч сложно запаковывать компактно 😅

git — это направленный ацикличный граф, ноды которого всегда хранят в себе hash родителя(-ей).
Т.е. каждый git commit -m "the best changes" создает новую ноду в которую записывает hash parent коммита (hash коммита предшествующий текущему) и hash object-tree.

Для простоты понимания git — это два независимых LinkedList'а один - для изменений (object-tree) второй - для коммитов (commit-tree).
Только LinkedList'ы однонаправленные (нету Next) и могут иметь несколько нод (Node<T>[] Previous).

Это значит:
🔸 Все коммиты в ветке однонаправленно связаны с самым первым Initial commit.
Т.е. из любого коммита в ветке можно дойти до самого начала графа.
🔸 Каждый коммит, без указания parent'а, как нода из LinkedList'а, Previous которой равен null.
Угадайте как их можно удалить? 🙃
🔸 Эта структура отлично подходит для добавления/изменения/удаления.
С поиском сложнее, но благодаря сортировке префиксов по алфавиту (см. папку objects), используется бинарный поиск.

С устройством разобрались. Дальше порядок работы merge:
1️⃣ Находим общий коммит.
Просто идем по графу, пока parent'ы не совпадут.
2️⃣ Ищем diff от общего коммита до последних коммитов в двух ветках.
3️⃣ Полученный diff пишем в merge-commit.
4️⃣ В parent у merge-commit'a прописываем последниE коммитЫ из двух веток.
Т.е. merge-commit, в отличии от обычного имеет 2 parent'а.

Это фактически значит:
🔻git merge не меняет родителей у существующих коммитов (в отличие от rebase), а создает новый, с ссылками на 2 последних коммита в ветках.

А revert-commit может иметь лишь один parent.

Значит, чтобы сделать все правильно, нужно указать изменения какого именного из parent'ов мы хотим revert'нуть.
Или по другому: diff какой из ветки мы должны revert'нуть

За это как раз и отвечает магическое 1 или 2 — номер parent'а, изменения которого мы хотим revert'нуть.

Лично у меня случилось 2 озарения:
🔶 Именно merge-commit несет в себе все изменения.
Revert'нули его == revert'нули изменения всех коммитов.
🔶 Все, rebase, cherry-pick есть маленькая merge операция. А не наоборот.
До этого я думал что merge - аналог rebase 🤯

Но помните, вы этим самым, вы делаете revert изменений, не истории.

Ставь 👍 если такая движуха тебе по кайфу!

Источники:
Ответ с SO
Статья раз
Статья два

@UniArchitect #будни

ВАШ ПОСЛЕДНИЙ КУРС ПО АРХИТЕКТУРЕ Ч.2

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

Процесс был долгим и сложным.
Анализируя материал, я постоянно задавался вопросами:
🔹"Какая информация действительно нужна для принятия качественных решений?"
🔹"Что необходимо для целостного усвоения всей информации в курсе?"
🔹"Каких знаний мне самому не хватает?"
🔹"Насколько эта информация важна?"

Так постепенно сформировался список тем, которых не хватает в стандартном информационном пространстве разработчика.
Оставалось лишь переработать и объединить их в единое целое 😊
Ну вроде изян! мем 🤣

Вот немного цифр:
🔸Суммарно в основу курса легла основа примерно из 50 источников
В основном это были научные статьи, книги, видео, профессиональные блоги и документация.
🔸С января 24-го на проработку всего этого ушло более 300 мифических человеко-часов 😬
То есть, каждый месяц уходила полная рабочая неделя на проработку в течение 8 месяцев.
🔸На подачу материала уйдёт в сумме около 40 часов — по 8 часов на каждый из 5 модулей!

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

У меня был план, которого я придерживался:
🔹Проработать, структурировать материал, подготовить конспекты для видео.
🔹Записать и смонтировать видео.
🔹Сделать сайт-лендинг, где была бы собрана вся информация в удобном виде.
🔹Соединить его с платформой для обучения.

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

Поэтому я принял решение, что первый и единственный поток я проведу лично в формате онлайн-лекций!

И я хочу признаться:
Не получится сделать что-то действительно полезное и крутое, варясь только в котле собственных мыслей.
Как и любая игра, курс требует полировки и качественной обратной связи.

Что будет включено:
🔸Доступ к закрытому телеграм-каналу, в котором будут публиковаться все материалы:
Записи, презентации, список источников и, возможно, текстовые конспекты лекций.
🔸Индивидуальный разбор кейсов и ответы на вопросы.
🔸Доступ к курсу на платформе после релиза.
🔸А также главная фишка, киллер-фича:
Персональный доступ к реальному проекту Magic Battle Arena!

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

Для меня это способ вдохнуть вторую жизнь в этот проект, а для вас — отличный пример и источник знаний!
Получается win-win 😎

Переходите по ссылке и смотрите полный план курса со всеми темами!

Спасибо всем большое за активность в предыдущем посте.
Я прислушался к каждому из комментариев и подправил план курса 🫡

Делитесь с коллегами и боссами, уже через пару недель состоится открытие продаж!
Ставь 👍, если уже с нетерпением ждешь этого!

@UniArchitect #моя_история

Комментарии можно оставлять под эти постом 😅

Буду знать что посты в ТГ не поддерживают и кнопки и комменты 😬

ВАШ ПОСЛЕДНИЙ КУРС ПО АРХИТЕКТУРЕ Ч.3

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

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

Чтобы этого достичь, в курсе будет большой теоретический модуль, в котором будет:
🔸Теория по инженерной разработке
🔸Разбор имеющихся архитектурных подходов
🔸 Анализ текущих метрик качества кода и способы их измерения
Этим мы заложим основу, которая будет всегда актуальна!

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

Именно это мы будет обсуждать в 3ем модуле: Подробный план курса
Цель которого — найти каждый элемент, который требует принятия архитектурного решения.

🔻И каждый проект это море непринятых кем-то решений!

Иногда мы не знаем, где и как нужно принимать их, а также как правильно фиксировать и добиваться их выполнения.

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

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

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

По кнопке ниже, вы сможете прямо сейчас открыть бот и скачать памятку с рекомендациями 🫡

Ставь 👍 если тебе заходит подобного рода контент!

@UniArchitect #моя_история

АНОНС СТРИМА

Завтра в Воскресенье в 15:00 МСК проведу стрим на тему "Процесс принятия решений".

На нем я расскажу основы того, как принимаются решения человеком.

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

Это будет самое начало, основа на которую будет опираться весь дальнейший материал!
Нулевая лекция курса из которой можно будет понять в каком виде и формате будут проходить все занятия 🫡

Ставь себе уведомление о начале трансляции:
📎https://youtube.com/live/zSf2rvH9cWw

Завтра в 15:00 МСК встречаемся на стриме 💪

@UniArchitect

ВАШ ПОСЛЕДНИЙ КУРС ПО АРХИТЕКТУРЕ | СТАРТ ПРОДАЖ

Закончился стрим, на котором мы разобрали научную статью "Когнитивный процесс принятия решений".

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

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

🔻Во время стрима состоялся ОФИЦИАЛЬНЫЙ СТАРТ ПРОДАЖ.

Всю информацию о курсе, его целях и особенностях вы сможете подробно прочитать в статьях:
🔸 ВАШ ПОСЛЕДНИЙ КУРС ПО АРХИТЕКТУРЕ Ч.1
🔸 ВАШ ПОСЛЕДНИЙ КУРС ПО АРХИТЕКТУРЕ Ч.2
🔸 ВАШ ПОСЛЕДНИЙ КУРС ПО АРХИТЕКТУРЕ Ч.3

Или на сайте, где есть ответы на часто задаваемые вопросы:
https://uniarchitect.notion.site/

📞 Хочешь записаться прямо сейчас, пиши мне: @vangogih

Кол-во мест ограниченно!
Продажи заканчиваются уже 6 Октября.

Поспеши, пока есть места!
До встречи на курсе 👋

@UniArchitect