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

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

Я считаю, что можно и знать теорию, и иметь хороший практический опыт. Отсутствие первого или второго — это вполне ликвидируемый недостаток. Поэтому я решительно не понимаю, когда незнание теории едва ли не с гордостью выдают за достоинство.
forketyfork
+22
Эта треш-статья не стоила перевода.
Особенно забавный пример с «хрупким классом». Автор добавляет в подклассе состояние (поле count), которое по его задумке должно быть консистентно с внутренним состоянием суперкласса (число элементов в нижележащем ArrayList), и при этом почему-то полагает, что ему не нужно вникать в детали устройства суперкласса.
forketyfork
0
Да, в Slick нельзя так сделать, потому что Slick — это не ORM. Он значительно ближе к реляционной модели, чем ORM. Slick не отображает внешние ключи в ассоциации, для него один кейс-класс — это одна таблица.

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

В этой главе документации как раз объясняется модель Slick, и как можно мапить объекты со связями в составные кейс-классы, если очень хочется.
forketyfork
0
Интересно, посмотрю на неё. Спасибо!
forketyfork
+1
Спасибо! Иллюстратор — Марья Габышева.
А сайт в настоящий момент переживает редизайн :)
forketyfork
0
Да, я именно про эту ситуацию и говорю. Когда вы прописываете версию библиотеки в dependencyManagement, она перекрывает все остальные определения этой библиотеки из всех зависимостей в дереве, включая сторонние.
forketyfork
+1
Если разные версии одной библиотеки тянутся различными транзитивными зависимостями, то часто удобнее бывает один раз прописать версию этой библиотеки в секции dependencyManagement в корневом pom, чем расставлять везде exclude.
forketyfork
0
Да, в этом мощь абстракции Slick, можно якобы вообще забыть про SQL и представлять, будто этот код выполняется прямо на базе данных. Но это ровно до первой ошибки :) Причём в случае со Slick это будет ошибка компиляции, в содержание которой очень сложно вникнуть, если не понимаешь того, как именно этот код преобразуется в SQL.
forketyfork
0
Ну зря вы так :) Для того я и написал эту статью, чтобы поделиться опытом и помочь другим разобраться.
forketyfork
0
В том-то и дело, что for используется не для итерации по строчкам базы данных, а для композиции метаданных, т.е. классов, описывающих таблицы. На момент формирования запроса мы ещё не обращаемся к базе, а только лишь формируем SQL-строку.
forketyfork
+1
Спасибо! Отметил.
Действительно, асинхронные интерфейсы требуют тектонических сдвигов в голове.
forketyfork
0
В разделе про Henshin не сразу сообразил, как нарисовать диаграмму :) Может, я что-то пропустил, но раздела «ecore» в палитре инструментов у меня не оказалось. Как выяснилось, надо щёлкнуть правой кнопкой в поле диаграммы, выбрать Import Package -> From Registry и в появившемся окне импортировать пакет http://www.eclipse.org/emf/2002/Ecore, чтобы этот раздел появился. Либо то же самое можно было сделать на последнем шаге создания диаграммы.
forketyfork
0
Если так, то я глубоко сочувствую этим людям, но от этого не перестаю ощущать, что меня держат за идиота.
forketyfork
0
Я не люблю не Microsoft, а маркетинговый буллшит. Когда вместо того, чтобы просто написать «мы повышаем цены», придумывают какую-то ерунду в духе «мы рады предоставить возможность». Возникает смутное чувство, что тебя считают идиотом, а для утверждения этого статуса держат специальный штат PR-менеджеров.
forketyfork
+4
Партнёрское письмо о «коррекции» цен начинается с редкостного маркетингового буллшита:
Компания Microsoft регулярно обновляет портфель продуктов, снабжая их расширенным функционалом, отвечающим потребностям бизнеса. Мы рады представить вам возможность предложить заказчиками продукты Microsoft и обновить с ними лицензионные соглашения по текущим ценам до 1 января 2016 года.

Рады они.
forketyfork
+1
Спасибо за статью. Ещё, когда тип пишется справа, для меня это удачно укладывается в математическое представление типа как множества принадлежащих ему объектов.
var x int // x принадлежит множеству целых чисел
var p *int // p принадлежит множеству указателей на объекты, принадлежащие множеству целых чисел
var a [3]int // a принадлежит множеству трёхэлементных массивов объектов, принадлежащих множеству целых чисел

