Лига программистов

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

Существует множество различных способов ветвления, которые можно использовать при работе с Git. В этой статье мы рассмотрим три наиболее распространенных способа ветвления: Git Flow, GitHub Flow и Trunk Based Development.

Git Flow и GitHub Flow являются наиболее популярными ветвящимися стратегиями в коммерческой разработке. Trunk Based Development является несколько более рискованным подходом, поскольку он не предусматривает постоянных веток. Рассмотрим их подробнее:

Git Flow

Git Flow - это методология ведения разработки с использованием системы контроля версий Git. Она была разработана Винсентом Дриессеном и опубликована в 2010 году.

Git Flow предлагает структуру ветвления репозитория Git, которая позволяет эффективно управлять процессом разработки, отделяя стабильные версии от версий, находящихся в разработке. Методология основана на использовании двух основных веток: master и develop.

Ветка master содержит только стабильные версии продукта, которые готовы к выпуску. Ветка develop используется для разработки новых функций и исправления ошибок. Кроме того, Git Flow предлагает использовать дополнительные ветки для различных типов задач, таких как feature - для разработки новых функций, release - для подготовки к выпуску новой версии, hotfix - для исправления критических ошибок в текущей версии, и т.д.

Git Flow также определяет процедуры работы с каждой из веток, например, процедуру слияния ветки feature в develop или процедуру создания новой версии из ветки release.

GitHub Flow

GitHub Flow - это методология ведения разработки с использованием системы контроля версий Git и платформы GitHub.

GitHub Flow предлагает использовать только одну основную ветку - master. Все изменения в коде вносятся через создание новых веток, которые называются feature-ветками. Каждая feature-ветка создается для решения конкретной задачи или добавления новой функции. После завершения работы над задачей в feature-ветке происходит запрос на слияние, pull request, в основную ветку master.

GitHub Flow также предлагает использовать дополнительные инструменты GitHub, такие как Issues и Projects, для управления задачами и проектами.

Эта стратегия ветвления ориентирована на непрерывную интеграцию и доставку (CI/CD), что позволяет быстрее и безопаснее выпускать новые версии продукта.

В целом, GitHub Flow является более простой и гибкой методологией, чем Git Flow, и может быть особенно полезной для небольших команд или проектов.

Trunk Based Development

Trunk Based Development (TBD) - это методология разработки программного обеспечения, которая предлагает использовать только одну основную ветку, trunk, для разработки и интеграции всех изменений в коде. Это означает, что все разработчики работают непосредственно в trunk и делают коммиты прямо в эту ветку.

Для крупных проектов предлагается использовать Scaled Trunk Based Development. Главным отличием является то, что коммиты делаются не напрямую в trunk, для этого используются короткоживущие feature-ветки.

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

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

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

Преимущества Trunk Based Development:

1. Ускорение процесса разработки и интеграции изменений в коде.

2. Быстрая реакция на изменения требований заказчика или рынка.

3. Высокое качество кода благодаря использованию автоматизированных тестов и непрерывной интеграции.

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

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

6. Уменьшение рисков и снижение влияния изменений на работу приложения.

7. Простота и легкость в использовании для малых и средних проектов.

Хотя Trunk Based Development может быть эффективным методом для управления процессом разработки, он также имеет свои недостатки:

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

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

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

1. Кроме того, Trunk Based Development не позволяет экспериментировать с новой функциональностью в отдельных ветках, потому что это может оказать негативное влияние на основную ветку и другие компоненты. Для решения этой проблемы можно использовать фича-флаги, чтобы временно включить или отключить опасные или еще не полностью разработанные функции, и избежать возможных проблем в основной ветке.

Что такое фича-флаг и как с ним работать?

Если сложно, то фича-флаги (feature flags, feature toggles) — это инструмент разработки, который включает и выключает выбранные фичи в рантайме без развертывания нового кода.

Если просто, то это if в коде.

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

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

Инструменты для работы с фича-флагами

