Менеджер: А как вы оцениваете задачи в майках или попугаях?
Мы: В попугаях

Наши попугаи:

Когда я сделаю свою конференцию я никому не скажу. Но будут знаки.

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

Моя защита от мошенников:

Когда разделил на ноль

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

Итак, отвечаю на вопрос. Наверное расширим его вообще на вопрос из разряда как бы я изучал Spring. Это все мои мысли, не призыв к действию, все ситуации выдуманы, все люди - актеры.

Первое, что надо понимать - это то, что Spring это в целом огромный комбайн, там есть очень много всего, что-то и вовсе довольно экзотическое (типа Spring ACL). Второе, это то, что сейчас чаще (не всегда, но чаще) - когда говорят изучить/написать на Spring имеют в виду именно Spring Boot.

И тут важно понимать, что именно вы хотите и какова ваша цель. Если ваша цель - это погрузиться в разработку, что то достаточно быстро сварганить и запустить, то это одно. Если ваша цель прямо покопаться в устройстве - это другое.
Мы рассмотрим, что ваша цель - это вот именно сварганить что-то, научиться базовые вещи писать (эдакие CRUD-ы) и плюс-минус понимать че ваще зачем и как этот Spring.

Я бы не рекомендовал книжку Spring Для профессионалов (или Spring Pro) - как по мне, так это вода водой и ваще смысла не вижу.
Но мне в свое время (да я и сейчас думаю это актуально) понравились доклады Евгения Борисова по Spring. Их я бы рекомендовал посмотреть (если вы новичок): это Spring Потрошитель 1,2, Spring построитель, Spring Patterns для взрослых
Это такое не особо напряженное, не слишком сложное, с хорошей подачей - дает основы и общее понимание сути, как по мне - отлично

Из книг Spring In Action поновее можно полисать. Также есть такая книжка Spring Boot по-быстрому, но я бы посоветовал это чуть попозже, сначала вам надо прямо попрактиковаться и чтобы это было просто, чтобы была маленькая победа. Для этого:

Параллельно с этим вам нужна практика - тут можно начать с простых проектов на оф сайте Spring, там они оч простые и прямо для старта - запустить что то и посмотреть, что оно работает ок. Далее я бы посоветовал для ускорения и чтобы было попроще - это писать проект с кем-то, кто объяснит. Так как у вас скорее всего этого ментора под рукой нет (а иначе че бы вы читали бы этот текст) - то я бы посоветовал найти проект, который уже пишет кто-то на ютубе и писать его. Например, вы посмотрели урок/часть - поставили на паузу и БЕЗ подсматриваний у себя пишете эту част. Тупите - смотрите, не тупите - не смотрите. Что не понятно - гуглим, gpt, спрашиваем в каналах помощи (в конце скину ссылки)

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

Проектов на ютубе таких море, найдите что то прямо поновее и пробуйте. Как почувствуете, что уже тесновато и можете прямо спокойно писать такое - поднимите планку, например, найдите что-то из проектов таких старое (уже устаревший такой) и попробуйте его на новом стеке переделать. К примеру вот у @letsCodeDru (название канала) был отличный канал, где он много что писал, но забросил - попробуйте те проекты переписать на современном Spring Boot-е.

Здесь важно, чтобы вы прямо много печатали и как можно реже подсматривали - вы должны прямо научится в такой код и не боятся его.
После можно глянуть что-то типа @shurik_codes (на ютубе)- местами там для начинающего есть полезные вещи.

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

После я бы посоветовал сделать или оформить какой-нибудь проект и прийти в какие-нибудь группы типа Spring АйО @spring_aio_chat, @javastart и попросить поревьюить вас - наверняка будут отклики и вам дадут пару советов.
Ну и вроде готово, база есть, понимание плюс минус есть, а детали уже в работе и на практике за деньги что называется придут.

Да и обязательно ознакомьтесь с spring initializr

Ну и на всякий случай ссылки на ресурсы, каналы, to sum up:
Сайт:
https://spring.io/quickstart
https://spring.io/guides
https://start.spring.io/

Книги:
1. Spring In Action
2. Spring по быстрому

