Почему все так хейтят Сбер последнее время? В некоторых каналах заметил тенденцию, что HR к работникам Сбера относятся с таким же пренебрежением, как Яндекс к ребятам, которые долго сидели на php.

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

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

На этапах системного дизайна любят задавать вопрос: "Что такое архитектура?" Вопрос интересный и сразу показывает, насколько кандидат широко мыслит при ответе.

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

База такая: архитектура — это инструмент, который позволяет быстрее доносить ценность как для пользователя, так и для заказчика. Хорошая архитектура дешевле и быстрее доносит ценность, плохая — медленнее и дороже.
Из этой базы исходит то, что архитектура должна решать следующие задачи:

• 💰 Сохраняет стоимость внедрения фичей. Бизнесу важно, чтобы стоимость внедрения новых фичей, которые по сложности не отличаются от предыдущих, не росла в цене. Если в начале проекта стоимость внедрения фичи X, а через полгода 2X — это проёб архитектуры, который реально может сильно ударить.

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

• 🧪 Тестирование. Это может проявляться на уровне кода, когда вы забили на DI, и нельзя никак подменить зависимость для тестов, и никак нельзя протестировать отдельную фичу, не задев ничего другого. Также может проявляться на уровне всей системы, когда у вас нет возможности поменять конфиги для QA контура, и тестировать можно исключительно на проде — это, кстати, проблема как бэка, так и фронта.

• 🚀 Развёртывание. Не актуальный пункт для мобилок, но очень важный для бэка. Архитектура должна помогать в поднятии новой версии приложения. Если у вас приложение спроектировано так, что может работать только один инстанс и при этом много пользователей, то у вас проблемы. Ведь про zero downtime можно забыть.

• 🔄 Деградация. Хорошая архитектура должна отвечать на вопрос: "А что будет, если у нас отъебнёт база?" или, если мы говорим про мобилку: "Что будет, если инет пропадёт?"

• 👁 Observability. Это уже больше про SRE, однако каждому важно понимать, что архитектура должна давать возможность трекать состояние каждого элемента системы, чтобы быстро понимать, где именно проблема.

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

Наконец-то опубликовали мою статью про robolectric, немного вернулся к темам android.

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

Благо пока канал мой не трогают. Короче вот статья, старался писать не душно https://habr.com/ru/companies/tbank/articles/902180/

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

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

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

Работает следующая формула. В начале мы рассчитываем срок, исходя из нашего прошлого, на глазок. Затем мы умножаем это число на π и добавляем две недели. Почему на π, спросите вы? Исходим из того, что мы двигаемся от начала проекта к его концу.

Оптимистичное мышление подсказывает нам, что мы двигаемся по прямой. Однако в реальности, даже в лучшем случае, мы будем двигаться по окружности из-за разного рода проблем. Длина окружности у нас — это 2πr. Нам нужно пройти половину окружности, значит, πr, где r — это срок, который мы насчитали в начале.

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

UPD: меня в комментах ткнули носом что формула: πr/2 - ведь срок у нас это не радиус а диаметр

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

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

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

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

ё

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

Это один из вариантов наивного решения, которое заключается в том, что мы всё кладем в set, и если обнаружили копию, значит есть цикл. Решение рабочее, более простое, но менее эффективное, и на интервью вероятнее всего не примут. Вот почему:

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

Во-вторых, оба решения имеют временную сложность O(n), однако при использовании set вы получаете расход по памяти O(n), тогда как в решении с двумя указателями расходов на дополнительную память нет.

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

Условия задачи: есть связный список, и нужно понять, есть ли в нем цикл. Цикл — это когда у нас последний элемент списка ссылается не на null, а на какой-то из элементов этого самого списка, короче, смотрите картинку.

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

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

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

👉 быстрый указатель упрется в null – цикла нет
👉 они встретятся на каком-то из элементов – цикл есть

Это собственно все... Код решения на python:
class ListNode:
def __init__(self, x, next):
self.val = x
self.next = next

def detect_cycle(head: ListNode) -> bool:
fast = slow = head
circle_detected = False
while fast and fast.next:
slow = slow.next
fast = fast.next.next
if slow == fast:
circle_detected = True
break
return circle_detected
В некоторых случаях могут попросить вернуть ссылку на начало цикла, в этом случае вам нужно будет подвигать ссылку head до нужного места.

Знаете, я тут подумал и кажется осознал:

👉 покрывать все интерфейсами это единственно верное решение, чтобы ваша кодовая база не развалилась.
👉 npm и gradle это лучшие системы сборки, которые существуют на рынке.
👉 снепшоты это отличная замена UI тестам, в целом можно только их использовать!
👉 llm от лукавого и нужно писать весь код самостоятельно
👉 чтобы быть востребованным на рынке важно, чтобы у вас был красивый github

UPD: лучшая тема в IDE – светлая

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

Компания AliExpress Russia, собес на позицию Android-разработчика. Было несколько этапов, насколько помню, три: скрининг, Android-секция и техническая. Скрининг и Android-секцию я слабо помню, видимо, вопросы были максимально банальные в стиле: "расскажите про все основные компоненты". Техническая сессия оказалась алгоритмической.

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

Вторым вопросом был flatten array. Нужно было написать кастомный iterator, который из такого списка [1, 2, 3, [4, [5, 6]]], делает такой [1, 2, 3, 4, 5, 6]. Задача была прикольная, с натяжкой можно представить, где такое можно применить.

Знаете, что было самое забавное в этих собесах? Собес в AliExpress, по ощущениям, был самым сложным по сравнению с другими, а оффер в итоге был самый маленький…

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

Смотрите, есть два основных подхода в архитектуре.

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

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

Недостаток первого подхода в том, что мы плохо предвидим будущее и можем подсунуть абстракцию не туда, куда нужно, а куда нужно — не подсунуть.

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

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

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

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

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

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

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

Что делать после того, как вы получили лычку сеньора?

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

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

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

Абсолютно кайфую от подхода ребят. Занятия тут это не потогонка, а крутой дружеский разговор.
Студент школы — Иван, QA инженер

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

Реклама. Моисеев Кирилл Владимирович. Erid: 2VtzqxAwUMM

Давайте подытожим, что у нас со снепшотами. Соберем все плюсы и минусы:

✅ Плюсы:
👉 Нет эмуляторов – довольно жирный плюс
👉 Легко написать проверку вместо вызова кучи функций в espresso
👉 Позволяет отследить баги SDK

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

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

👉 Поехал текст на кнопке, но сама кнопка работает
👉 Запрос отправляет не на тот endpoint, из-за чего у клиента не работает оплата

Знатоки, внимание вопрос, за какой из этих багов форма вашего стула станет похожа на бутылку?

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

Да, снепшот тесты отлично проверяют внешний вид приложения, а толку то от этого? В тестах важно чтобы не было регресса в логике. Вы тут можете возразить, ведь в таких тестах можно ходить в сеть. Если под капотом снепшотов нет robolecric, вы сходите лесом, а не в сеть. Что если замокать network и проверять на фейковых данных? В этом случае вы проверите как ваше приложение работает в мире феечек с единорогами.

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

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

Итак, снепшот тесты. Тесты когда мы отрисовываем интерфейс, сравниваем его по пикселям с эталоном и падаем, если картинка сильно отличается.

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

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

Что такого вы можете сделать в коде, от чего вас спасут эти тесты? Я просто не понимаю, как можно накосячить в верстке так, чтобы всё сломалось. Compose позволяет даже сложные экраны верстать в полмозга, левой пяткой. В верстке нет сложной логики, которую мы можем сломать изменениями. Или вы падинги рассчитываете по сложной формуле?

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

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

Может, у вас есть истории успеха, где такие тесты реально спасли релиз?

{3/3} Базу прошли, теперь поговорим про kotlin и gradle.

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

Теперь про систему сборки. В обязанности сборщика помимо компиляции кода входит:
👉 Управление зависимостями
👉 Тестирование
👉 Упаковка приложения
👉 Работа с кешами
👉 И еще дохера всего

Нужно ли для этих задач использовать тот же язык, на котором мы пишем код или на котором написан компилятор? Однозначно нельзя ответить на этот вопрос.

Говоря откровенно, когда я садился писать этот пост, мне казалось что я сейчас быстро найду кучу примеров сборщиков, написанных на других языках. Иии оказалось их почти нет, только один Bazel написан на java и может компилировать C++.

Если пройтись по всем 3-м пунктам которые я привел для компилятора вот что получим:
👉 Если мы не можем написать сборщик на том же языке, то нужно ли вообще такой язык использовать?
👉 Если же другой язык перестанут поддерживать, нам придется переписывать систему сборки на другой, а это затраты
👉 Корпоративный аспект в система сборки кстати не работает, почти всегда сборщики делают сторонние компании, тут конечно минус