Существует много комплексных инструментов для работы с фича-флагами, которые поддерживают флаги по определенным пользователям, ролям, процентному соотношению или сложные флаги, где значение не просто true или false. Вот несколько таких инструментов:

• DevCycle

• Flagsmith

• Unleash

Если нужно что-то попроще, или хочется лишь протестировать подход, то подойдут следующие способы:

• Старые добрые env-переменные

• Простой, как палка, json-файл

• Свой сервис с простой API

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

Но мы уже находимся в процессе перехода на Flagsmith, так что в скором времени работа с фича-флагами станет более удобной и быстрой.

Итак, теперь о нашем опыте

Что у нас было раньше?

Раньше на проекте у нас был Git Flow без релизной ветки, то есть ветка master использовалась в качестве релизной, а весь свежий код находился в ветке dev. Под каждую задачу заводилась своя фича-ветка, для тестирования она сливалась в ветку dev, затем ждала своего часа до попадания в master. Зачастую, дев сильно отличался от мастера своим набором фича-веток, и из-за этого возникало много конфликтов при сборке релиза.

Почему мы решили измениться?

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

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

Соответственно, все эти проблемы выливались в финансовые потери, ведь время - деньги.

Подготовка и переходный этап, инструкция:

1. Мержим все что есть в одну ветку

2. Делаем резервную копию, на случай, если что-то пойдет не так

3. Настраиваем репозиторий: в нашем случае это squash вместо merge commit, сливаем только через pull-реквест, выставляем обязательных ревьюеров

4. Проводим инструктаж для разработчиков

5. Кодим

Отзывы пользователей:

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

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

Первое время приходилось напоминать разработчикам, что размер пулл-реквестов должен быть небольшим, а ревью нужно проводить гораздо чаще, чем раньше. Например, при подходе Git Flow, мы делали ревью целой задачи, разработка которой могла занимать от одного до нескольких дней, в зависимости от ее размера. Сейчас же ревью проводится постоянно в течение дня, среднее количество пулл-реквестов в день - 10-15 штук.

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

Автор статьи: Иван, frontend-разработчик DexSys.

!(4) и что-то новенькое: hh.ru, на котором размещаются резюме, начал проверять точность информации и связываться с работодателями.

Поэтому поговорим о том, как можно привлечь внимание к себе, чтобы потом не уволили, как в этом случае:

(1) Начинать искать как можно раньше (когда изучена уже какая-то база), потому что то, что дают на курсах не всегда равно требованиям компаний. Чем больше смотрите вакансии и общаетесь, тем лучше понимаете, что нужно рынку.

(2) Использовать нетворкинг - знакомиться с людьми, которые работают в тех компаниях, куда вы хотите. Даже просто написать и попросить зарефералить. Теория с рукопожатиями тоже работает (у меня так много клиентов и знакомых нашли работу)

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

(3) Резюме должно быть продумано до мелочей, из самого базового:

➡️ название должности должно соответствовать названиям вакансий, т.е не "специалист", а максимально конкретно;

➡️на первом месте должен быть опыт по той вакансии, на которую вы хотите, даже если это учебный опыт;

➡️ расписать подробно навыки, которые вы получили на обучении, лучше сразу с примерами из практики.

(4) Брать из предыдущего опыта все навыки, которые могут быть полезны. Смена направления — это не начинать с нуля, всегда есть переносимые навыки. Например, опыт ведения коммуникации и работа в команде, который есть у всех, и другие soft skills. Успех поиска 50/50 зависит от hard и soft skills.

(5) Использовать сопроводительные письма и писать вдумчивые отклики на позиции (спам-рассылка скорее всего не даст результата). А вот резюме + нормальное сопроводительное можно отправлять не только на hh, но и напрямую в компании, даже если вакансии нет, вас могут добавить в базу и написать позже.

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

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

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

На прошлом стриме затупил ужасно, аж вспоминать стыдно, всё из-за того, что слишком привык к IDE и забыл про базовые механики Python, решил провести работу над ошибками так сказать)

