Forwarded from SnowOne-канал
Мы продолжаем публиковать описания докладов и даже чуть ускоряемся! Сегодня очередь самого практического контента: доклады из категории Enterprise (все доклады будут в основной день, 1 марта).
1) Павел Кислов раскроет тему Spring Security и его работы с OAuth2, OIDC, SAML, SSO и Spring Authorization Server;
2) Михаил Поливаха прочитает основательный доклад про ORM-системы, рассмотрит примеры, ключевые дизайн-принципы и вытекающие из этого ограничения и use-кейсы;
3) Артём Бояршинов расскажет о том, как правильно проектировать Fluent API на Java, обратившись к примерам популярных библиотек: Spring Security, AssertJ, Awaitility и других;
4) Илья и Фёдор Сазоновы объяснят, что за настройка OSIV в Spring, чем она вредит и почему ее нужно отключать. Обсудят, что можно сделать, если пожар, вызванный этой настройкой, надо тушить прямо сейчас и времени на рефакторинг системы нет;
5) Сергей Петрелевич выступит с докладом "Что такое и для чего нужно backpressure?", где полностью раскроет тему и в том числе покажет, как backpressure уже реализовано в WebFlux.
Больше деталей о каждом из докладов можно прочитать здесь, а у нас впереди анонс еще одного блока интереснейших докладов, не переключайтесь!
1) Павел Кислов раскроет тему Spring Security и его работы с OAuth2, OIDC, SAML, SSO и Spring Authorization Server;
2) Михаил Поливаха прочитает основательный доклад про ORM-системы, рассмотрит примеры, ключевые дизайн-принципы и вытекающие из этого ограничения и use-кейсы;
3) Артём Бояршинов расскажет о том, как правильно проектировать Fluent API на Java, обратившись к примерам популярных библиотек: Spring Security, AssertJ, Awaitility и других;
4) Илья и Фёдор Сазоновы объяснят, что за настройка OSIV в Spring, чем она вредит и почему ее нужно отключать. Обсудят, что можно сделать, если пожар, вызванный этой настройкой, надо тушить прямо сейчас и времени на рефакторинг системы нет;
5) Сергей Петрелевич выступит с докладом "Что такое и для чего нужно backpressure?", где полностью раскроет тему и в том числе покажет, как backpressure уже реализовано в WebFlux.
Больше деталей о каждом из докладов можно прочитать здесь, а у нас впереди анонс еще одного блока интереснейших докладов, не переключайтесь!
🔥1
Газообразное состояние дел 🎈
Когда я только начинал путь разработчика и постигал основы планирования, мой тогдашний руководитель (я бы даже сказал "просветитель") где-то в разговоре обронил фразу, показавшуюся мне до глупости очевидной:
Ну это же элементарно: вот сколько ты работал над задачей, столько времени и прошло — всё понятно. И всё же эта фраза почему-то запала мне в память.
Её истинный смысл "догнал" меня позже. Она описывает не тривиальную простоту измерения времени для заданного (конечного и единичного) блока работ, а наоборот — свойство дел неявно подстраиваться под "объём" предоставленного им времени. Ведь действительно: вспомните, сколько раз вы заканчивали проекты задолго до наступления дедлайна? Если много (постоянно), расскажите, пожалуйста, в комментариях, как вам это удаётся. Но что-то мне подсказывает, что это не так. И это нормально.
На моей памяти, нетривиальные проекты (в основном, рабочие, но и личные тоже) чаще завершаются где-то в районе дедлайна. И дело здесь отнюдь не в "меткости" того, кто ставит дедлайны. Ему, по большому счёту, достаточно быть адекватным (чтоб не впадать в крайности), а метким — не обязательно. Потому что дальше всё произойдёт без него:
● далеко за дедлайн исполнитель не заступит, поскольку величина задержки наверняка пропорциональна негативу, который он получит;
● задолго до дедлайна исполнитель не закончит как раз в силу описанного выше свойства: мы не любим заставлять себя торопиться, пока не почувствуем в этом реальной необходимости, а значит, пока дедлайн далёк, задача будет делаться "в комфортном темпе".
И вот потому, что "комфортный темп" — понятие ооочень растяжииимое (даже для одного и того же человека в разное время), выполняемые задачи с лёгкостью занимают всё предоставленное им время, разве что могут несколько уплотняться в конце.
Это удивительное и в чём-то даже контр-интуитивное свойство натолкнуло меня на аналогию из школьного курса физики, точнее, термодинамики. Как вы наверняка помните, газ занимает весь предоставленный ему объём, при этом его плотность меняется обратно пропорционально занятому объёму.
То же происходит и с делами во времени:
● каким бы ни был "истинный" объём работ, фактический срок выполнения наверняка окажется сопоставим с дедлайном;
● постановка сжатых сроков, очевидно, приводит к повышению плотности работы и, как следствие, к повышению "температуры", способному привести к последующему (воз)/(вы)горанию;
● закладывание большого запаса в сроки отнюдь не гарантирует, что дедлайн не будет достигнут, но может привести к тому, что бОльшую часть времени работа будет вестись с низкой плотностью, а значит, весьма "прохладно".
Помимо этих почти поверхностных выводов, такая аналогия привела меня к одному куда менее очевидному умозаключению: когда хочется/нужно заняться чем-то новым, но кажется, что "мне ваще некогда", "каждый день под завязку", "график капец плотный" и т.п., то вместо поиска дела-жертвы (в ущерб которому добавится новое) достаточно просто начать заниматься новым хоть в какое-то время и, выждав небольшой контрольный период, посмотреть что будет.
Поскольку дела сродни газу, они с высокой вероятностью легко уплотнятся, уступив место новому в том же объёме времени. Разумеется, так можно делать не до бесконечности, и постепенно плотность перестанет быть выносимой. И всё же потенциал "холодного уплотнения" у нас зачастую остаётся не раскрытым, и мы без всякого перенапряжения можем успевать больше. Стоит лишь попробовать 😉
P.S. Взятая из Википедии картинка иллюстрирует процесс расширения газа при внешнем нагревании, что в переводе на советы менеджерам звучит как: "чем чаще контролируешь исполнителя, тем дольше его ждёшь".
Когда я только начинал путь разработчика и постигал основы планирования, мой тогдашний руководитель (я бы даже сказал "просветитель") где-то в разговоре обронил фразу, показавшуюся мне до глупости очевидной:
Работа занимает столько времени, сколько под неё отводится
Ну это же элементарно: вот сколько ты работал над задачей, столько времени и прошло — всё понятно. И всё же эта фраза почему-то запала мне в память.
Её истинный смысл "догнал" меня позже. Она описывает не тривиальную простоту измерения времени для заданного (конечного и единичного) блока работ, а наоборот — свойство дел неявно подстраиваться под "объём" предоставленного им времени. Ведь действительно: вспомните, сколько раз вы заканчивали проекты задолго до наступления дедлайна? Если много (постоянно), расскажите, пожалуйста, в комментариях, как вам это удаётся. Но что-то мне подсказывает, что это не так. И это нормально.
На моей памяти, нетривиальные проекты (в основном, рабочие, но и личные тоже) чаще завершаются где-то в районе дедлайна. И дело здесь отнюдь не в "меткости" того, кто ставит дедлайны. Ему, по большому счёту, достаточно быть адекватным (чтоб не впадать в крайности), а метким — не обязательно. Потому что дальше всё произойдёт без него:
● далеко за дедлайн исполнитель не заступит, поскольку величина задержки наверняка пропорциональна негативу, который он получит;
● задолго до дедлайна исполнитель не закончит как раз в силу описанного выше свойства: мы не любим заставлять себя торопиться, пока не почувствуем в этом реальной необходимости, а значит, пока дедлайн далёк, задача будет делаться "в комфортном темпе".
И вот потому, что "комфортный темп" — понятие ооочень растяжииимое (даже для одного и того же человека в разное время), выполняемые задачи с лёгкостью занимают всё предоставленное им время, разве что могут несколько уплотняться в конце.
Это удивительное и в чём-то даже контр-интуитивное свойство натолкнуло меня на аналогию из школьного курса физики, точнее, термодинамики. Как вы наверняка помните, газ занимает весь предоставленный ему объём, при этом его плотность меняется обратно пропорционально занятому объёму.
То же происходит и с делами во времени:
● каким бы ни был "истинный" объём работ, фактический срок выполнения наверняка окажется сопоставим с дедлайном;
● постановка сжатых сроков, очевидно, приводит к повышению плотности работы и, как следствие, к повышению "температуры", способному привести к последующему (воз)/(вы)горанию;
● закладывание большого запаса в сроки отнюдь не гарантирует, что дедлайн не будет достигнут, но может привести к тому, что бОльшую часть времени работа будет вестись с низкой плотностью, а значит, весьма "прохладно".
Помимо этих почти поверхностных выводов, такая аналогия привела меня к одному куда менее очевидному умозаключению: когда хочется/нужно заняться чем-то новым, но кажется, что "мне ваще некогда", "каждый день под завязку", "график капец плотный" и т.п., то вместо поиска дела-жертвы (в ущерб которому добавится новое) достаточно просто начать заниматься новым хоть в какое-то время и, выждав небольшой контрольный период, посмотреть что будет.
Поскольку дела сродни газу, они с высокой вероятностью легко уплотнятся, уступив место новому в том же объёме времени. Разумеется, так можно делать не до бесконечности, и постепенно плотность перестанет быть выносимой. И всё же потенциал "холодного уплотнения" у нас зачастую остаётся не раскрытым, и мы без всякого перенапряжения можем успевать больше. Стоит лишь попробовать 😉
P.S. Взятая из Википедии картинка иллюстрирует процесс расширения газа при внешнем нагревании, что в переводе на советы менеджерам звучит как: "чем чаще контролируешь исполнителя, тем дольше его ждёшь".
❤4👍2
Программный комитет конференции SnowOne, в котором мне выпала честь состоять, в этот раз отработал на опережение и укомплектовал программу в рекордно ранние сроки (по нашим собственным меркам, разумеется). При этом состав и качество программы вызывают гордость и нетерпение представить её вам. Осталось меньше месяца, скоро всё увидим 😉
❤1
Forwarded from SnowOne-канал
Заканчиваем серию постов про наши доклады!
В финальной партии мы собрали очень разные, и от того только более интересные доклады.
1) Настя Лисицкая приоткроет завесу тайны, рассказав как устроен умный ассистент Алиса внутри: какая там архитектура, что именно написано на Java/Kotlin и при чем тут LLM;
2) Александр Чесноков покажет, как можно реанимировать забытые проекты. На примере библиотеки jSymbolic2 покажет, как можно автоматически привести проект в чувство, улучшить читаемость кода и даже увеличить производительность;
3) Александр Нозик расскажет, что такое контекстно-ориентированное программирование, и как оно работает в разных языках. Конечно же речь пойдет и о Kotlin с его контекстными ресиверами и контекстными параметрами;
4) Дмитрий Черкасов обсудит, как бэкенд-разработчику создавать фулстек-приложения с UI на Kotlin. Что лучше использовать: Ktor HTML Templates? Vaadin Kotlin DSL? React? В своем докладе Дмитрий рассмотрит различные варианты, расскажет про плюсы и минусы каждого из них;
5) Николай Шипяков посвятит свой доклад интеграционным тестам: на примере типичного REST-сервиса пройдет путь от полного отсутствия тестов до полноценного покрытия ими всего проекта и поделится советами, как повторить этот путь на вашем проекте уже без боли.
—
Таким образом, на сайте сейчас опубликованы уже все 19 докладов нашей конференции! Очень скоро там появится и расписание (в котором кроме докладов будут и дополнительные активности), так что не переключайтесь)
В финальной партии мы собрали очень разные, и от того только более интересные доклады.
1) Настя Лисицкая приоткроет завесу тайны, рассказав как устроен умный ассистент Алиса внутри: какая там архитектура, что именно написано на Java/Kotlin и при чем тут LLM;
2) Александр Чесноков покажет, как можно реанимировать забытые проекты. На примере библиотеки jSymbolic2 покажет, как можно автоматически привести проект в чувство, улучшить читаемость кода и даже увеличить производительность;
3) Александр Нозик расскажет, что такое контекстно-ориентированное программирование, и как оно работает в разных языках. Конечно же речь пойдет и о Kotlin с его контекстными ресиверами и контекстными параметрами;
4) Дмитрий Черкасов обсудит, как бэкенд-разработчику создавать фулстек-приложения с UI на Kotlin. Что лучше использовать: Ktor HTML Templates? Vaadin Kotlin DSL? React? В своем докладе Дмитрий рассмотрит различные варианты, расскажет про плюсы и минусы каждого из них;
5) Николай Шипяков посвятит свой доклад интеграционным тестам: на примере типичного REST-сервиса пройдет путь от полного отсутствия тестов до полноценного покрытия ими всего проекта и поделится советами, как повторить этот путь на вашем проекте уже без боли.
—
Таким образом, на сайте сейчас опубликованы уже все 19 докладов нашей конференции! Очень скоро там появится и расписание (в котором кроме докладов будут и дополнительные активности), так что не переключайтесь)
К новостям спорта. Несмотря на плотную загрузку по рабочим проектам, неделя ознаменовалась двумя значимыми вехами в физкультуре📺
1. В среду на контрольном заплыве на 1 км внезапно для себя (реально не ожидал) шлифанул собственный личный рекорд на 18 секунд - стало 17:05. Чтобы вы понимали масштаб этой мелочи для меня, вот статистика предыдущих заплывов этой же серии:
Правда, треть дистанции плыл плотно вслед за другим пловцом, что заставило снова задуматься о роли драфтинга в плавании, но кого это волнует🤓
2. Сегодня принял участие в местном лыжном старте коньком на 30 км. Бежал в формате длительной тренировки, не на скорость. Старт и так не обещал быть лёгким (набор высоты 600 м), а тут ещё полночи и всё утро валил снег, и трассу немножечко(ваще капец по уши) занесло, и скольжение оказалось, мягко говоря, не очень. И если обычно на больших спусках я смотрю только в лыжню, чтобы не вылететь из неё на скорости, то сегодня вполне успевал любоваться красотами заснеженного леса. Основная цель - не помереть там - выполнена, и вполне уверенно; боялся, что будет хуже. Опять же для понимания: из 111 заявившихся лыжников до финиша добрались только 93: кто-то сошёл, а кто-то, возможно, не стартовал вовсе (и правильно сделал🤪)
А вечером после гонки вновь ощутил, как это здорово - растечься в офисном кресле и тихонько постукивать пальцами по клавишам, не махая руками и не толкаясь ногами по пухлому снегу на морозе. Всё познаётся в сравнении 🙃
#спорт
1. В среду на контрольном заплыве на 1 км внезапно для себя (реально не ожидал) шлифанул собственный личный рекорд на 18 секунд - стало 17:05. Чтобы вы понимали масштаб этой мелочи для меня, вот статистика предыдущих заплывов этой же серии:
2018 (декабрь) – 19:23
2019 (декабрь) – 19:39
2020 (декабрь) – 19:13
2021 (декабрь) – 19:42
2022 (декабрь) – 20:13
2023 (декабрь) – 18:53
2024 (июнь) – 17:28
2025 (февраль) – 17:05
Правда, треть дистанции плыл плотно вслед за другим пловцом, что заставило снова задуматься о роли драфтинга в плавании, но кого это волнует🤓
2. Сегодня принял участие в местном лыжном старте коньком на 30 км. Бежал в формате длительной тренировки, не на скорость. Старт и так не обещал быть лёгким (набор высоты 600 м), а тут ещё полночи и всё утро валил снег, и трассу немножечко
А вечером после гонки вновь ощутил, как это здорово - растечься в офисном кресле и тихонько постукивать пальцами по клавишам, не махая руками и не толкаясь ногами по пухлому снегу на морозе. Всё познаётся в сравнении 🙃
#спорт
🔥7
Я долгое время думал, что PlantUML нужен только для рисования диаграмм последовательности (их ещё называются сиквенсами).
Но несколько лет назад при работе над Интернет-банком столкнулся с хитрым багом в интеграции с банковской системой через БД — там для выявления причины нужно было как-то визуализировать хитросплетение состояний потоков в терминах выполняемых ими бизнес-действий 🧶
Уже не помню как, но я вышел на тот же PlantUML, только со стороны диаграмм тайминга — это такие картинки, где над осью времени располагаются несколько полосок, описывающих изменения состояний элементов системы (или участников процесса) друг относительно друга во времени (см. примеры). Они чем-то похожи на визуализацию потоков в VisualVM и на диаграммы Гантта. Как и сиквенсы, они генерируются на основе специальной нотации, синтаксис которой оказался достаточно прост, чтобы генерировать её прямо из кода обычным `StringBuilder`ом, примерно так:
Тогда набор сгенерённых таким образом картинок действительно помог найти причину и устранить докучавший всем баг. А намедни этот же инструмент пригодился снова — с его помощью удалось визуализировать состав, порядок и времена взаимодействий между компонентами модели данных low-code платформы (вторая картинка). В светлом будущем эти данные будут отображаться на фронте крутым графом с блекджеком и шлюзами, но, пока идут сугубо фундаментные работы, смотреть на формируемый результат уже как-то надо 👁
В общем, советую взять этот инструмент на заметку. Кстати, у PlantUML есть не только удобный плагин для IDEA, но и собственный онлайн-редактор, так что первое знакомство можно осуществить весьма быстро и просто 🪆
Но несколько лет назад при работе над Интернет-банком столкнулся с хитрым багом в интеграции с банковской системой через БД — там для выявления причины нужно было как-то визуализировать хитросплетение состояний потоков в терминах выполняемых ими бизнес-действий 🧶
Уже не помню как, но я вышел на тот же PlantUML, только со стороны диаграмм тайминга — это такие картинки, где над осью времени располагаются несколько полосок, описывающих изменения состояний элементов системы (или участников процесса) друг относительно друга во времени (см. примеры). Они чем-то похожи на визуализацию потоков в VisualVM и на диаграммы Гантта. Как и сиквенсы, они генерируются на основе специальной нотации, синтаксис которой оказался достаточно прост, чтобы генерировать её прямо из кода обычным `StringBuilder`ом, примерно так:
@startuml
concise "CDAS_FETCH_EVENT" as CDAS_FETCH_EVENT
scale 30 as 100 pixels
title connector.log
0 is {hidden}
@CDAS_FETCH_EVENT
0 is 80 : db
+80 is {-}
@enduml
Тогда набор сгенерённых таким образом картинок действительно помог найти причину и устранить докучавший всем баг. А намедни этот же инструмент пригодился снова — с его помощью удалось визуализировать состав, порядок и времена взаимодействий между компонентами модели данных low-code платформы (вторая картинка). В светлом будущем эти данные будут отображаться на фронте крутым графом с блекджеком и шлюзами, но, пока идут сугубо фундаментные работы, смотреть на формируемый результат уже как-то надо 👁
В общем, советую взять этот инструмент на заметку. Кстати, у PlantUML есть не только удобный плагин для IDEA, но и собственный онлайн-редактор, так что первое знакомство можно осуществить весьма быстро и просто 🪆
🔥5
В эти самые дни в стенах АкадемПарка проходит долгожданная конференция SnowOne, к которой мы начали готовиться ещё в августе прошлого года👣
Первый (студенческий) день выдался богатым на крутые доклады. Например, на этом фото выступает сам Роман Елизаров (экс.лид языка Котлин) с увлекательным и нереально широким по охвату докладом про дизайн языков программирования. Как будет запись, посмотрите хотя бы просто для расширения кругозора 🌏
Завтрашний (основной) день обещает быть ещё более насыщенным и интенсивным. Нам как программному комитету остаётся лишь пожелать спикерам удачи и, затаив дыхание, наблюдать за их выступлениями и первой реакцией аудитории. Пусть всё будет отлично🙏🏼
Первый (студенческий) день выдался богатым на крутые доклады. Например, на этом фото выступает сам Роман Елизаров (экс.лид языка Котлин) с увлекательным и нереально широким по охвату докладом про дизайн языков программирования. Как будет запись, посмотрите хотя бы просто для расширения кругозора 🌏
Завтрашний (основной) день обещает быть ещё более насыщенным и интенсивным. Нам как программному комитету остаётся лишь пожелать спикерам удачи и, затаив дыхание, наблюдать за их выступлениями и первой реакцией аудитории. Пусть всё будет отлично🙏🏼
🔥10❤3
Помимо роли ведущего на первом потоке конференции SnowOne, сегодня мне довелось ненадолго очутиться в роли стартапера и открыть своим выступлением так называемый EasyPitch — сессию коротких презентаций проектов на (пре)акселераторе А:Старт всё в том же АкадемПарке 💚
Множество прогонов моего питч-дека в одиночку сегодня утром никак не давали уложиться в положенные 3 минуты, а под давлением глаз слушателей и собственным волнением на сцене вдруг получилось успеть за 2:39. Несмотря на эту спешку и крайне низкую читаемость слайдов, эксперты всё же включили мой проект в число победителей и вручили приглашение на акселератор А:Старт 🕺
Объектом презентации стала та самая "мимолётная" разработка, о которой я заикался здесь еще в январе. Подробнее расскажу о ней отдельно, равно как и об основной части SnowOne; не переключайтесь 📻
Множество прогонов моего питч-дека в одиночку сегодня утром никак не давали уложиться в положенные 3 минуты, а под давлением глаз слушателей и собственным волнением на сцене вдруг получилось успеть за 2:39. Несмотря на эту спешку и крайне низкую читаемость слайдов, эксперты всё же включили мой проект в число победителей и вручили приглашение на акселератор А:Старт 🕺
Объектом презентации стала та самая "мимолётная" разработка, о которой я заикался здесь еще в январе. Подробнее расскажу о ней отдельно, равно как и об основной части SnowOne; не переключайтесь 📻
🔥8❤🔥3
Первые годы жизни сибирской Java-конференции SnowOne (в ПК которой я состою) выдались не простыми – каждый раз наступал момент (а то и несколько), когда приходилось взвешивать решение об отмене: то ковид, то война, то мобилизация, то внутренние неурядицы… 🥴
Завершившийся вчера 6-ой “выпуск” конференции с самого начала был одним из самых экспериментальных по организации и этим вообще не обещал быть гладким. Но вопреки опасениям таковым оказался. Нам не пришлось переносить даты, у нас не отвалился ни один спикер, слушателей было достаточно, партнёров и стендов – тем более. Даже как будто бы скучно, на первый взгляд. Но знаете, что я об этом думаю? Да НАКОНЕЦ-ТО, блин! 🥞
Как приятно было видеть множество увлечённых лиц участников, впитывающих речь спикеров, жарко спорящих с коллегами в коридорах или самозабвенно отвоёвывающих мерч на стендах партнёров! А ещё меня поразили разносторонние способности нынешних спикеров – мало того, что они реально шарят в сложнейших областях разработки и умеют об этом рассказывать, так они ещё и в “гражданской” жизни звездят: один играет на 8 музыкальных инструментах, второй собирает мебель как автомат, третий преуспевает в гиревом спорте… 🏋️
Похоже, нам удалась действительно ламповая конференция. С нетерпением ждём обратной связи участников и начинаем предвкушать подготовку к следующему разу 😋
Завершившийся вчера 6-ой “выпуск” конференции с самого начала был одним из самых экспериментальных по организации и этим вообще не обещал быть гладким. Но вопреки опасениям таковым оказался. Нам не пришлось переносить даты, у нас не отвалился ни один спикер, слушателей было достаточно, партнёров и стендов – тем более. Даже как будто бы скучно, на первый взгляд. Но знаете, что я об этом думаю? Да НАКОНЕЦ-ТО, блин! 🥞
Как приятно было видеть множество увлечённых лиц участников, впитывающих речь спикеров, жарко спорящих с коллегами в коридорах или самозабвенно отвоёвывающих мерч на стендах партнёров! А ещё меня поразили разносторонние способности нынешних спикеров – мало того, что они реально шарят в сложнейших областях разработки и умеют об этом рассказывать, так они ещё и в “гражданской” жизни звездят: один играет на 8 музыкальных инструментах, второй собирает мебель как автомат, третий преуспевает в гиревом спорте… 🏋️
Похоже, нам удалась действительно ламповая конференция. С нетерпением ждём обратной связи участников и начинаем предвкушать подготовку к следующему разу 😋
🔥7