Давайте на примере. Допустим у нас есть язык Java и система сборки для нее например на C++ . Кого ты хочешь в команду для разработки сборщика? Человека который всю жизнь писал на Java, знает все ее тонкости и проблемы или человека на C++ который всю жизнь решал другие проблемы?

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

Решение команды TypeScript это интересный прецидент: практическая производительность становится важнее вот этих опасений. Если у них все выгорит, то кто знает, возможно мы когда-нибудь получим аналог Gradle на Rust.

{2/3} В мире языков есть такое понятие как самокомпилируемость (self-hosting). Компиляторы «взрослых» языков написаны на них же самих — C компилируется C-компилятором, Java использует компилятор на Java, даже Go изначально был на C, но потом его переписали на Go и т.д.

Почему это так важно?
1️⃣ Это показывает, что язык достаточно мощный и выразительный, чтобы реализовать функционал собственного компилятора. Если же компилятор переписывается на другой язык, многие могут воспринять это как увядание языка.

2️⃣ Компилятор должен быть независим от других технологий. Вот например: компилятор языка X написан на языке Y. Что случится, если язык Y перестанут поддерживать? У компилятора X будут большие проблемы. Ведь язык, на котором написан компилятор, не развивается, а значит никто не улучшает производительность, никто не добавляет новые фичи для ускорения. Так еще попробуй теперь найти разрабов на устаревающем языке.

3️⃣ Корпоративный аспект: TypeScript поддерживает Microsoft, а Go разрабатывает Google. Получается, что Microsoft в некотором смысле становится зависимым от решений Google. По идее было бы в разы меньше рисков если бы они выбрали С#. Что сказать, у команды TypeScript железные яйца.

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

{1/3} TypeScript переписали на Go. Последнее время эта новость пронеслась на волне хайпа. Даже если вы рот топтали TypeScript и Go тут есть кое-что интересное.

Для начала, в чем суть новости. В любом языке есть две части — Транслятор и Рантайм. Трансляторы реализуются в виде компиляторов или интерпретаторов. Чем они отличаются, я надеюсь, вы знаете. Транслятор преобразует текст в команды нужного формата, которые затем исполняет Рантайм. Так вот, TypeScript транслятор теперь реализован на Go вместо JS.

Сделали это с одной целью – ускорить работу компилятора. Тестирование показало, что сборка крупных проектов, типа VS Code с кодовой базой около 1,5 млн строк, с новым компилятором на Go занимает 7,5 секунд против 77,8 секунд ранее. С одной стороны, десятикратное ускорение — весьма неплохо, с другой стороны, компиляция в минуту — это не чтобы big deal. В Gradle у нас столько одна только конфигурация занимает. Другое дело, если бы речь была о сокращении времени с нескольких часов до пары минут.

Самое интересное тут то, как они всё переписали. У команды было 4 претендента на переписывание: C#, Go, Rust и F#. Им хотелось попробовать все 4 варианта. Разумеется, взять и перелопатить такую огромную кодовую базу вручную, да еще и 4 раза, нереально.

Поэтому что они сделали? Они написали автопереводчик с JS языка на каждый из вариантов. Как я понял, из всех вариантов проще всего было перевести на Go. С C# и F# не получилось потому как это чисто объектные и функциональные языки. С Rust не пошло, так как модель памяти в нем запрещает цикличные ссылки, поэтому это имело бы смысл только если на нем бы разрабатывали изначально. С Go не было особых проблем, потому как он ближе всего стоял по подходам, поэтому в результате выбрали его.

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

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

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

👉 Мы убиваем программы, когда добавляем новые фичи, не учитывая вносимой ими дополнительной сложности.
✏️ Согласен, любая новая фича увеличивает когнитивную нагрузку. Сейчас каждая корпорация пытается сделать суперапп, которая на эту нагрузку кладет хер. У меня неделя ушла, чтобы в инсте найти, где мои лайки.

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

👉 Мы разрушаем программы абсурдной цепочкой зависимостей, делая всё раздутым и хрупким.
✏️ Я так понял, это пункт про проблему транзитивных зависимостей. Ну тут охота процитировать того деда из сериала: "Ну почему мы не можем жить без сторонних зависимостей? Да потому что блять не можем..."

👉 Мы разрушаем программы, говоря новым разработчикам: «Не изобретай велосипед!».
✏️ Потому что, изобретая велосипед, в большинстве случаев они внесут кучу уязвимостей, которые уже давно поправлены, или уничтожат перформанс. Нет ничего плохого в велосипедах, но только когда ты уже не начинающий.

