Одна из сегодняшних рабочих задач ✅

*Добавить в таблицу базы данных новый атрибут
*Добавить работу с этим аттрибутом в сервисный слой, через вызов SQL запроса в репозитории
*Отредактировать несколько HTTP эндпоинтов, чтобы они принимали/отдавали добавленный параметр

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

Также сегодня я понял, что мне не хватает знаний в SQL, потому что я привык работать с Entity фреймворками, но о них в другой раз

Сегодня во время диалога о грубой силе/интеллекте и идеях/реализациях очень кстати пришёлся один из принципов SOLID, interface segregation или принцип выделения интерфейсов

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

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

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

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

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

Вчера с командой начали переход на Jira с другой системы управления проектами(Kaiten)

Jira предоставляет огромный функционал в области таск-менеджмента, управления командой и рабочим процессом, отслеживания ошибок и интегрируема с кодом через платформы совместной разработки (gitlab, bibucket и тд)

Для нашей команды было важно более строго организовать рабочий процесс по философии Agile (Scrum), для чего-то очень нужны были спринты(определённые сроки, для выполнения определённых задач) и беклог(упорядоченный список задач)

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

Сегодня пол дня писал Open API спецификацию - описание веб-интерфейса на декларативном yaml, независимое от языка реализации (отсылка на недавний пост о интерфейсах)

В спецификации указываются эндпоинты (http-ссылки), схемы передаваемых объектов, безопасности и общая информация о предоставляемом Application Programming Interface(сокр. API)

Такая спецификация может быть контрактом между фронтендом и бекендом в вебе или просто документацией

Приятным бонусом является автогенерация клиента/сервера с помощью Swagger Codegen и возможность экспорта в Postman - утилиту для тестирования веб-интерфейса

Небольшой интерактив, будем развивать самопрезентацию и нетворкинг !

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

⏬ ⏬ ⏬

Сегодня ночью за два часа случайно буквально проглотил небольшую книгу на 100 страниц на английском о тестировании Spring Boot приложений

и могу сказать следующее:
1) знание технического английского в IT невероятно важно (огромное количество ресурсов, документация, сами языки - это буквально английский)
2)фреймворки, все завязано на них(в данном случае junit, mockito,spring test,selenium, testcontainers)

Фреймворк (англ. framework — «каркас») - надстройка над языком, универсальный набор инструментов, обеспечивающий структуру кода и избавляющий от низкоуровневых операций. Это очень экономит время и усилия, позволяя сконцентрироваться на сути

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

Недавно пришлось разбираться с полотном sql запроса с десятком вложенных подзапросов, джоинов и спагетти из ифов, добавляющих непонятные строчки. Запрос причём передавался просто String-ой..

Хотелось бы, чтобы все использовали такие абстракции как Entity Graph, но к сожалению обычно самым простым и производительным способом будет написать такой огромный запрос, рефакторинг которого превращается в ад

Entity модель и в целом Object Relation Mapping (оно же ORM, реализациями которого и являются Spring Data и Hibernate) - это модель отображающая объекты из ООП в строки таблиц SQL, что позволяет взаимодействовать с бд не написав ( написав ≥ 0) запросов

Entity граф же позволяет более точно описать сущности и сложные запросы к ним, для избежания проблем ленивой инициализации и n+1, но о них как нибудь в другой раз

Для тех кому интересно узнать больше о Spring Data

Ключевым аспектом при приеме на работу помимо хардов/софтов, особенно на стажку/джуна являются алгоритмы. Из всех моих собесов их спрашивали процентах на 90% (особенно этим грешит пресловутый Яндекс).Большинство задач сводятся к одним и тем же паттернамскоторые надо уметь увидеть и применить

По уровню это обычно easy-medium задачи leetcode.com
Из его аналогов можно отметить coderun от Яндекса и codewars

Подобные сервисы предлагают решать задачи на определённые темы (list, map,динамическое программирование и тд) или воспользоваться подборками с наиболее частыми задачами определённых компаний

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

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

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

tipical autistic developer day

только что в квалификационном контексте Yandex Cup по бекенду пытался решить безумно интересную задачу

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

Респект Яндексу за интересный формат задачи для контекста
И большой дизреспект за то, что конфиг для этой задаче собирается через go, который я не могу физически поставить на рабочий ноут, с которого и решал контест(

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

оконная функция (в отличие от агрегирующей) рассчитывает значения для всех значений внутри партиции (окна, по сути - набора строк, отвечающему условиям) и сохраняет количество строк, что позволяет применять их последовательно/поочерёдно для всего набора набора данных