В этом ролике расскажу как Python ищет модули, что такое вообще модуль и зачем нужны sys.path и PYTHONPATH.

Анонсы стримов и новости моего канала: https://t.me/davaite_pro_it

Признаюсь, что был сильно удивлен тому факту, что буквально через пару дней на сайт полезли боты. Нет, я был готов к тому, что придут всякие поисковики, но вот они как раз и не пришли сразу. А налетели всякие сканеры, накрутчики и прочая мерзость. Через неделю доля паразитного трафика была примерно под 98%. Пришлось заниматься не свойственной для себя работой – «сисдаминством». Поставил и настроил fail2ban, прикрутил к нему несколько фильтров, допилил движок проекта под перманентные баны всех, кто запрашивает страницы, которых у меня нет и никогда не будет, но которые используются для взлома или аутентификации на сайте.
В целом, много кого победил, но искоренить зло полностью не получится. Есть море упертых ботов, которые лезут через прокси и пытаются что-то сделать.

Разочаровал Яндекс, который совсем не борется или хотя бы фильтрует роботов, которые работают на понижение поведенческих факторов. В Метрике куча левака, которое можно было бы отсеять. Уходить за Cloudflare не хочется. Тоже надо думать, что с этим делать (или не делать).

Пережил многодневную «атаку» со стороны какого-то левого скрипта, размещенного на Амазоновских серверах. Почему я был ему интересен до сих пор не понимаю. Паразит каждую минуту выкачивал весь сайт с разных ip или долбил его разными запросами. Это на DDOS не похоже, сервер нагрузку держал без проблем, но к чему была такая активность – не понял. Написал саппорту AWS, приложил логи, но там сказали, что ничего криминального не видят. На второй день снова им написал, что скрипт работает по расписанию, что выкачивает весь сайт и все это не нормально. Ответили вопросом, о том, что я хочу от них услышать? Попросил их проверить, что это за ерунда такая и вообще надо бы на кол посадить того, кто так делает. Обещали подумать и разобраться. Я же задолбался смотреть логи с IP от AWS и забанил все их сетки, которые нашел. Через несколько дней трафик от AWS исчез, а саппорт отписался, что поговорил со своим клиентом. На этом все закончилось.

Идем далее, от нытья к реальным проблемам. Одна из них – нет полной автоматизации по поиску и размещению вакансий. На размещение/модераторство у меня уходит не более 30 минут в день. Тем не менее, я думаю над тем, чтобы тратить на это не более 5 минут в день. Добиться не просто, так как часто цепляю реально не интересные вакансии, в которых нет описания того, что будет делать кандидат или нет вообще информации о работодателе/проекте. Бывают дни, когда вообще нет ничего интересного и это проблема, которую я решил, но пока в ручном режиме и способа автоматизации пока не вижу.

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

Отсюда получаем еще одну задачу: надо раскрутиться! Банальный совет, который лежит на поверхности и который так же банально требует денег. Я делал разные прикидки по бюджету, но в согласие с самим собой пока не пришел. Впереди 2-3 месяца стагнации на рынке труда из-за праздников. Так что пока активно в рекламу вкладываться не хочу. К тому же, я не маркетолог и слить первый бюджет это «как два пальца об асфальт». Много чего уже прочитал, посмотрел Ютуб (а где же еще учиться?) и пока раздираем сомнениями. У кого-то есть идеи на этот счет? Только условия как всегда самые лучшие: денег нет, а результат нужен =)

Ошибки

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

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