👉 Мы разрушаем программы, не заботясь о обратной совместимости API.
✏️ Согласен, это отсутствие инженерной культуры.

👉 Мы разрушаем программы, заставляя переписывать то, что уже работает.
✏️ Кто их заставляет? Покажите мне хоть одного менеджера, который в восторге, когда к нему приносят задачу на рефакторинг?

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

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

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

👉 Мы разрушаем программы, утверждая, что комментарии в коде бесполезны.
✏️ Большинство да, однако в сложных местах это может сэкономить часы. Лучше всего руководствоваться правилом наименьшего удивления.

👉 Мы разрушаем программы, ошибочно принимая разработку за чисто инженерную дисциплину.
✏️ Странный пункт. Что это тогда, наука, писательство?

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

👉 Мы разрушаем программы, стремясь писать код как можно быстрее, а не как можно лучше.
✏️ Бизнесу как-то похуй, к сожалению, с этим приходится мириться.

👉 Мы разрушаем программы, и то, что останется, больше не будет приносить нам радость хакерства.
✏️ Подразумевается, что разработчикам нет никакой радости от работы. Ну совсем сомнительный пункт, не понимаю почему и как это прокомментировать…

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

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

Примерно то же самое произошло с созданием Git. Линус Торвальдс просто хотел решить проблему влития изменений и создал Git под нужды своего проекта. Позже оказалось, что Git на порядок удобнее всех конкурентов. Работая над Linux, Торвальдс создал инструмент, который по распространённости не уступает оригинальному проекту.

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

Система сборки получилась настолько впечатляющей, что когда Uber решили перевести часть своих серверов на архитектуру arm64, они доработали билд-систему Zig и внедрили кросс-компиляцию без необходимости переписывать существующий код.

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

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

Закончим срач, про интерфейсы. Из всех аргументов "за", был только один связанный с практикой. Комент про то, как интерфейсы помогли разработчику перевести свой проект на KMP в краткие сроки.

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

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

👉 Retrofit + OkHttp для сетевого взаимодействия
👉 Room для работы с БД (если оно вообще нужно)
👉 MVI для презентационного слоя (они уже все на базе корутин)
👉 Timber для логирования
👉 Dagger для внедрения зависимостей

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

Для переезда на KMP нам нужно два основных шага: перевести стек для сети и БД на мультиплатформу и вынести за интерфейсы платформенные компоненты (даты, UUID и подобное). Последнее заранее никто не выносит, если только не закладывали перенос заранее, поэтому в любом случае придется делать.

📞 Сеть. Retrofit изначально требует использования интерфейсов, поэтому эта часть уже готова. Мы просто то меняем зависимость на Ktorfit и заменяем OkHttp на Ktor. Возможно потребуется переписать интеракторы, но вы бы в любом случае их переписывали.

💽 БД. Если ее на проекте нет, то вы уже сделали 90% работы. Если же есть, то Room последней версии уже мультиплатформенная. Если же Room не нравится, то придется мигрировать на SQLDelight. Как бы вы не закрывались интерфейсами, у вас все равно будет дофига работы по мигрированию сущностей на другую либу. Все равно менять код Repository, поэтому профит интерфейса не ясен.

💉 DI. Если у вас был Dagger или Hilt или Anvil – вы в заднице. Теперь вам нужно или делать кастомный DI или переходить на Koin. Кстати если шарите, в комментариях подскажите, какие еще DI контейнеры мультиплатформенные?

📜 Логер. Никто никогда не покрывает интерфейсами логер, поэтому мы через замену текста меняем Timber на Napier.

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

Итог: KMP никак не оправдывает избыточное использование интерфейсов, поскольку они здесь второстепенны. Успешный перенос проекта на KMP в первую очередь зависит от актуальности технологического стека. Даже если вы обложитесь интерфейсами по самые уши, но на проекте еще есть RxJava или View, то вы никуда быстро не передите.

🗓 Итак, топ постов за февраль. Решил попробовать делать такие дайджесты, посмотрим как пойдет:

👉 Структурная типизация
👉 Мой проеб с внедрением AI
👉 Фишки с типами, о которых не знают джависты
👉 Джуны тупеют
👉 Версионирование
👉 Что такое кольцевой буфер?

История моего отношения к LLM проходила несколько этапов. В начале я со всеми хихикал над тем, какой код выдает GPT 3.5. Да, можно сгенерить змейку, даже код запускается, но на реальных задачах много галлюцинаций, и получить что-то вменяемое крайне сложно. Затем пришла GPT 4.0, которая уже была значительно круче. Однако с ней также было много проблем — в подавляющем большинстве случаев было проще самому накидать код.

