Всем привет!
Возвращаюсь в канал и начну с топовой истории)
Вчера к нам на собеседование пришёл кандидат, который решил воспользоваться Chat GPT 🤣
Пруфов нет, но все признаки на лицо

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

После всех вопросов чел зависал секунд на 5-10, у него подёргивалось плечо, делал уточнения "правильно ли я понял, что вы спрашиваете ...."
И начинал отвечать в стиле "... обладает характеристиками и используется для предоставления ...."
Потом я чуть не упала, когда мы попросили перечислить сущности k8s, и он сказал - под, репликационные наборы (это типа ReplicaSet) 🤪
Затем мы решили перейти к секции с кодом, кандидат перепутал = и ==, не знал что такое юникод, запутался в ООП.

Я читала о том, что на некоторых курсах начинающих разработчиков учат врать в резюме, но сама столкнулась впервые. Шок-контент 😨

Всем привет!

Коллега посоветовал классную книгу, «Фундаментальный подход к программной архитектуре» (обложку покажу в каментах), в ней описаны различные подходы к проектированию архитектуры, паттерны, антипаттерны и приёмы, виды архитектуры и др.
Одна из глав книги посвящена такому понятию как записи архитектурных решений (Architecture Decision Record, ADR). Это созвучно с тем, что мы сейчас реализуем у себя в команде разработки, поэтому очень хочу рассказать)

Architecture Decision Record - это текстовый файл, который создаётся для описания конкретного архитектурного решения. Мы у себя используем .md файлы и храним их в Git. Есть и другие инструменты и форматы, например, страница в вики вашей компании.
Файл должен быть лаконичным, и содержать разделы, о которых я расскажу ниже.

1️⃣ Название - короткое описание архитектурного решения, должно быть информативным и понятным, чтобы быстро ориентироваться, о чём эта запись
2️⃣ Статуc ADR - на какой стадии находится данное арх. решение: принято, или ещё обсуждается (Request For Comments, RFC), а может заменено новым ADR
3️⃣ Контекст - ситуация, которая привела к созданию ADR и принятию решения
4️⃣ Решение - сама суть архитектурного решения и его полное обоснование. Важно уделить особое внимание именно обоснованию решения, ответить на вопрос «почему». Этот момент является ключевым и самым полезным (имхо) в документировании архитектуры
5️⃣ Последствия - описание того, что влечёт за собой принятое архитектурное решение. Какие плюсы и минусы у него есть, их анализ
6️⃣⭐️ Альтернативы - опциональный раздел, в котором сосредоточены альтернативные решения указанной проблемы, и причины, по которым эти решения не были приняты командой
7️⃣ ⭐️ Комплаенс - в книге рекомендуется включать этот раздел в свои ADR. Это описание, каким образом контролировать соблюдение требований данного арх. решения, должно ли это контролироваться вручную или можно автоматизировать. У нас пока такого раздела нет
8️⃣⭐️ Примечания - также опциональный раздел для указания автора, дат утверждения и замены, лиц, участвующих в принятии и утверждении данного решнеия и т. д.
9️⃣ ❓❓❓
🔟 Вы великолепны 🤪😂

Вы спросите меня, зачем всё это нужно? И я вам отвечу)))

🌟 Это эффективный способ документировать архитектуру - всё в одном месте, можно наблюдать инкремент, описаны альтарнативы, + и -
🌟 Не приходится проводить повторные R&D, потому что результаты предыдущих архитектурных дилемм записаны, оформлены, подведены итоги
🌟 Чуть полегче онбордить новых разработчиков/внедрять иннерсорс, когда приходят с «а почему», можно прислать ссылку на «а потому» и вопрос исчерпан (но естественно пересмотр архитектуры и принятых решений должен быть)
🌟 Можно унифицировать подход к архитектуре микросервисов и тем самым снизить эксплуатационные издержки на поддержку

Приземлю на конкретику. Если вы приходите в сервисы и не понимаете

🟢 почему условный Вася воткнул тут кафку, а не обошёлся рестом
🟣 почему решили использовать gRPC, а не десериализовать json’ы до талого))
🔵 почему используется именно эта библиотека для генерации PDF
🟡 зачем тут Camunda прости господи)))
🟢 почему эту интеграцию реализовали из г… теми ресурсами, которые были доступны на тот момент 🥲
🟣 почему все сервисы развёрнуты в k8s, а один стоит на виндовой тачке в другом контуре

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

Расскажите, знаете про такой инструмент? Практикуете?

Кто на оффлайне? На какие доклады пойдёте?)
🤓🤓🤓

@Cacheable. Part 1

Недавно на работе решила попробовать использовать спринговый @Cacheable с Redis'ом, оказалось настроить очень легко и всё сразу работает)
Оставлю здесь заметку 📎

1️⃣ Сначала подключаем две зависимости

implementation("org.springframework.boot:spring-boot-starter-cache")
implementation("org.springframework.boot:spring-boot-starter-data-redis")

2️⃣ Потом))) на метод, результаты которого нужно закешировать вешаем собственно анноташку @Cacheable(value = ["название кеша"])

3️⃣ Создаём класс конфигурации (@Configuration), вешаем на него аннотацию @EnableCaching

4️⃣ В конфигурации создаём бин RedisCacheManager (код лучше смотреть с компа)

@Bean
fun redisCacheManager(
    connectionFactory: RedisConnectionFactory,
    redisConfigurationProperties: RedisConfigurationProperties
): RedisCacheManager {

    val cacheConfig = defaultCacheConfig()
        .disableCachingNullValues()
        .entryTtl(redisConfigurationProperties.expireTime)
        .prefixCacheNameWith(redisConfigurationProperties.keyPrefix)

    return RedisCacheManager.builder(connectionFactory)
        .cacheDefaults(cacheConfig)
        // если не указать здесь кеш, то не будут собираться метрики
        .withCacheConfiguration("название кеша", cacheConfig)
        .enableStatistics()
        .build()
}

🌟 И вуаля! Результат метода кешируется в Redis. Ключом служит входной параметр функции, на которую повесили анноташку

❓ Почему я не использовала in-memory кеши, которые были бы внутри приложения?

🟢 кеш планируется достаточно объёмный, не хочется тратить ресурсы кластера куба, когда есть выделенный redis
🔵 в случае рестарта приложения, я не потеряю накопленный кеш
🟡 мне нравится как легко в редисе настраивается retention

🟡 при локальном in-memory кеше, если будет несколько реплик сервиса, локальный кеш будет на каждой реплике, возможно будут дубликаты, а это лишняя трата памяти
🟣 уменьшится hit rate, потому что второй запрос может прийти не на ту реплику

Во второй части напишу как я использовала @Cacheable с локальным кешом, cheers 🌟

Всем привет!
У моего друга Жени, junior дата инженера в Сбере, вышло интервью.
В нём он рассказывает как вкатился в IT 🤓
🟣как выбрал профессию дата инженера
🟡как искал свою первую работку, проходил собесы и всё такое 😉
🟢с какими инструментами работает сейчас и зачем язык С дата инженеру

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

Ещё у Жени есть канал, где он пишет про будни дата инженера, постит чаще меня 🤪

кто здесь? ❣️