Видео

Все просто. 1. Тесты все чаще становятся частью программирования. 2. Крупные компании постепенно уходят от отладки продуктов до "идеального" состояния. Это сильно тормозит разработку и тестирование ниш. Ну и автотесты - уже по сути программирование. Так что и о них речь.

В одной лодке сидим)

@@azimutjava про автотесты да, а что думаете насчет мануального?)

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

И помните! ИИ не защитит вас от медведя в лесу. И если медведь нападет - ИИ даст вам мудрый совет. Так что укрепляйте базовые навыки. Любопыство - один из них.

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

@@azimutjava А Как относитесь к Котлину? Используете ли его на продакшене в новых проектах вместо джавы?

Не приходилось. Отношусь спокойно. Если пригодится - переформатируюсь. Для своих поделок использовать не планирую. Сегодня)

Сейчас я честно говоря, больше переживаю за виденье проекта. Зверинец технологий огромен, но в результате важны - декомпозиция кода, разбитие на домены, тесты, swagger, гит и ci/cd. И быстрее выбрасывать мвп в доступ. Тогда можно спокойно развивать проект.

@@azimutjava Работа Лида : )

Эйджизм как он есть. Но есть мнение что 1С спецы общаются с бухгалтерами в основном и сейчас очень востребованны. Вроде как и не то ИТ что мы понимаем, но архинужное и важное. Так что думаю Жозе с легкостью бы освоил этот язык и обрел востребованность (будь в том необходимость).

Квартирный вопрос во всех мирах актуален)

Спойлерите))

1. Это уже я. 2. по документации спринг рекомендует объявлять бины как можно раньше, например в конфигурации. И если у вас замес из компонент и бинов - повод задуматься то ли вы делаете.

И пример циклической зависимости. Класс А (бин x) -> класс Б (бин y). Случится если вы в Б инжектите x, а в A инжектите y. А если вы используете бин только в своем классе - вы уверенны что вам нужен бин?

Блин устал править. Целый навык укладывать объяснение в комменты.

Проще сказать- граждане, держите бины в конфигурационных классах. Если это не так - то либо у вас что то крутое/старое, либо не правильное.

Спасибо за творчество! Кратко, емко и понятно

Ох! Как раз думаю наоборот. Книгу Егора Бугаенко предлагаю почитать) Элегантные объекты вроде. После неё голова переворачивается, интересна в прочтении)) И введение record в джава - говорит о том что валидация в конструкторе верный паттерн.

Глубина (количество элементов в ноде/бакете) тут ни причём. Здесь речь о распределении Node в массиве по горизонтали. После вычисления хеша - значение кладется в определнное место в массиве нод. Если это место занято - варианта 2: квадратичное хранение (в глубину баккета) или вторая хеш-функция!=0 для смещения. Поскольку в java нет никакой гарантии наличия второй хеш-функции - используется loadfactor чтобы смещать позицию и избегать коллизий.

Жозе Помар. Найдете его на канале @java

@@azimutjava спасибо вам, а то я подумал что он Джошуа Блох

И правда, похож.

Жозе Помар. Если вы не про меня спрашиваете) Жозе ведет интересные рубрики на канале @java в YT. Мне зашло как он доносит вещи, делюсь с вами.

@@azimutjava Спасибо за ответ. Это очень полезно 👍

Согласен. Да и фронт наверное не стоит описывать в ролике с беком.

Верно. Приватный конструктор в видео про immutable вроде рассматривался.

А про return в качестве гарантии - не встречал на практике, или не понял подход.

@@azimutjava сори видимо не так написал, своими словами. Есть допустим Класс кошки с 3 параметрами, int age, string name, bool isHomeless. В конструкторе проверяем параметр isHomeles, если true тогда this.isHomeless = issHomeless; return...В остальных случаях инициализируемся со всеми параметрами

@@mustFLEXboi Ох, я бы не стал. Очень зависит от последующих правок. Можно конечно. Кроме того вы вероятнее выйдете с null полями в дальнейшую работу, обрекая себя на дробоение логики по null. Но если мы просто говорим о возможностях конструктора то да, так можно.

@@azimutjava аааа ну да совсем забыл там придется костыли вставлять и как то миновать null придавая дефолтные значения полям типо 0, или "empty". Но все равно прикольно что так можно делать и только в специфических ситуациях

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

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

@@azimutjava 😁😁😁 щас бы прод уронить

Используется при сортировке объектов через коллекции/map. Плюс при в некоторых структурах на этапе добавления новых элементов через comporator идёт автоматическое упорядочивание элементов. Вообщем, штука нужная и не просто так появилась.

Наверное "непосредственно" - не совсем. Есть наследование ещё. Но в целом - да.

Да, так и есть. 1 бит под значение, остальное - под хедер оставлено

Да. На этапе компиляции (class), во время работы (runtime). Но не и там и там. Признаться сам думал что можно массив policy-видимости указать, но нет. Интересно даже - почему.

В одном из следующих роликов озвучено, да и в доках видел что конкатенация через плюс под капотом уже реализована через StringBuilder. Но и эта штука уже переоптиммзирована, поскольку String теперь не массив char, а массив byte.

proftrud.ru/box/52 - здесь вы можете тоже прочесть про char/byte

@@azimutjava уже посмотрел, спасибо