Затем внутри OpenAI начались споры, часть команды ушла и основала отдельную компанию, которую назвали Anthropic. Свою модель они назвали Claude. Уже первая версия модели по комментариям многих разрабов, писала код значительно лучше чем основной конкурент. Claude 3.5 уже делала дельные замечания по коду, круто писала тесты, но в сложных вещах могла затупить. Последний раз я активно пытался её использовать примерно осенью.

На прошлой неделе я всё-таки решил попробовать платную версию Claude 3.7. И это прям впечатляет — за последние полгода модели значительно продвинулись. После пары дней использования я даже начал нервничать. Не в том плане, что нас всех заменят моделями и мы будем сидеть без работы, а в том, что умение работать с такими моделями даёт значительное конкурентное преимущество. Я не скажу, что она меня ускорила в разы, но по ощущениям процентов на 50 точно

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

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

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

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

Хотите прикол? Если в канал ничего не писать, число подписчиков потихоньку растет. А если писать, то кто-то постоянно отписывается. Так что писать невыгодно. Думайте

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

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

Задача такая: вот у нас есть трекер посещений сайта, с двумя методами:
class WebsiteTracker{
fun visit() {}
fun count(): Int {}
}

Метод visit дёргается когда человек заходит на сайт. Метод count должен возвращать количество посещений за последние 5 минут. Для упрощения не нужно париться насчёт многопоточности и считать уникальных посетителей только реализовать эти два метода, причём максимально эффективно. Задача сложнее, чем кажется на первый взгляд, можете попробовать что-то накидать перед тем, как читать дальше.

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

В Kotlin, разумеется, нет такой структуры, однако её очень просто сделать при помощи LinkedHashMap. Фишка этой мапы не только в том, что она сохраняет порядок добавления, а ещё и в том, что у неё есть волшебный метод removeEldestEntry. Переопределив его, можно задать правило, по которому старые элементы будут автоматически вычищаться при добавлении новых.

Поэтому задаём правило, что нужно удалять, если значение ключа отличается от текущего времени более чем на 300 секунд:
val visits = object : LinkedHashMap() {
override fun removeEldestEntry(
eldest: MutableMap.MutableEntry
): Boolean = eldest.key < currentTimeMillis() - 300*1000
}

Всё, что осталось – это реализовать наши методы:
fun visit() {
val timeSlot = (currentTimeMillis() / 1000) * 1000
visits[timeSlot] = (visits[timeSlot] ?: 0) + 1
}

fun count(): Int {
val cutoff = сurrentTimeMillis() - timeWindow
visits.entries.removeIf { it.key < cutoff }
return visits.values.sum()
}

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

Второй вопрос, который может возникнуть: мы же итерируемся по целой коллекции это же не оптимально? У нас гарантированно не более 300 элементов, пробежаться по ним также быстро как ты в свой первый раз.

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

Стоило мне один раз, стать виновником инцидента на проде. Мой скрипт на CI отработал не так, как нужно. И я попал в какой-то кафкианский бюрократический ад. Две задачи, страница на wiki, инцидент в специальной системе которую я впервые вижу. Отчасти я понимаю зачем это нужно, но кто мне запретить поныть?

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

Это же случилось и в прошлым постом. Мой любимый подписчик (без шуток), рассказал свою историю, в стиле "я Д’Артаньян, все пидорасы" о том как он покрывал все интерфейсами, потом пришел заказчик, который попросил перевести все на kmp. Меньше чем за неделю он в соло зарелизил iOS версию с минимальными изменениями. Чем не история успеха?

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

Короче я решил декомпозировать этот комментарий на составные части и высказать что я думаю:

"<6 слоев градл модулей" – не особо понимаю что значит меньше 6 слоев, наверное имеется ввиду дофига слоев? Если ты один разработчик на проекте то, да крутят у виска заслужено, это попахивает каргокультом. Не представляю зачем больше 3 слоев может быть даже на большом проекте? Однако сам таким страдал когда, был зеленым, поэтому 100% понимания.

"на работе всем похер экзоплееры прямо во вьюмодели залетают и view прокидываются на domain слой" – это не про интерфейсы, это уже про инженерную культуру, а точнее про ее отсутствие. Когда я говорю, что не нужно плодить лишние интерфейсы, я не имею в виду, что можно смешивать UI и Domain. Domain может быть только на классах, но при этом максимально изолирован от платформы, я проверял. И я говорю именно про лишние интерфейсы, а не вообще интерфейсы в целом, не нужно перегибать.

