Итак, начнем с довольно остросоциальной темы☠️

#java #junior
Как передаются параметры в Java? По ссылке или по значению?

Очень часто люди отвечают как-то так: "Java передает примитивные типы по значению, а объекты по ссылке"
На самом деле ответ проще: Java всегда передает параметры по значению

Давайте разберемся в определениях:

Передача по значению (by value): Берется переменная, значение которой мы хотим использовать в методе. Значение этой переменной КОПИРУЕТСЯ и передается в метод.
Передача по ссылке (by reference): Берется переменная, значение которой мы хотим использовать в методе. Значение этой переменной НЕ КОПИРУЕТСЯ. В метод передается лишь УКАЗАТЕЛЬ на саму эту переменную (не на ОБЪЕКТ, а на ПЕРЕМЕННУЮ, которая указывает на ОБЪЕКТ)

С примитивными типами все понятно, в Java мы копируем значение переменных и считаем что-то в методе, самая настоящая передача по значению 👍

С ссылочными типами и возникают трудности. Часто под "передачей параметра по ссылке" люди имеют ввиду "передачу ссылки на объект".
Действительно, в Java в метод передается КОПИЯ ссылки на объект. Однако суть "передачи значения по ссылке" в том, что в метод передается НЕ ссылка на объект, а ссылка на переменную, которая уже ссылается на этот объект.

То есть при "передаче по ссылке" в методе мы получаем УКАЗАТЕЛЬ на ПЕРЕМЕННУЮ, которая в свою очередь указывает на ОБЪЕКТ.
А при "передаче по значению" в метод просто КОПИРУЕТСЯ ссылка на объект, и именно так и происходит в Java.

Java всегда передает параметры по значению 👩‍🎓

#java #junior
Где хранятся примитивные поля объектов? 🧳

Ответ односложен - в куче. Но почему же так происходит? Почему примитивные поля не могут храниться в стеке? 💆‍♀️

Для этого давайте откатимся назад и обсудим, что же такое стек?

Стековая память в Java работает по схеме LIFO (Последний зашел-Первый вышел)

Каждый раз, когда мы вызываем метод, в стеке формируется новый блок, который содержит все примитивы и ссылки на объекты (НЕ САМИ ОБЪЕКТЫ, они хранятся в куче)🧶

Как только метод завершается - этот блок УДАЛЯЕТСЯ из стека. Соответственно, все примитивы и ссылки на объекты удаляются из стека в этот же момент. Они больше нам не нужны, потому что все расчёты с ними мы завершили (как вы знаете, область доступности переменной в Java ограничивается блоком = фигурными скобками, в которых она объявлена)

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

Именно для сохранения целостности объекта все поля этого объекта сохраняются в КУЧЕ, и никак иначе🕶

#java #middle
Почему не всегда использование всех фишек подключаемых библиотек – это хорошо? 🌪

Зачастую, подключая какую-либо библиотеку к проекту, мы верим ей почти беспрекословно. Кажется, что всё, что мы подключаем к проекту, изначально не может содержать ошибок или недоработок.

Но это не так! Зачастую в библиотеках есть большое количество и неисправленных багов, и экспериментальных фишек ⚠️

Такая ситуация случилась со мной совсем недавно: я использовал библиотеку для автогенерации кода Lombok, которая позволяет не создавать конструкторы, сеттеры, геттеры самостоятельно, а генерирует их за счет добавления аннотаций. Например, при добавлении @Getter над классом, эта библиотека создаст геттеры для всех полей этого класса. Очень удобно.

И вот я разрабатываю класс-утилиту – вспомогательный класс, все члены которого статические, а экземпляры этого класса не могут существовать (создается приватный конструктор). Примером такого класса является java.lang.Math.

В этот момент мне приходит идея использовать аннотацию @UtilityClass, которая как раз создает, и приватный конструктор и запрещает создание любых других конструктор. И более того, помечает класс final. Жизнь сладка! 🍏

Ан нет! Я не прочитал документацию на эту аннотацию (а стоило): https://projectlombok.org/features/experimental/UtilityClass

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

То есть (на примере java.lang.Math) так бы сработало: import static java.lang.Math.*
А так нет: import static java.lang.Math.PI

Открыв документацию, мы сразу видим надпись «Experimental» и описание той самой проблемы, о которой я писал выше.
Используя библиотеки – будьте внимательны к экспериментальным фишкам! ♨️

Пример работы аннотации

А это описание аннотации. Также перевел на русский для общего понимания темы для тех, кто плохо понимает английский

Как учиться лучше? #junior #middle #Поговорим 🧠

Думаю, что многие видели картинку, прикрепленную к посту. Многие даже задавались вопросом: "Как же эти знания применить, чтобы действительно понять что-то? Я все понял, но как сажусь делать - ступор"

Тут нам поможет немного усовершенствованный "метод Уточки", напомню вам его:
"Если вы не знаете, как решить какую-то проблему, расскажите о ней утенку, вряд ли он что-то поймет, но благодаря этому вы сможете найти ошибку в своих рассуждениях или найти ответ на свой вопрос" 🐣

Выкидываем из этого уравнения уточку и тащим своего друга, девушку, бабушку или семейного врача (если у вас есть такой, я вам завидую), садим перед собой и пытаемся на простых примерах объяснить сложные вещи.
Ведь "Если вы учёный, квантовый физик, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан." 🔮