forketyfork
0
Безусловно. Любая нормальная задача на собеседовании — это не какой-то однозначный вопрос, требующий правильного ответа, а приглашение к диалогу, в ходе которого человек может очень много всего рассказать, в том числе и по поводу того, в каких именно случаях правильнее забивать шурупы молотком. И чем больше человек скажет на эту тему умных мыслей, различных юзкейсов, случаев из практики, тем больше у него шанс произвести хорошее впечатление.
forketyfork
+1
Отличный пример. Вот я предпочту взять тех немногих, кто выкинет молоток и попросит шуруповёрт.
forketyfork
+1
Да, сам по себе ответ «отсортирую и возьму первый элемент» ещё ничего не значит. Самое интересное начинается тогда, когда интервьюер задаёт вопрос «а можно быстрее?»
forketyfork
–2
У человека есть контекст в виде процедурного языка программирования общего назначения, в котором есть циклы, присваивания и операторы сравнения. Этого достаточно, чтобы решить задачу в один проход.
forketyfork
0
В статье речь идёт не об отсутствии технического собеседования, а о той ситуации, когда кандидата готовы принять без технического собеседования. Как я понимаю, оффер вам не делали, так что это не ваш случай. Рассказать своими словами о рабочем опыте — вполне нормальная просьба интервьюера, даже если всё подробно расписано в резюме, ведь на работу принимают не резюме, а живого человека.

«Выгнал» — сильное слово, это в моём понимании когда вам говорят «пшёл вон, свободен». Не могу себе представить что-то подобное из уст моих коллег. По окончании собеседования никто вам не скажет «вы нам не подходите, потому что...» — обычно интервьюер просто заканчивает собеседование тогда, когда считает нужным, и по его результатам составляет внутренний отзыв, который, естественно, никто и нигде вам не предоставит. При наличии положительного отзыва вам могут сделать оффер. Это абсолютно нормальная процедура проведения собеседования.
forketyfork
–1
Я не смеялся над вашим резюме, как раз наоборот, отметил, что спектр указанных там умений достаточно широкий, его сложно подогнать под какой-то ограниченный набор вакансий, и такие ошибки неизбежны. С таким резюме вам неизбежно придётся самостоятельно отсеивать все поступающие предложения, не надеясь на то, что резюме правильно истолкуют HRы, чтобы не погрязнуть в бесконечных собеседованиях на самые разнообразные вакансии.
forketyfork
0
Нет, это был не я. Думаю, меня при желании можно опознать по аватарке: о)
Если HR не сообщил вам, на какую вакансию вас приглашают, это, конечно, не очень хорошо с его стороны. Но вообще совет лично от меня как от человека, много походившего по собеседованиям — следует помнить, что HRы далеко не всегда разбираются в тонкостях технологий и ориентируются в основном по ключевым словам в резюме. Нет смысла судить их за это, они не технические специалисты. Поэтому лучше не идти на собеседование вслепую, а всё же самостоятельно уточнять такие вещи, как вакансия и список требований, заранее. Не стоит надеяться на то, что ваше резюме правильно соотнесли с вакансией и догадались, какую именно должность вы ищете, особенно если в резюме написано «всё умею, всё могу»: о)
forketyfork
–1
Мне очень жаль, если у вас остались плохие впечатления о нашем собеседовании. У нас достаточно большая компания, много подразделений, куда набор идёт по совершенно разным критериям. Я отвечаю лишь за набор людей в свои команды, поэтому не в курсе всех происходящих интервью. На какую именно вакансию вас пригласили, и чем обидели?
forketyfork
0
Да, там ошибка, не проверил перед отправкой. Хотел только показать идею.
forketyfork
+1
Я же расшифровал, какая именно часть ответственности приходится на подчинённого, а какая — на начальника. Начальник отвечает за принятое решение перед своим начальством. Подчинённый же отвечает за реализацию идеи перед самим начальником.