"На работе же уже потратили около 600к$ и больше 2к человеко-часов на переписывание, чтобы хотя бы домейн уровень вынести в кмп" – я возможно ничего не понимаю, но если уже такие бюджеты есть на проекте, и все это время была только одна платформа? Реально, KMP выглядит проще чем написать iOS приложение, которое будет работать в разы стабильнее и плавнее?

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

"горячая сборка моего проекта около 5 секунд на обеих платформах. Холодная конфигурация около 20 секунд" – не особо понимаю как связаны интерфейсы и сборка. Если проект небольшой, а он судя по всему небольшой если ты на нем один, то разумеется на нем будет быстрая сборка.

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

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

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

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

Начало туть. Когда какое версионирование использовать?

🗄️ SemVer позволяет грамотно спланировать обновления библиотек в проекте. Ты можешь прикинуть объем работы, исходя из того, какая цифра в версии поменялась. Представим, что мы живем в идеальном мире и у нас не ломают обратную совместимость на минорных релизах. 

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

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

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

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

🧬 Вся суть версий для пользовательского ПО в двух составляющих: понять в какой версии у нас появился баг и маркетинг. Баги можно отслеживать и без SemVer главное понять какая версия идет за какой. С точки зрения маркетинга тоже все довольно неоднозначно. Когда мы говорим про приложения в рекламных акциях никак не указываются точные версии, всем похеру. 

Поэтому я считаю, что для пользовательского ПО лучше всего подходит комбинация Дата +  SemVer, то что использует JetBrains. Мы четко можем отличать версии друг от друга, и у нас навсегда уходят споры о том, а достаточно ли это большое изменение чтобы мажор инкрементить?

Вывод: 
👉  SemVer – для всего прогерского, библиотеки, CLI, какой-то сервисный софт
👉  Дата + SemVer – для пользовательского ПО

☁Офлайн-встречи мобильных разработчиков уже в эти выходные!

😉Привет! На связи Coffee&Code — международное сообщество мобильных разработчиков.

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

🤪Пообщаемся на технические темы, обсудим интересные события из мобильной разработки, разберем вопросы с собеседований и поделимся опытом!

🤖 Android | 📱 Mobile | 🍏 iOS

📍СПИСОК ГОРОДОВ

💃Также мы выкладываем интересные технические/полезные видосики в наш YouTube канал и записываем Подкаст! Ждем тебя на встречах!

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

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

👉 SemVer
👉 С использованием даты
👉 Хеш коммита/номер билда
👉 Гибрид всех что выше

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

SemVer – базовая база для разраба и одна из лучших вещей, которая придумана для версионирования ПО. Суть в трех цифрах: мажор.минор.патч. Мажор мы меняем при изменении публичного API, в котором не гарантируется обратная совместимость. Минор это новые фичи или фикс багов с гарантией обратной совместимости, другими словами не удаляем старое API, а только дополняем или депрекейтим. "С гарантией" это в идеале конечно, по факту часто бывает "мама анархия", поговорите с фронтендерами, они много вам расскажут про это. Ну а патч для багов и хотфикстов –мой любимый.

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

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

Хеш коммита или номер билда – я думаю тут тоже пояснять не нужно. Просто берем хэш коммита в git от которого решили сделать релиз и его используем как версию. Либо просто берем цифру, инкрементим на каждый билд, это и есть наша версия. Само по себе такое версионирование я нигде не видел, в основном применяется вместе с SemVer.

Гибрид. Это комбинация из нескольких типов. Например, как делает Jet Brains они берут SemVer, но за мажор принимают год выпуска. Часто также используется подход когда берут SemVer и добавляют хеш коммита с которого этот релиз поехал.

Когда что использовать? Расскажу в следующем посте.

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

По мне так такого рода аргументы, несусветная глупость. Я пришел в IT в 2018 году, знаете, что тогда мне сказал один из сеньоров? Джуны сейчас уже не те, они не пытаются разобраться, а сразу идут в StackOverflow! Готов поспорить, что в нулевых обвиняли во всем IDE с автодополнением. До нулевых – высокоуровневые языки, собаки сутулые никто Си учить не хочет!

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