Ютуб:
Ну беглый поиск - вот можно для самых основ начала попробовать:
https://www.youtube.com/watch?v=8W5CeSGcAU0&pp=ygUXc3ByaW5nINGC0LXRgdGC0L7QstC-0LU%3D
https://www.youtube.com/watch?v=Ft4FKXOfmf0
https://www.youtube.com/watch?v=5yb_nz3x0aQ
@letsCodeDru (устаревает и многое устарело - толко в качестве практики на переписывание на новый стек)
@shurik_codes - смотреть на середине своего обучения, когда уже прошел страх спринга
Начать с https://www.youtube.com/playlist?list=PLs_aLxm3VDLt24V_BLaM5MLbh59tOEXX3

Ну и дальше вы там посмотрите сами еще что то

Телеграм:
@spring_aio_chat
@javastart

При этом по мере укрепления и спокойного погружения, обретения уверенности - начните постепенно углубляться в темы @Transactional в Spring (доклады на JUG, статья на Habr), во всякие Spring Security, начинайте думать о том как ваше приложение будет обрабатывать ошибки ( https://spring.io/blog/2013/11/01/exception-handling-in-spring-mvc и подобные) и так далее, просто усложняем и смотрим дальше.

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

Джуниор пытается найти максимум в массиве перебором, сеньор спрашивает а нахрен вы его вообще там спрятали?

Если я стану архитектором я никому не скажу. Но будут знаки.

Когда пришел на новый проект

В RFC авторы в конце указывают свои телефоны и адреса.

Вот это я понимаю уверенность в том, что ты пишешь!

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

Лирическое настроение. С тех пор благодарен очень Супрунову Михаилу и Алимову Алишеру. Спасибо вам.

И раз уж мы затронули тему наставников, то не могу не вспомнить и не поблагодарить еще Владимира Буднева. Это человек, на которого я и по сей день стараюсь равняться как на тимлида. Легенда!

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

На этом спасибо и жду вас завтра на JPoint (но, видимо, не с утра уже).

Так, ну что, бродяги! Вы не ждали, но дождались - вот и закончился JPoint, а значит я свои обязанности выполнил: лайтинг толки провел (тут спасибо моему коллеге по этой секции Петру Портнову), побыл экспертом на докладе!

В целом, справился, но не без косяков. Не все лайтинги получились легкими и иногда я даже не знал как подступиться и пошутить к чему-то, потому ощущение внутреннее, что вышло неплохо, но могло быть получше.
Оценки пока по секции очень положительные, что радует. Кстати если вы были и не поставили оценку или комментарий - сделайте, мне будет важно увидеть вашу обратную связь. Вообще, то, что регулярно человек 30 досиживают все 3-4 часа этой секции и не уходят до конца это хороший показатель. У нас уже такой своеобразный клуб прямо любителей лайтинг толков, многих я уже даже узнаю! Если меня в следующий раз также пригласят ведущим, то я уже точно выступлю сам и может даже сделаю стендап небольшой на АйТи тему.

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

Следующей активностью было экспертность на стенде Spring АйО, где я тоже наваливал джаза.

В общем, в этот раз пришлось прямо работать и вкалывать.

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

В общем очень понравилось, слава богу уже домой еду!
И слава богу все эти конференции кончились, в ближайшем моем будущем!

P.S. теперь приеду и начну отвечать дальше на вопросы ваши в предыдущем посте!

Еще вспомнил!
Несмотря на то, что я уже давненько не преподаю на конференции меня нашла моя бывшая студентка (еще с МФТИ!!), а в один из спикеров сказал, что недавно ходил в ВШЭ по каким-то своим делам и мне передавали привет, что помнят и отзывались с приятной обратной связью!

Так что отголоски преподавательской деятельности до сих пор еще доносятся до меня, что удивительно, но, не буду скрывать, приятно.
Больше всего я рад именно за студентку - так как несмотря на тот курс (который не совсем для них профильный и скажем честно не самый лучший) - она пришла в АйТи, в Java, на JPoint! Не знаю, но мне было прямо приятно и горжусь ей. Хотя, к своему позору, я немного растерялся и даже не сразу вспомнил/понял с какого ВУЗ-а (виной тому недосып и волнение перед лайтинг толками)

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

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

На этом тему JPoint-а точно мы завершаем!

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

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

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

Вот эта картинка (прикрепляю)

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

Не растолстел, а горизонтально отмасштабировался

Вайбкодим)))))