Иначе говоря, нормальный начальник никогда не «сдаст» подчинённого своему собственному начальству в духе «у нас не заработало, потому что имярек такой-сякой придумал хреновую идею» — потому что он сам принял решение и все шишки заранее взял на себя. Но при этом никто не снимает с подчинённого ответственность за эту идею перед его начальником и перед коллегами (в том числе и будущими разработчиками на проекте), которым тоже придётся с этой идеей потом жить.
forketyfork
–1
Если под «фронтэндом» вы понимаете «программирование браузера», то пожалуй, хотя даже там это важно. Например, чтобы не городить велосипедный транспорт поверх HTTP/REST там, где можно перейти на более низкий уровень, или чтобы понимать, как работает TLS и сертификаты. А если рассматривать понятие «фронтэнд» как разработку клиентского ПО вообще, то там такое понимание незаменимо.

По-хорошему, любой разработчик приложений, которые что-то передают/принимают по сети, должен хотя бы примерно представлять себе, как происходит весь процесс передачи данных на всех уровнях, и к кому бежать, если что-то пошло не так. Область ответственности быстро расширяется, когда что-то не работает, и человек не может не то что решить проблему, а даже диагностировать её, чтобы определить эту самую область ответственности.
forketyfork
0
Кроме технического аспекта «начинаний», есть ещё и аспект ответственности. С моей точки зрения, инициатива всегда приветствуется, но она наказуема. Это означает, что если человек принёс какую-то идею, то он за неё отвечает — т.е. помогает внедрять, подсказывает другим, собирает грабли, вовремя отслеживает, если идея не работает, и её надо пересмотреть и т.д.

Просто иногда случается такое, что человек приносит свою гениальную идею, а потом, когда она не работает, отходит в сторону со словами «мучайтесь сами, это не идея была плохая, это ваша задача отстой». Отвечать за криво реализованную идею приходится как раз начальнику. Поэтому начальник может не принимать идеи подчинённых не по причине того, что он самодур и считает себя умнее всех, а потому что он понимает, что отвечать за эту идею потом ему.
forketyfork
+2
При чём тут нанооптимизации? Я привёл совершенно типовую реализацию задачи на стандартном SQL, в котором LIMIT отсутствует.
forketyfork
0
Если бы мне такую аргументацию привели, это было бы человеку только в плюс. К сожалению, зачастую соискатель вообще не знает, что такое сложность и как её оценить.
forketyfork
+1
Не очень понимаю, откуда ваша формула. Если вы сначала сортируете массив, а потом берёте первый элемент, то на сортировку у вас уходит (в типовой реализации сортировки в стандартных библиотеках) как раз O(ln(n)*n), а потом константное время чтобы взять первый или последний элемент по индексу.
forketyfork
–1
Естественно, универсальных способов построения команды нет. Для кого-то нормальный начальник («нему*ак» в ваших терминах) — это тот, с которым можно потрындеть про шутки на тему ООП и паттернов, а для кого-то — тот, кто всё под контролем держит и умеет нормально работу команды организовать. Далеко не всегда эти вещи совпадают.
forketyfork
–2
Ну а это уже было бы из области провокаций, я мог бы добавить это шестым пунктом в «как отпугнуть соискателя». Я бы указал на ошибку, но спорить не стал бы. Если из этого следует какой-то вывод о моих личных качествах, то он, скорее всего, будет неверным.
forketyfork
–7
Для этого на собеседованиях, как правило, есть специальные задачи. Например, спроектируйте какую-нибудь архитектуру кода или системы. А почему вы так сделали? А как вы учли это? А почему выбран не этот, а тот вариант? Вот это хороший повод для того, чтобы проявить умение убеждать и аргументировать. А вот «вы не правы» — типичное самоутверждение.
forketyfork
–4
Нет, на практике всегда можно выкрутиться родным диалектом SQL, спору нет, но даже в вашей конструкции есть некоторая неинтуитивность. ORDER это всё-таки глагол, и мне надо очень постараться, чтобы увидеть в этой конструкции декларативное описание того, что я на самом деле хотел получить.
forketyfork
–3
Согласен, это важное умение, но есть целый спектр между умением отстаивать свою точку зрения ради пользы общего дела и самоутверждением в виде попыток на каждом ровном месте доказывать окружающим, какой ты крутой. Едва ли собеседование — это адекватное место для первого. Чаще на собеседованиях проявляется что-то ближе ко второму.
forketyfork
0
Да, а в других базах есть ещё FIRST, LIMIT и т.д. Я говорил про стандартный SQL.
forketyfork
–1
Это зависит от стиля «доказательства», конечно, но в любом случае не забывайте, что вы принимаете на работу не сумму знаний, а живого человека, и работать он будет с живыми людьми.