Что касаемо того, что джуны не разбираются в проблеме. Так и до бума LLM много кто тупо копировал код из StackOverflow, также не копая вглубь. По моим наблюдениям джуны не стали менее компетентными, они такими всегда и были)

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

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

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

Вот например:

type ParseType = "number" | "boolean" | "string";

function parse(
input: string,
type: ParseType
): number | boolean | string {
switch (type) {
case "number":
return parseFloat(input);
case "boolean":
return input === "true";
case "string":
return input;
default:
throw new Error(`Unknown type: ${type}`);
}
}

typeof parse("42", "number") // number
typeof parse("42", "boolean") // boolean
typeof parse("42", "string")) // string

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

Эта же мощность мне кажется является и недостатком Typescript. В kotlin начинающего разработчика система типов сдерживает, в Typescript же напротив, позволяет слишком многое.

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

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

Мальчик: ждет 14 февраля чтобы сделать подарок своей половинке

Мужчина: ждет 14 февраля чтобы узнать, что будет с ключевой ставкой

Итак, как бы я сейчас делал задачу с классификацией ошибок на МР.

1️⃣ Я бы сразу пошел выбивать ресурсы, чтобы сразу развернуть модель побольше. Большая Llama от Meta на 70B или недавно вышедший deep-seek, прекрасные варианты. Если же компания в которой я работаю, такого не позволяет сделать, договорился бы об отправке логов в Open AI или тот же Deep Seek. В таком случае правда пришлось бы очищать данные, чтобы что-то лишнее не утекло.

2️⃣ Сделал бы другую архитектуру. У нас было сделано так, что мы собираем данные в одной из Job на CI и отправляем в наш сервис. И вот так лучше не делать, лучше не вмешиваться интеграциями внутрь пайплайна. Как нужно было сделать: либо завязаться на вебхуки Gitlab, чтобы он сам нас дергал при падении. Если же вебхуки отключены, раз в условные 10 минут собирать все МРы через Gitlab API и анализировать пачкой по очереди.

3️⃣ Не парился бы с самописным сервисом. Сейчас я бы взял бы какой-нибудь n8n и накидал прототип на нем. Уже после, если бы идея себя оправдала, задумался бы о написании своего сервиса. Развернуть n8n у себя это день если есть готовая инфра, или неделя если ее нужно еще поднимать. Вы примерно сколько бы и потратили на деплой своего сервиса.

И главный проеб! Я не придумал никаких метрик в начале, чтобы понять, а решение вообще стоит того? Сейчас бы я начал со сбора хоть каких-то метрик, хотя бы считать реакции на коментах к МРу.

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

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

На фоне всего этого возникла такая идея. На CI у нас переодически падают пайплайны, и нет никакой статистики по причине падания. Где-то памяти не хватило, где-то тесты упали, где-то компиляция не прошла и еще куча всяких причин. Сам Gitlab ведет себя как уставший уролог, его особо не парит почему у тебя там что-то упало.

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

Почему сразу не пойти в API OpenAI? Ну в крупной компании безопастники могут прописать с вертухи за такое. Задача была интересна исключительно по тому, что мне хотелось руками потрогать LLM. Ресурсов у нас было мало, а мозгов еще меньше, поэтому мы решили взять самую мелкую модель из тех, что есть в open source. На тот момент это была Gemma-2b от гугла.