Далее напишу важную, как мне кажется, вещь. Она тоже на поверхности и описана во многих книгах в том или ином виде. Я ее озвучу так, как это получилось со мной. И я считаю, что ошибка мне сейчас обходится дороже всего.
Напомню, что проект мы хотели сделать вчетвером: менеджер и три программиста (фронт и два быка бэка). Менеджер не только принес идею, но еще имел знания по раскрутке проектов, их продвижении. Да и язык у него подвешен правильно. Если надо, то мог уговорить сделать что-то нужное, а может и про инвестиции что-то в голове имел, мог что-то придумать и на этот счет. Фронт мог колдовать не только с кодом, но и с SEO. Ну, а остальные два мушкетера могли и с основным кодом шаманить, и немного в админство поиграть. Что в итоге: проект сделал один человек, который не может сразу заменить всех четверых. Я, конечно, мудак молодец, что сделал проект в одиночку. А как теперь его тянуть одному? Осознание этого приносит понимание того, что проект будет долгим. Просто потому, что ты один впахиваешь за четверых. Поиграть в Д'артаньяна, конечно, получилось. Но без команды все куда сложнее. И моя ошибка в том, что не поговорил хотя бы еще с одним из членом нашей могучей кучки и не предложил ему присоединиться, когда заканчивал проект. Так что вывод: если хотите сделать проект, то не старайтесь все делать в одиночку. В книжках пишут про то, что должно быть минимум 3 человека в команде с разными компетенциями и я с этим сейчас (потирая шишку на лбу) полностью согласен. Да, я делал проект чтобы доказать одно. Но по факту шагнул немного дальше и теперь имею все шансы заработать «орден сутулого».
А знаете, что еще плохо в работе одного человека? Тебе не с кем обсудить идею! Второе или третье мнение могут как-то трансформировать идею или вовсе ее отбросить. Иначе ты что-то придумываешь себе, веришь в это, убеждаешь себя в этом, тратишь силы на реализацию, а по факту это все никому не нужно. Некому тебя оставить, одернуть или наоборот - предложить что-то такое, о чем ты сам не думаешь.

Так же сейчас задаюсь вопросом про окупаемость проекта. Раньше думал, что надо просто сделать сайт. Теперь же хочется добиться самоокупаемости. Звучит как очередной вызов, получение некой ачивки. Это не очень больше деньги, так как основные траты — это оплата хостинга. Свою работу пока не считаю. Пожалуй, размещение рекламы спасло бы ситуацию, но трафика не хватает, чтобы получить прописку на приличной площадке для контекстной рекламы. А продавать всякие «казино» совсем не хочется.

Позитив

То, что есть позитив – это основное, что позволяет не бросить это все в корзину.

Главное - проект работает. И даже есть свои достижения. Например, аудитория телеграм-канала выросла в 3 раза! Согласитесь, звучит солидно. Есть только одно маленькое «но»: (Гусары! Не ржать!) рост составил с двух человек до шести =) Прямо так и вижу слайд какой-нибудь мощной презентации с графиком о трех кратном росте и маленькой подписью внизу о реальных цифрах. Все как в рекламных проспектах.

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

Из последних крупных обновлений в этом году – раздел с тестами по HTML, CSS, JavaScript и фреймворкам. Еще нужно поработать над несколькими вопросами, возможно, что-то добавить или заменить. Но в целом считаю, что раздел получился. Вопросов достаточно, чтобы они не повторялись, а ответы не идут по порядку. Так что можно проходить тест несколько раз подряд. База вопросов может без проблем дополняться или изменяться. У вопросов есть уровень сложности, но я пока это выключил. Надо над сложными вопросами подольше поработать, чтобы они больше соответствовали уровню знаний сильного кандидата.
Из минусов, пожалуй, то, что не показываю правильных ответов. Решил сейчас этого не делать. Бонусом добавил две мульки, которые не видел у других: во-первых, я считаю время, которое потратил человек на тест, а во-вторых, если тестируемый уходит с активной вкладки браузера, то я это фиксирую и в конце теста выдаю ему сообщение. Это все мелочи, но лучше с ними, чем без них.

