То же самое подумал при чтении. Всегда казалось что лучший руководитель это в первую очень хороший специалист - просто для того чтобы понимать процесс, которым он руководит.
Обилие фреймворков не упрощает жизнь программистов, а наоборот. Чтобы эффективно использовать весь зоопарк хотя бы одной экосистемы нужно знать довольно много. Реализовывать свои велосипеды всегда было и будет проще
Актуальных материалов про это мало, потому что сейчас это мало кому нужно - включая кэш второго уровня у вас пропадает возможность балансировать нагрузку (по крайней мере в лоб) между несколькими инстансами приложения, поскольку такие локальные кэши становятся несогласованными друг с другом. Есть у ehcache механизм репликации кэшей, но там свои минусы
Когда обсуждают «алгоритмы на собеседованиях» часто ставят знак равенства между пониманием принципов работы стандартных алгоритмов и структур данных (с оценкам сложностей) и вот такими вот «олимпиадными» задачками на сообразительность. Но это фундаментальные разные вещи. Можно отлично разбираться в стандартных алгоритмах и быть в курсе таких продвинутых техник как динамическое программирование, но когда в конкретной (как правило очень искусственной) задаче тебе в ограниченное время предлагается догадаться до «трюка» с которым ты не сталкивался — тут в принципе мало какие знания помогут
Сложные проекты на 80 процентов состоят из CRUD-а, поэтому хибернейт и jpa актуальны почти везде
То же самое подумал при чтении. Всегда казалось что лучший руководитель это в первую очень хороший специалист - просто для того чтобы понимать процесс, которым он руководит.
Обилие фреймворков не упрощает жизнь программистов, а наоборот. Чтобы эффективно использовать весь зоопарк хотя бы одной экосистемы нужно знать довольно много. Реализовывать свои велосипеды всегда было и будет проще
О чем не надо спрашивать на собеседовании - знают многие. О чем надо - никто не знает
Если вы смотрели этот сериал в дубляже стс, то вы смотрели другой сериал
Почему-то TDD всегда иллюстрируется на примерах, которые не имеют никакого отношения к реальной разработке
На втором вопросе любой уважающий себя соискатель закончит интервью
"Из восьми рабочих часов продуктивны только три" - отсюда напрашивается сокращение рабочего дня, а не уменьшение количества рабочих дней
Соглашусь с комментатором выше. Я бы предложил определить свой тип для паники и перехватывать в Catch только этот тип
Что происходит если в теле функции произошла паника, инициированная не через методы try?
Актуальных материалов про это мало, потому что сейчас это мало кому нужно - включая кэш второго уровня у вас пропадает возможность балансировать нагрузку (по крайней мере в лоб) между несколькими инстансами приложения, поскольку такие локальные кэши становятся несогласованными друг с другом. Есть у ehcache механизм репликации кэшей, но там свои минусы
Не совсем понял почему нельзя было сделать как GString в Groovy с неявным презованием строки шаблона в строку там где нет соответствующей перегрузки
Эти "советы' написаны теми, кому надо было продавать книгу
"А тут неявно проверяется тип" - вполне себе явно, синтаксис другой, неоднозначностей нет.
Специально сложно сконструированный кейс, где мы разбираем и Class, и Number. С if-ми где делается instanceof вы ещё больше запнетесь
Точно также и с локальными переменными в принципе. Чтобы понять как она связана с текущим контекстом, надо смотреть где и как она объявлена
Назначение лямбды обычно очевидно из её кода и из имени функции, в которую она передаётся
Так более того, в 17 джаве можно избавиться от явного каста после instanceof с объявлением переменной
Все что было после релиза java 8 - косметика
Ответ вообще говоря неверный, потому что в условии не сказано что в комнате только белые и чёрные люди
Учитывая целеустремленность автора, я не понимаю почему ему просто было не податься в разработчики и не искать работу на H1B
Когда обсуждают «алгоритмы на собеседованиях» часто ставят знак равенства между пониманием принципов работы стандартных алгоритмов и структур данных (с оценкам сложностей) и вот такими вот «олимпиадными» задачками на сообразительность. Но это фундаментальные разные вещи. Можно отлично разбираться в стандартных алгоритмах и быть в курсе таких продвинутых техник как динамическое программирование, но когда в конкретной (как правило очень искусственной) задаче тебе в ограниченное время предлагается догадаться до «трюка» с которым ты не сталкивался — тут в принципе мало какие знания помогут