Как объяснять: начните со слов, которые точно известны человеку.
Например, что такое переменная? Это коробка, в которой лежит какое-то число или символ, или что-то другое. Что такое массив? Ну это несколько таких коробок, которые мы положили на конвейер и дали ему какое-то название. Так мы можем легко найти нужную коробку.

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

Не забудьте о вопросах из зала ⚠️

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

Созванивайтесь вместе и пытайтесь друг-другу помочь с домашней работой (если вы проходите один курс) или за кофе объясните уже коллеге, почему не нужно сливать сырые изменения в мастер. Может быть, вы и сами чего-то нового узнаете от себя или про себя👩‍🎓

#ЯПрочитал #junior #middle 👩‍🎓

Я не самый большой фанат книг, за что частенько ругаю себя, но есть книги, с которыми стоило бы ознакомиться каждому.

Я думаю, что вы и без меня сможете найти "Топ-10 книг для разработчика", но есть и менее популярные, но достойные книги 👀

Задумывались ли вы о том, как вас видит руководитель? Доволен ли он вашей работой или ищет вам замену? Что можно улучшить в работе с точки зрения вашего менеджера или лида?
Если вы хоть раз задавались подобными вопросами, то "Мама, я Тимлид" Марины Перескоковой - отличный книга не несколько вечеров

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

В жизни всё не так, нет идеальных руководителей, как и нет идеальных работников. Но именно этот "идеальный" взгляд "идеального" босса позволит стать чуть ближе к тому, чтобы выглядеть в глазах нашего (любимого, но не идеального начальника) лучше.

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

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

Всем остальным - крайне рекомендую

#junior #middle #senior #Поговорим

Сегодня поговорим с вами об ещё одной чисто soft-skill теме.

Синдром самозванца. Кому то могло стать плохо уже только от названия, кто-то сразу вспомнил себя, а кто-то просто слышал, но никогда не сталкивался с ним лицом к лицу🙈

Если коротко, то "синдром самозванца" - когнитивное искажение, при котором человек полностью убежден, что он: слабое звено команды, случайно попал в эту компанию, не способен быть полезным, глупее других и так далее (нужное подчеркнуть)

Если в других профессиях эта проблема имеет локальный характер, то для программистов - это настоящий бич 🥲

Так, по исследованиям Хабр, более 97% программистов сталкивались с синдромом хотя бы раз в жизни. По данным другого исследования, от 40 до 80 процентов разработчиков (в зависимости от компании) страдают этим синдромом.

Итак, все что мы можем делать с этим синдромом - бороться с ним.

А как?

1. Первое, что нужно сделать - распознать, что вы подвержены этому синдрому. Если вы часто говорите: "мне повезло", "да там ничего сложного" или думаете о том, что вы не достойны того, что имеете, значит, вы в списке "самозванцев". Располагайтесь, налью вам кофе)

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

3. Сходите уже, наконец, к психологу. Это не какой-то страшный мозгоправ из фильмов ужасов. Психолог - это фитнес-тренер, только для мозга ⭐️

4. Помните о том, что когда вы сравнивание себя с кем-то вы, скорее всего, совершаете две ошибки:

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

4.2 Вы совсем не учитываете, что сеньор, сидящий справа от вас, 6 лет назад был таким же, как и вы. И совсем не учитываете, что через 6 лет (а может даже раньше) вы будете тем самым сеньором. Сейчас у вас нет такого опыта, как у него.

И ЭТО НОРМАЛЬНО! Не сравнивайте свое начало пути с чьей-то серединой.

Не болейте 🌧

Всем привет! Уже в среду выложим очень интересный контент для вас❤️

Один из подписчиков примет участие в "Собеседовании на разбор"

Что это такое?
Это новая рубрика на канале, в которой соискатель проходит интервью со мной, а запись этого собеседования выкладывается в группу и тут же мы делаем общий разбор, определяем сильные и слабые стороны кандидата.

Следите за группой, чтобы не пропустить ничего нового!

#junior #middle #senior #hrПозор
Часто, когда мы получаем отказ - мы расстраиваемся, а когда приходит позитивный отклик - радуемся. Это весьма банальные истины, но есть такие вакансии, от которых хочется плакать или, даже, смеяться...

Вот на такую интересную вакансию меня как-то пригласили. Давайте пройдемся по основным моментам и посчитаем количество "red flags":

♨️ В вакансии вообще не указано, чем конкретно вы будете заниматься, какой продукт будете делать, какие знания нужны. А над чем я работать-то буду?
👩‍🎓 Автор вакансии пишет только о том, что вы должны обязательно иметь 5 по математике. И что, давно это оценки в школе или университете говорят об уровне знаний?
🥲 Ни слова о soft-skills, то есть, нанимающему менеджеру (а он вообще тут есть?) вообще все равно, как вы уживетесь с коллективом. Добро пожаловать в змеюшник. Ведь если вас набирают именно так, то остальных точно так же)
☠️ Слова, вроде "Сэкономьте ваше время", "подумайте" максимально уничижительны, вас как бы заранее ставят в позицию "докажи, что ты крутой". Просто представьте, что будет, когда вы будете в подчинении!
🏁 Пример про испанского писателя я вообще разбирать не хочу, вы и сами все понимаете. Ах да, забыл о том, что текст писал человек, абсолютно не знакомый с hr-процессами. Значит и штата специалистов по кадрам в этой компании нет, не было и не будет!

В общем, берегите себя, а я отказался от этой вакансии только по одной причине - очень боюсь, что мне скажут, что я не программист 😂