От проекта получил отклик, который вообще не предполагал. Дело в том, что с текущим местом работы прощаюсь. Это никак не связано с описываемым сайтом. Просто пришло время двигаться дальше (и глубже, ага). И вот один из коллег узнал о моих планах и посоветовал меня знакомым, которые ищут разработчика. Договорились просто устроить разговор между технарями (мной и их тимлидом), а если все срастется, то уже еще раз встретится и сделать все, как полагается. В подробности разговора вдаваться не буду, тут ничего интересного кроме того, что спросили (а кого из нас не спрашивали), что ты делал ранее и можешь ли ты показать свой код. Не будь у меня этой джобборды, я бы показать ничего не мог. Просто потому, что последние годы работы — это все то, что не видят простые люди (т.е. внутренние разработки компании). А код так вообще под всякими NDA и за закрытыми Git’ами живет. Так что показал то, что сделал. Дал доступ к своему гиту, показал код. Тимлид по нему побегал, задавал вопросы по типу «почему здесь так, а не иначе?». После просмотра проекта даже других вопросов не было. Тем более, что ответы мои были не только с позиции разработчика, но и менеджера, сисадмина. Возможно, что ничего в этом такого нет. И обычный фулл-стак разраб легко ответит на все вопросы и по фронту, и по бэку. Но все же мне хочется верить, что мои знания не так безнадежны, как я думал о них ранее. Это интервью несколько подняло (в очередной раз) мою самооценку. В любом случае, очень приятно рассказывать о том, что ты сделал сам и это оценивают те, кто тебя слушают. Жаль только мы по зарплате не договорились: предложили меньше, чем я зарабатываю сейчас. Рынок уже как-то остывает к большим з/п программистам, если смотреть вакансии на сайтах.

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

Хочу сказать огромное спасибо всем пикабушникам, которые перешли по ссылке на сайт из прошлого поста (вас было 64 человека), и кто написал комментарии с советами. Первые показали мне ошибки в навигации сайта и прочее, о чем я писал выше. Вторые дали дельные советы и я к ним прислушался. Мерси вам всем от (так по тексту получилось) Д’артаньяна и его проекта!

P.S. мой единственный (первый) подписчик, кто бы ты ни был, тебе отдельная благодарность просто за то, что ты есть =)

Что уже умеет сервис? Умеет следить за тремя сайтами пользователя с периодичностью в 1 минуту, оповещать, если сайт отдаёт отличный от 2хх код состояния, а также измеряет среднее время отклика, если зайти в список сайтов. Это всё бесплатно, без рекламы и смс.

Пару слов про название. Назвали сервис Upall, в том смысле, что по-русски "упал", а на английском значение ровно противоположное. Такая вот игра слов.

Для программистов: приложение написано на Kotlin. Да, мы в курсе, что на питоне проще, но у команды экспертиза в JVM, поэтому писали, на чём умели.

В общем, приглашаю попробовать сервис. Бот доступен здесь.

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

PS Моё - потому что сам принимаю участие.
PPS Пикабушник @devmarkru пришел в комменты - один из авторов

В общем, так получилось и со мной после того, как я открыл гайд по подготовке к интервью одной хабровчанки (жители Хабаровска, это не про вас написано), и узнал, что, по ее мнению, я знаю где-то 20% от требуемого уровня. Там и дискретная математика, и теория вероятности, и master theorem, и основы криптографии, и битовые манипуляции - и это все только база. В общем, я было перенес сроки еще на пару лет вперед, но один умный человек, который уже давно в этом самом FAANG, меня успокоил и посоветовал сосредочиться на основах. Чем я и решил заняться.

Так что сейчас я просто начал прорешивать по 4 задачки из топика Amazon в день. Когда закончу с ним - начну Meta. Это две компании, в которые у меня потенциально есть рефералы.

Плюс начал книжку Alex Xu по системному дизайну. Для опытных людей, наверное, она довольно примитивная, но для меня, как способ "вкатиться в тему" - прям must have, как оказалось. Минимум воды, максимум информации, люблю такое.

Ну и да, я начинаю моки по алго части. It's time. Страшновато, конечно. Так что пожелайте мне удачи.