Всем привет 🤖
Меня зовут Даниил и я Java-разработчик!
Я давно занимаюсь обучением и всегда хотел создать какое-то место, где я бы смог делиться тем, что знаю сам с большим, очень большим количеством людей😺
Вот и я тут!
Меня зовут Даниил и я Java-разработчик!
Я давно занимаюсь обучением и всегда хотел создать какое-то место, где я бы смог делиться тем, что знаю сам с большим, очень большим количеством людей😺
Вот и я тут!
🌭6👍1
Программист живёт нормально pinned «Всем привет 🤖 Меня зовут Даниил и я Java-разработчик! Я давно занимаюсь обучением и всегда хотел создать какое-то место, где я бы смог делиться тем, что знаю сам с большим, очень большим количеством людей😺 Вот и я тут!»
Итак, начнем с довольно остросоциальной темы☠️
#java #junior
Как передаются параметры в Java? По ссылке или по значению?
Очень часто люди отвечают как-то так: "Java передает примитивные типы по значению, а объекты по ссылке"
На самом деле ответ проще:Java всегда передает параметры по значению
Давайте разберемся в определениях:
Передача по значению (by value): Берется переменная, значение которой мы хотим использовать в методе. Значение этой переменной КОПИРУЕТСЯ и передается в метод.
Передача по ссылке (by reference): Берется переменная, значение которой мы хотим использовать в методе. Значение этой переменной НЕ КОПИРУЕТСЯ. В метод передается лишь УКАЗАТЕЛЬ на саму эту переменную (не на ОБЪЕКТ, а на ПЕРЕМЕННУЮ, которая указывает на ОБЪЕКТ)
С примитивными типами все понятно, в Java мы копируем значение переменных и считаем что-то в методе, самая настоящая передача по значению 👍
С ссылочными типами и возникают трудности. Часто под "передачей параметра по ссылке" люди имеют ввиду "передачу ссылки на объект".
Действительно, в Java в метод передается КОПИЯ ссылки на объект. Однако суть "передачи значения по ссылке" в том, что в метод передается НЕ ссылка на объект, а ссылка на переменную, которая уже ссылается на этот объект.
То есть при "передаче по ссылке" в методе мы получаем УКАЗАТЕЛЬ на ПЕРЕМЕННУЮ, которая в свою очередь указывает на ОБЪЕКТ.
А при "передаче по значению" в метод просто КОПИРУЕТСЯ ссылка на объект, и именно так и происходит в Java.
Java всегда передает параметры по значению 👩🎓
#java #junior
Как передаются параметры в Java? По ссылке или по значению?
Очень часто люди отвечают как-то так: "Java передает примитивные типы по значению, а объекты по ссылке"
На самом деле ответ проще:
Передача по значению (by value): Берется переменная, значение которой мы хотим использовать в методе. Значение этой переменной КОПИРУЕТСЯ и передается в метод.
Передача по ссылке (by reference): Берется переменная, значение которой мы хотим использовать в методе. Значение этой переменной НЕ КОПИРУЕТСЯ. В метод передается лишь УКАЗАТЕЛЬ на саму эту переменную (не на ОБЪЕКТ, а на ПЕРЕМЕННУЮ, которая указывает на ОБЪЕКТ)
С примитивными типами все понятно, в Java мы копируем значение переменных и считаем что-то в методе, самая настоящая передача по значению 👍
С ссылочными типами и возникают трудности. Часто под "передачей параметра по ссылке" люди имеют ввиду "передачу ссылки на объект".
Действительно, в Java в метод передается КОПИЯ ссылки на объект. Однако суть "передачи значения по ссылке" в том, что в метод передается НЕ ссылка на объект, а ссылка на переменную, которая уже ссылается на этот объект.
То есть при "передаче по ссылке" в методе мы получаем УКАЗАТЕЛЬ на ПЕРЕМЕННУЮ, которая в свою очередь указывает на ОБЪЕКТ.
А при "передаче по значению" в метод просто КОПИРУЕТСЯ ссылка на объект, и именно так и происходит в Java.
Java всегда передает параметры по значению 👩🎓
🔥3❤1👍1
Многие знают, что объекты хранятся в области памяти Java, которая называется heap (куча), а примитивные типы данных хранятся в stack (стэке). А где же хранятся примитивные поля объектов? (пример ниже)
Anonymous Quiz
37%
В стэке
28%
В куче
35%
В виртуальной памяти
#java #junior
Где хранятся примитивные поля объектов? 🧳
Ответ односложен - в куче. Но почему же так происходит? Почему примитивные поля не могут храниться в стеке? 💆♀️
Для этого давайте откатимся назад и обсудим, что же такое стек?
Стековая память в Java работает по схеме LIFO (Последний зашел-Первый вышел)
Каждый раз, когда мы вызываем метод, в стеке формируется новый блок, который содержит все примитивы и ссылки на объекты (НЕ САМИ ОБЪЕКТЫ, они хранятся в куче)🧶
Как только метод завершается - этот блок УДАЛЯЕТСЯ из стека. Соответственно, все примитивы и ссылки на объекты удаляются из стека в этот же момент. Они больше нам не нужны, потому что все расчёты с ними мы завершили (как вы знаете, область доступности переменной в Java ограничивается блоком = фигурными скобками, в которых она объявлена)
Однако, если бы в стеке находились примитивные поля объектов, тогда бы при завершении метода все примитивные поля этого объекта просто-напросто удалялись. Мы бы получали картину, как на скриншоте ниже.
Именно для сохранения целостности объекта все поля этого объекта сохраняются в КУЧЕ, и никак иначе🕶
Где хранятся примитивные поля объектов? 🧳
Ответ односложен - в куче. Но почему же так происходит? Почему примитивные поля не могут храниться в стеке? 💆♀️
Для этого давайте откатимся назад и обсудим, что же такое стек?
Стековая память в Java работает по схеме LIFO (Последний зашел-Первый вышел)
Каждый раз, когда мы вызываем метод, в стеке формируется новый блок, который содержит все примитивы и ссылки на объекты (НЕ САМИ ОБЪЕКТЫ, они хранятся в куче)🧶
Как только метод завершается - этот блок УДАЛЯЕТСЯ из стека. Соответственно, все примитивы и ссылки на объекты удаляются из стека в этот же момент. Они больше нам не нужны, потому что все расчёты с ними мы завершили (как вы знаете, область доступности переменной в Java ограничивается блоком = фигурными скобками, в которых она объявлена)
Однако, если бы в стеке находились примитивные поля объектов, тогда бы при завершении метода все примитивные поля этого объекта просто-напросто удалялись. Мы бы получали картину, как на скриншоте ниже.
Именно для сохранения целостности объекта все поля этого объекта сохраняются в КУЧЕ, и никак иначе🕶
👍4
Почему в некоторых интерфейсах может быть вообще не обьявлено методов?
Anonymous Quiz
15%
В интерфейсах методов быть и не должно
9%
Чтобы было проще их имплементировать
67%
Это маркерные интерфейсы
9%
это интерфейсы-указатели
#java #middle
Почему не всегда использование всех фишек подключаемых библиотек – это хорошо? 🌪
Зачастую, подключая какую-либо библиотеку к проекту, мы верим ей почти беспрекословно. Кажется, что всё, что мы подключаем к проекту, изначально не может содержать ошибок или недоработок.
Но это не так! Зачастую в библиотеках есть большое количество и неисправленных багов, и экспериментальных фишек ⚠️
Такая ситуация случилась со мной совсем недавно: я использовал библиотеку для автогенерации кода
И вот я разрабатываю класс-утилиту – вспомогательный класс, все члены которого статические, а экземпляры этого класса не могут существовать (создается приватный конструктор). Примером такого класса является
В этот момент мне приходит идея использовать аннотацию
Ан нет! Я не прочитал документацию на эту аннотацию (а стоило):
То есть (на примере java.lang.Math) так бы сработало:
Используя библиотеки – будьте внимательны к экспериментальным фишкам! ♨️
Почему не всегда использование всех фишек подключаемых библиотек – это хорошо? 🌪
Зачастую, подключая какую-либо библиотеку к проекту, мы верим ей почти беспрекословно. Кажется, что всё, что мы подключаем к проекту, изначально не может содержать ошибок или недоработок.
Но это не так! Зачастую в библиотеках есть большое количество и неисправленных багов, и экспериментальных фишек ⚠️
Такая ситуация случилась со мной совсем недавно: я использовал библиотеку для автогенерации кода
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» и описание той самой проблемы, о которой я писал выше. Используя библиотеки – будьте внимательны к экспериментальным фишкам! ♨️
🤔4
Можно ли из не-статических методов вызывать статические? А наоборот?
Anonymous Quiz
11%
Да, Да
68%
Да, Нет
3%
Нет, Нет
18%
Нет, Да
Как учиться лучше? #junior #middle #Поговорим 🧠
Думаю, что многие видели картинку, прикрепленную к посту. Многие даже задавались вопросом: "Как же эти знания применить, чтобы действительно понять что-то? Я все понял, но как сажусь делать - ступор"
Тут нам поможет немного усовершенствованный "метод Уточки", напомню вам его:
"Если вы не знаете, как решить какую-то проблему, расскажите о ней утенку, вряд ли он что-то поймет, но благодаря этому вы сможете найти ошибку в своих рассуждениях или найти ответ на свой вопрос" 🐣
Выкидываем из этого уравнения уточку и тащим своего друга, девушку, бабушку или семейного врача (если у вас есть такой, я вам завидую), садим перед собой и пытаемся на простых примерах объяснить сложные вещи.
Ведь "Если вы учёный, квантовый физик, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан." 🔮
Как объяснять: начните со слов, которые точно известны человеку.
Например, что такое переменная? Это коробка, в которой лежит какое-то число или символ, или что-то другое. Что такое массив? Ну это несколько таких коробок, которые мы положили на конвейер и дали ему какое-то название. Так мы можем легко найти нужную коробку.
Именно рассказывая другим людям о том, что вы учите, вы сможете усвоить материал. Ведь вам надо не просто "прочитать и забыть", а как бы "отчитаться" перед другим человеком.
Не забудьте о вопросах из зала ⚠️
Позже переключайтесь с бабушек и друзей на людей, которые находятся на одной ступени изучения темы\предмета\языка программирования с вами, их тяжелее обмануть)
Созванивайтесь вместе и пытайтесь друг-другу помочь с домашней работой (если вы проходите один курс) или за кофе объясните уже коллеге, почему не нужно сливать сырые изменения в мастер. Может быть, вы и сами чего-то нового узнаете от себя или про себя👩🎓
Думаю, что многие видели картинку, прикрепленную к посту. Многие даже задавались вопросом: "Как же эти знания применить, чтобы действительно понять что-то? Я все понял, но как сажусь делать - ступор"
Тут нам поможет немного усовершенствованный "метод Уточки", напомню вам его:
"Если вы не знаете, как решить какую-то проблему, расскажите о ней утенку, вряд ли он что-то поймет, но благодаря этому вы сможете найти ошибку в своих рассуждениях или найти ответ на свой вопрос" 🐣
Выкидываем из этого уравнения уточку и тащим своего друга, девушку, бабушку или семейного врача (если у вас есть такой, я вам завидую), садим перед собой и пытаемся на простых примерах объяснить сложные вещи.
Ведь "Если вы учёный, квантовый физик, и не можете в двух словах объяснить пятилетнему ребёнку, чем вы занимаетесь, — вы шарлатан." 🔮
Как объяснять: начните со слов, которые точно известны человеку.
Например, что такое переменная? Это коробка, в которой лежит какое-то число или символ, или что-то другое. Что такое массив? Ну это несколько таких коробок, которые мы положили на конвейер и дали ему какое-то название. Так мы можем легко найти нужную коробку.
Именно рассказывая другим людям о том, что вы учите, вы сможете усвоить материал. Ведь вам надо не просто "прочитать и забыть", а как бы "отчитаться" перед другим человеком.
Не забудьте о вопросах из зала ⚠️
Позже переключайтесь с бабушек и друзей на людей, которые находятся на одной ступени изучения темы\предмета\языка программирования с вами, их тяжелее обмануть)
Созванивайтесь вместе и пытайтесь друг-другу помочь с домашней работой (если вы проходите один курс) или за кофе объясните уже коллеге, почему не нужно сливать сырые изменения в мастер. Может быть, вы и сами чего-то нового узнаете от себя или про себя👩🎓
👍9
#ЯПрочитал #junior #middle 👩🎓
Я не самый большой фанат книг, за что частенько ругаю себя, но есть книги, с которыми стоило бы ознакомиться каждому.
Я думаю, что вы и без меня сможете найти "Топ-10 книг для разработчика", но есть и менее популярные, но достойные книги 👀
Задумывались ли вы о том, как вас видит руководитель? Доволен ли он вашей работой или ищет вам замену? Что можно улучшить в работе с точки зрения вашего менеджера или лида?
Если вы хоть раз задавались подобными вопросами, то "Мама, я Тимлид" Марины Перескоковой - отличный книга не несколько вечеров
Автор презентует эту книгу, как некоторый гайд для руководителей-новичков, но мы рассмотрим ее немного с другого ракурса. На самом деле в книге описан собирательный образ идеального босса. Того, который может выслушать, понять сотрудника, а еще он просто душка 🥰
В жизни всё не так, нет идеальных руководителей, как и нет идеальных работников. Но именно этот "идеальный" взгляд "идеального" босса позволит стать чуть ближе к тому, чтобы выглядеть в глазах нашего (любимого, но не идеального начальника) лучше.
Из книги вы знаете не только о том, как вам общаться и строить отношения с вашим менеджером, но и о том, насколько ваш босс близок к "Идеалу по Перескоковой".
Из минусов книги выделю, наверное, слишком базовые советы для уже опытных руководителей, так что если в вашем штате есть уже парочку человек и вы закрыли уже не один горящий дедлайн - книга будет полезна не больше, чем "Java для чайников".
Всем остальным - крайне рекомендую
Я не самый большой фанат книг, за что частенько ругаю себя, но есть книги, с которыми стоило бы ознакомиться каждому.
Я думаю, что вы и без меня сможете найти "Топ-10 книг для разработчика", но есть и менее популярные, но достойные книги 👀
Задумывались ли вы о том, как вас видит руководитель? Доволен ли он вашей работой или ищет вам замену? Что можно улучшить в работе с точки зрения вашего менеджера или лида?
Если вы хоть раз задавались подобными вопросами, то "Мама, я Тимлид" Марины Перескоковой - отличный книга не несколько вечеров
Автор презентует эту книгу, как некоторый гайд для руководителей-новичков, но мы рассмотрим ее немного с другого ракурса. На самом деле в книге описан собирательный образ идеального босса. Того, который может выслушать, понять сотрудника, а еще он просто душка 🥰
В жизни всё не так, нет идеальных руководителей, как и нет идеальных работников. Но именно этот "идеальный" взгляд "идеального" босса позволит стать чуть ближе к тому, чтобы выглядеть в глазах нашего (любимого, но не идеального начальника) лучше.
Из книги вы знаете не только о том, как вам общаться и строить отношения с вашим менеджером, но и о том, насколько ваш босс близок к "Идеалу по Перескоковой".
Из минусов книги выделю, наверное, слишком базовые советы для уже опытных руководителей, так что если в вашем штате есть уже парочку человек и вы закрыли уже не один горящий дедлайн - книга будет полезна не больше, чем "Java для чайников".
Всем остальным - крайне рекомендую
👍3🔥2
#junior #middle #senior #Поговорим
Сегодня поговорим с вами об ещё одной чисто soft-skill теме.
Синдром самозванца. Кому то могло стать плохо уже только от названия, кто-то сразу вспомнил себя, а кто-то просто слышал, но никогда не сталкивался с ним лицом к лицу🙈
Если коротко, то "синдром самозванца" - когнитивное искажение, при котором человек полностью убежден, что он: слабое звено команды, случайно попал в эту компанию, не способен быть полезным, глупее других и так далее (нужное подчеркнуть)
Если в других профессиях эта проблема имеет локальный характер, то для программистов - это настоящий бич 🥲
Так, по исследованиям Хабр, более 97% программистов сталкивались с синдромом хотя бы раз в жизни. По данным другого исследования, от 40 до 80 процентов разработчиков (в зависимости от компании) страдают этим синдромом.
Итак, все что мы можем делать с этим синдромом - бороться с ним.
А как?
1. Первое, что нужно сделать - распознать, что вы подвержены этому синдрому. Если вы часто говорите: "мне повезло", "да там ничего сложного" или думаете о том, что вы не достойны того, что имеете, значит, вы в списке "самозванцев". Располагайтесь, налью вам кофе)
2. Поговорите об этом со своими коллегами, начните с тех, кому вы доверяете. Вы даже можете создать анонимный опросник и скинуть его в общий чат 💼
3. Сходите уже, наконец, к психологу. Это не какой-то страшный мозгоправ из фильмов ужасов. Психолог - это фитнес-тренер, только для мозга ⭐️
4. Помните о том, что когда вы сравнивание себя с кем-то вы, скорее всего, совершаете две ошибки:
4.1. Вы сравниваете себя не с одним человеком, а как бы объединяете все знания людей вокруг вас в один большой ком. А после пытаетесь сравнить этот ком из десятков судеб с вашей жизнью. Картинка будет прикреплена к посту.
4.2 Вы совсем не учитываете, что сеньор, сидящий справа от вас, 6 лет назад был таким же, как и вы. И совсем не учитываете, что через 6 лет (а может даже раньше) вы будете тем самым сеньором. Сейчас у вас нет такого опыта, как у него.
И ЭТО НОРМАЛЬНО! Не сравнивайте свое начало пути с чьей-то серединой.
Не болейте 🌧
Сегодня поговорим с вами об ещё одной чисто soft-skill теме.
Синдром самозванца. Кому то могло стать плохо уже только от названия, кто-то сразу вспомнил себя, а кто-то просто слышал, но никогда не сталкивался с ним лицом к лицу🙈
Если коротко, то "синдром самозванца" - когнитивное искажение, при котором человек полностью убежден, что он: слабое звено команды, случайно попал в эту компанию, не способен быть полезным, глупее других и так далее (нужное подчеркнуть)
Если в других профессиях эта проблема имеет локальный характер, то для программистов - это настоящий бич 🥲
Так, по исследованиям Хабр, более 97% программистов сталкивались с синдромом хотя бы раз в жизни. По данным другого исследования, от 40 до 80 процентов разработчиков (в зависимости от компании) страдают этим синдромом.
Итак, все что мы можем делать с этим синдромом - бороться с ним.
А как?
1. Первое, что нужно сделать - распознать, что вы подвержены этому синдрому. Если вы часто говорите: "мне повезло", "да там ничего сложного" или думаете о том, что вы не достойны того, что имеете, значит, вы в списке "самозванцев". Располагайтесь, налью вам кофе)
2. Поговорите об этом со своими коллегами, начните с тех, кому вы доверяете. Вы даже можете создать анонимный опросник и скинуть его в общий чат 💼
3. Сходите уже, наконец, к психологу. Это не какой-то страшный мозгоправ из фильмов ужасов. Психолог - это фитнес-тренер, только для мозга ⭐️
4. Помните о том, что когда вы сравнивание себя с кем-то вы, скорее всего, совершаете две ошибки:
4.1. Вы сравниваете себя не с одним человеком, а как бы объединяете все знания людей вокруг вас в один большой ком. А после пытаетесь сравнить этот ком из десятков судеб с вашей жизнью. Картинка будет прикреплена к посту.
4.2 Вы совсем не учитываете, что сеньор, сидящий справа от вас, 6 лет назад был таким же, как и вы. И совсем не учитываете, что через 6 лет (а может даже раньше) вы будете тем самым сеньором. Сейчас у вас нет такого опыта, как у него.
И ЭТО НОРМАЛЬНО! Не сравнивайте свое начало пути с чьей-то серединой.
Не болейте 🌧
👍8🔥4