Наша методология разработки

Продолжаем вашу(мою) любимую рубрику Ответ на вопрос
И телезрители играют против знатоков, вопрос из зала задает @Vlod_R

Вопрос:
Как у тебя происходило изучение других ЯПов/стеков? Когда уже был опыт в каком-то
Что бы посоветовал при перекате с ноды/ТС на JVM? Может уже работал с такими людьми и замечал общие ошибки?

Ответ:
Скажу честно, что такие перекаты от санитаров в изучении других ЯП у меня не то чтобы популярная история. В целом совет тут можно дать самый базовый: у любого ЯП есть его стержень (у некоторых ЯП типа как Scala их может быть несколько), так вот понять надо именно стержень этот. Например, в Java - это ООП (ОПГ) и разделение логики на всякие сервисы, контроллеры (Spring головного мозга) - поняв эти две вещи вы точно сможете на работе говорить на одном языке. Здесь важно не уходить в детали и всякие там типы данных - ну есть они и есть, вы их потом поймете. По сути этот стержень - это и есть философия языка, его главная парадигма.

У Python эта философия (как по мне) в нескольких вещах:
Это его гибкость через эти все словари у каждого объекта - что вы там в словаре объекта найдете все его возможности по сути.
Это его ООП (именно свой взгляд, не как у Java) и стиль написания (все эти генераторы).

В Java это его ООП и именно то как Java видит полиморфизм - отсюда все эти интерфейсы там и прочее. Можно полистать старую книжку (она реально чуть устарела, но плюс минус все еще будет полезна) Эккеля Thinking in Java. Даже посмотрев как в Java сделаны ФП вещи можно сформулировать вот именно ту самую философию. По сути (если коротко) Java очень любит абстракции и слои абстракций - отсюда эти все абстрактные фабрики абстрактных методов (шутка) (я не шутил)

Не советую еще читать Шилдта (это как справочник имхо он не нужен сейчас) и Блоха тебе пока не надо читать первое время, на мой взгляд это может отпугнуть

Основные ошибки же у всех одни - надо перестать писать «как вы писали» (забудьте чему вас учили в школе!), например, кто приходит с Си (студенты) - они начинают экономить сразу же байтики повсюду, это не нужно. Вторая популярная ошибка (кмк) - это уход в детали сразу, погружение слишком глубокое туда, куда еще рано. Часто бывает такое, что человек там начинает про какие-то Integer Pool-ы читать, а это ну точно не то, что ему надо сейчас. Третья ошибка - уход в теорию и мало практики (я на нее сам регулярно попадаю).

Очень важно сразу понять нейминг - по сути грамматика для ЯП, в Java принято размашисто писать, в Go нет - вот уже и первые ошибки будут, если ты начнешь как-то называть переменные или классы/методы коротко с кучей сокращений

Еще Java очень строгий и закрытый язык, в отличи от того же JS.
Это выражается и в структуре кодовой базы:

├── controller
├── service
├── repository
├── model
├── config

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

Еще отличие, которое замечал, что то, что смотришь на конференциях на том же Python - это все уже было в Симпсонах Java (не так давно смотрел вот про DI доклады там)

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

На правах рекламы еще посоветую JBook но я сам туда пишу и совет из разряда пользуйтесь - это круто, ведь это я делаю!
Но мне кажется там норм некоторые вещи (не все) описаны и полезны.

И я бы на твоем месте быстрее переходил бы в Spring/Ktor/Quarkus/Микронавт там - короче куда то туда, а по мере необходимости уже детали бы изучал.
Вообще популярные фреймворки языка - это тоже в том числе отражение его философии (то как ее видит большинство) - вот тебе это подойдет прямо.

Senior Java Developer ищет баг перед отпуском