Сравнение программистов со столярами, конечно, не в кассу совершенно, как и любое отвлечённое сравнение вместо доводов по существу. Но дело даже не в том, что опытный разработчик осилит или не осилит новую для себя технологию или фреймворк. Есть более серьёзная проблема — сможет ли разработчик привнести свой опыт из другого языка или стека и обогатить код и процесс новыми идеями, или наоборот, притащит что-то ненужное взамен общепринятых практик, с которыми не сможет или не захочет разобраться. Или и того хуже, будет ныть, что тут всё плохо, а вот в его-то любимом фреймворке не так, и вообще надо всё переписать. В таком случае мы получим не просто плохо работающего, а ещё и демотивированного сотрудника. И это, к сожалению, в большей степени человеческий фактор, это такая особенность характера, которую не выправить ни за 3, ни за 10 лет разработки.

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

И да, извините, но глаз резануло — нет в русском языке слова «найм».

В русском переводе «полностью» звучит так, будто нужно вообще выкинуть Java и переписать всё на Kotlin. Слово «totally», особенно в выражении «you should totally...», чаще всего означает «определённо», «обязательно», а вовсе не «полностью».

А чем вам не угодил стандартный механизм пессимистичных блокировок?

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

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

Я считаю, что можно и знать теорию, и иметь хороший практический опыт. Отсутствие первого или второго — это вполне ликвидируемый недостаток. Поэтому я решительно не понимаю, когда незнание теории едва ли не с гордостью выдают за достоинство.

Эта треш-статья не стоила перевода.
Особенно забавный пример с «хрупким классом». Автор добавляет в подклассе состояние (поле count), которое по его задумке должно быть консистентно с внутренним состоянием суперкласса (число элементов в нижележащем ArrayList), и при этом почему-то полагает, что ему не нужно вникать в детали устройства суперкласса.

Да, в Slick нельзя так сделать, потому что Slick — это не ORM. Он значительно ближе к реляционной модели, чем ORM. Slick не отображает внешние ключи в ассоциации, для него один кейс-класс — это одна таблица.

С маппингом ассоциаций сразу возникает целая вереница типичных проблем ORM, с которыми они справляются с весьма неоднозначными результатами, типа навигации по графу объектов, «N+1 select problem», eager/lazy fetches и т.д. В отличие от ORM, Slick даёт больше прозрачности в том, когда и какие запросы он выполняет.

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

Интересно, посмотрю на неё. Спасибо!

Спасибо! Иллюстратор — Марья Габышева.
А сайт в настоящий момент переживает редизайн :)

Да, я именно про эту ситуацию и говорю. Когда вы прописываете версию библиотеки в dependencyManagement, она перекрывает все остальные определения этой библиотеки из всех зависимостей в дереве, включая сторонние.

Если разные версии одной библиотеки тянутся различными транзитивными зависимостями, то часто удобнее бывает один раз прописать версию этой библиотеки в секции dependencyManagement в корневом pom, чем расставлять везде exclude.

Да, в этом мощь абстракции Slick, можно якобы вообще забыть про SQL и представлять, будто этот код выполняется прямо на базе данных. Но это ровно до первой ошибки :) Причём в случае со Slick это будет ошибка компиляции, в содержание которой очень сложно вникнуть, если не понимаешь того, как именно этот код преобразуется в SQL.

Ну зря вы так :) Для того я и написал эту статью, чтобы поделиться опытом и помочь другим разобраться.

В том-то и дело, что for используется не для итерации по строчкам базы данных, а для композиции метаданных, т.е. классов, описывающих таблицы. На момент формирования запроса мы ещё не обращаемся к базе, а только лишь формируем SQL-строку.

Спасибо! Отметил.
Действительно, асинхронные интерфейсы требуют тектонических сдвигов в голове.

В разделе про Henshin не сразу сообразил, как нарисовать диаграмму :) Может, я что-то пропустил, но раздела «ecore» в палитре инструментов у меня не оказалось. Как выяснилось, надо щёлкнуть правой кнопкой в поле диаграммы, выбрать Import Package -> From Registry и в появившемся окне импортировать пакет http://www.eclipse.org/emf/2002/Ecore, чтобы этот раздел появился. Либо то же самое можно было сделать на последнем шаге создания диаграммы.

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

Я не люблю не Microsoft, а маркетинговый буллшит. Когда вместо того, чтобы просто написать «мы повышаем цены», придумывают какую-то ерунду в духе «мы рады предоставить возможность». Возникает смутное чувство, что тебя считают идиотом, а для утверждения этого статуса держат специальный штат PR-менеджеров.

Партнёрское письмо о «коррекции» цен начинается с редкостного маркетингового буллшита:

Компания Microsoft регулярно обновляет портфель продуктов, снабжая их расширенным функционалом, отвечающим потребностям бизнеса. Мы рады представить вам возможность предложить заказчиками продукты Microsoft и обновить с ними лицензионные соглашения по текущим ценам до 1 января 2016 года.

Рады они.

Спасибо за статью. Ещё, когда тип пишется справа, для меня это удачно укладывается в математическое представление типа как множества принадлежащих ему объектов.

var x int // x принадлежит множеству целых чисел
var p *int // p принадлежит множеству указателей на объекты, принадлежащие множеству целых чисел
var a [3]int // a принадлежит множеству трёхэлементных массивов объектов, принадлежащих множеству целых чисел

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