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

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

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

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

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

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

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

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

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

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

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

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

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