LINUX.ORG.RU

Встреча для Java-разработчиков: говорим про борьбу с техническим долгом и об анализе времени отклика Java-сервисов

 , , ,


0

2

DINS IT EVENING, открытая площадка, объединяющая технических специалистов по направлениям Java, DevOps, QA и JS, проведет 18 сентября в 19:30 по адресу Старо-Петергофский проспект, 19 (Санкт-Петербург), встречу для Java-разработчиков. На встрече будут представлены два доклада:

«Звездолеты на ДВС. Выжить в схватке с техническим долгом» (Денис Репп, Wrike)

— Что делать, если варп-двигатель работает на АИ-95? — Что делать, если единственный обогреватель в каюте — тостер? — Что делать, если медотсек крепится к корпусу корабля одной гайкой и тремя гвоздями? — Капитан, передайте ключ на 16 или давайте наконец разберемся с техническим долгом! В ходе доклада Денис предлагает разобраться, как организовать процесс работы с техническим долгом в критически важных частях продукта, как сделать процесс предсказуемым и прозрачным, с какими ошибками приходится сталкиваться и как их обходить.

«Distributed Tracing: анализ времени отклика Java-сервисов» (Андрей Маркелов, Infobip)

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

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

>>> Подробности и бесплатная регистрация

Ответ на: комментарий от darkenshvein

говорим про борьбу с техническим долгом

это они про экономию памяти?

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

question4 ★★★★★ ()

говорим про борьбу с техническим долгом

Это как с глобальным потеплением бороться — бесполезно. Нормально делай — нормально будет. А то говнокодят, а потом ноют про долг.

java_util_Random ★★ ()
Ответ на: комментарий от java_util_Random

проблема обычно хуже и глубже.

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

ну и поперли костыли.

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

потребовалось в dts вкорячить ещё кучу информации, которую собирают спринговые ассемблеры.

как совместить по-быстрому? ну сделаем синглтон с аппконтекстом и будем в статическом методе автовайрить вручную. как-то так

wieker ★★ ()
Ответ на: комментарий от wieker

как совместить по-быстрому? ну сделаем синглтон с аппконтекстом и будем в статическом методе автовайрить вручную. как-то так

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

dimgel ()
Ответ на: комментарий от dimgel

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

wieker ★★ ()
Ответ на: комментарий от wieker

Все косяки и костыли в коде от новых вводных.
Я вот годами ковыряюсь и конца не видно. Только что-то заработает и задышит, так эти мудели СПиП-ы хася!... и с ног на голову.
Вот и думаешь, чего им всралость переписать 1:1 и только одну фразу поменять. Да так поменять, что черное стало белым, а белое коричневым.

Одно спасение - костыли, скотч и синяя изолента :)

vada ★★★★★ ()
Ответ на: комментарий от wieker

В доках к DI-фреймворкам во введении обычно пишут, что мол они нужны т.к. если связывать всё вручную, то код связывальщика будет спагетти. Бред собачий: про декомпозицию мы не слышали, ага. Например, я связываю компоненты внутри слоёв и передаю связанный слой в следующий одним объектом с компонентами в public final полях; и пришёл я к этой идее меньше чем за день, стало быть и любой другой может родить её же или аналогичную.

В других типовых вариантах использования спринга, тупо выпилить его без какой-либо замены не выйдет. @Transactional --> форкнул lombok и добавил к нему свою @Transactional (у нормальных людей метапрограммирование в buildtime); хотя если проект простой и нагрузка низкая, можно вообще не париться и заворачивать в транзакцию точку входа (в корневом ServletFilter). WebMVC --> тонкая обёртка над Servlet API (которое хрен кто когда переплюнет), включающая java-маппер URL на контроллеры вместо web.xml (долго ж я его соображал...) и парсер параметров в DTO (есть готовые).

И всё, спринг прощай. Было бы желание.

dimgel ()
Ответ на: комментарий от dimgel

код связывальщика будет спагетти. Бред собачий

Не знаю во что сегодня разрабы превратили DI, но лет 8 назад он использовался для автоматической инициализации сервисов-синглтонов, либо per-thread однотипных объектов живущих в течении сессии пользователя. Позволяя переложить рутинный код инициализации на DI.

Но дай макакам инжектить прямо в поля через аннотации и они превращают код в ад. Я как раз отошел в сторону, когда приняли официальный JSR 330. Там у хипстеров на JS как я понимаю тоже DI во все поля? Сколько непуганых идиотов...

foror ★★★ ()
Ответ на: комментарий от wieker

как совместить по-быстрому? ну сделаем синглтон с аппконтекстом и будем в статическом методе автовайрить вручную. как-то так

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

subwoofer ★★★★★ ()
Ответ на: комментарий от subwoofer

Если бы все было так просто.

1. Статический метод дергается из метода, реализующего интерфейс.

interface A {someMethod();} class B implements A {someMethod(){callBadMethod();}} class C implements A {someMethod() { doNotCallBadMethod(); }}

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

wieker ★★ ()
Ответ на: комментарий от ritsufag

Только если инжектить сервисы в домен получится уже не совсем домен :)

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

wieker ★★ ()
Ответ на: комментарий от abcq

Опять заманиваете в свой притон имени Керри? Оставьте легушатников их уже не спасти :3

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

hateyoufeel ★★★★★ ()

Что делать, если варп-двигатель работает на АИ-95? — Что делать, если единственный обогреватель в каюте — тостер? — Что делать, если медотсек крепится к корпусу корабля одной гайкой и тремя гвоздями? — Капитан, передайте ключ на 16 или давайте наконец разберемся с техническим долгом!

Что за херню я сейчас прочитал?

DELIRIUM ★★★★★ ()