Разумеется сервис решили делать на Python. Я взял Fast api, чтобы быстро накидать сервис и либу от Hugging face для работы с моделями. С либами все шло довольно быстро. Однако большую часть времени я потратил на косплей админа линукса и на возьню с poetry (npm мира python). Да пока еще не было системы сборки, которая бы меня не расстроила(

Иии эта фигня вообще не взлетела. Я потратил довольно много времени: на разворачивание сервиса, на интеграцию модели, на администирование linux, на подбор адекватного промта, который хотя бы иногда советовал что-то адекватное. В результате я получил только опыт и мудрость суть которой – мелкие модели работают крайне паршиво для таких задач.

Дальше расскажу как бы я делал такую штуку сейчас, набив шишки.

Как вы могли понять по последним постам, у меня большие проблемы с npm, ведь в плане фронтенда я дурачок.

Однако если у вас есть желание увидеть как работает профи фронтенда, почитайте канал «Джун на фронте».

Его автор Юрий, 2 года вкатывался в IT и все же смог. Теперь пилит интеграции для Web3 и пытается в инди-хакинг.

Если вам нравится следить за чужими ошибками и мемами то заглядывайте: @divatoz

Типизация о которой вы не знали

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

Есть два варианта типизации номинальная и структурная.

📜 В номинальной типизации совместимость типов определяется именем. Есть класс A и класс B и есть функция, которая принимает входным параметром класс A. Даже если класс A и класс B полностью совпадают по полям и методам, все равно при попытке вызвать функцию с объектом класса B компилятор пошлет вас лесом.
class A(val name: String)
class B(val name: String)

fun some(named: A){ /* ... */ }

some(A("Igor")) // тут все норм
some(B("Igor")) // тут уже идем лесом
Мы в java и kotlin всегда используем номинальную типизацию, у нас тупо нет выбора. Однако есть и другой вариант.

🩻 В структурной же типизации все намного гибче. Мы можем указать, что в функцию мы хотим объект, у которого есть поле name. И далее мы можем вызывать эту функцию с вообще каким угодно объектом, главное, чтобы у него было нужное поле
type A = { name: string, age: number };
type B = { name: string };

function some(named: { name: string }){ /* ... */ }

const userA: A = { name: "Igor", age: 30 };
const userB: B = { name: "Igor" };

some(userA)
some(userB)
Такой вариант типизации есть в python, typescript и в go на уровне интерфейсов. При этом если ты попытаешься подсунуть объект, который не удовлетворяет условиям, компиляция не пройдет.

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

Из минусов – сложность. Если же в номинальной типизации все однозначно, то при структурной можно уже запутаться где ты там чего передаешь.

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

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

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

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

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

Однако на этом моя эпопея не закончилась. Локально у меня все заработало, я даже смог настроить дебагер, чтобы все проверить. Запушил я это все на CI, и теперь оно сломалось там. Без какой-либо внятной ошибки. Опять то же самое, ошибка есть, но где я не скажу…
Вот такой лог у меня есть:

n8n-editor-ui:build:  ELIFECYCLE  Command failed with exit code 1.
n8n-editor-ui:build: ERROR: command finished with error: command (/builds/sme-tools/n8n/packages/editor-ui) /usr/bin/pnpm run build exited (1)
n8n-editor-ui#build: command (/builds/sme-tools/n8n/packages/editor-ui) /usr/bin/pnpm run build exited (1)
Tasks: 17 successful, 18 total
Cached: 0 cached, 18 total
Time: 4m40.712s
Failed: n8n-editor-ui#build
ERROR run failed: command exited (1)
 ELIFECYCLE  Command failed with exit code 1.

Дамы и господа, ваши догадки, что тут сломалось?

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

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

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

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

Вот на этом моменте вы наверное думаете: философ хуев, нахера мне это нужно в канале про разработку? А я это вот к чему, markdown – это сверх ценная идея!

Подход для разметки документа, который задумывался для упрощения. Подход, который позволяет накидать документ без всяких превью. Все это превратилось в то, что я теперь должен скачать и запустить докер с node.js (привет npm), для проверки, что моя дока нормально отображается!

Обычный markdown слишком просто, давайте затащим docusaurus, в котором есть еще 50 вариантов прикольных элементов. В итоге идешь в доку ожидая только markdown файлы, а там какие-то файлы верстки, и уже даже какой-то реакт компонент. Мы с каждым днем все дальше от бога…

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

📚 Полезные посты:
👉 Как понимать любой DI
👉 Как делать доку
👉 Забытый способ делать double check locking
👉 Путаница с рефлексией в kotlin
👉 Как не профакапится с релизом мобилки
👉 Когда нужно использовать статику вместо DI
👉 Как работают валидаторы моделей в kotlin

🧐 Просто интересные:
👉 Про риски
👉 Почему с технологиями в мобилке меньше проблем
👉 Проблемы логирования
👉 Как делать код ревью
👉 Как получаются хорошие open source решения
👉 Как не бояться собесов

🤡 Похихикать:
👉 Конфиги
👉 Опыт работы с npm
👉 Хихикаем над чистым кодом
👉 Про frostpunk

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

Собеседование в Яндекс

Друзья которые работают в Яндексе страшно возмущены этим видео. Абсолютная чушь и клевета. Ведь на самом деле на обед дают 875 рублей, а не 800

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

Однако базовые алгоритмы обхода графа, как мне кажется стоит знать. Они бывают полезными на практике. Например, построить граф зависимостей на проекте или сделать закрашивание как в 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 же вроде как подходит для поиска кротчайшего пути, но я на практике такую штуку не реализовывал.

Итак, 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. При этом у тебя очень быстро меняются миры, эдакий тик-ток на уровне всей игры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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