Большая часть собеседующих спрашивали одно и тоже. Какие методы есть в классе Object. Что такое hashCode() и equalsTo? Collection Framework и т.д.
При этом на таком (чрезвычайно простом для собеседующего) этапе прекрасно отсеиваются все, кто на самом деле не знает базы. И не понимает. Включая и автора, кстати, которые либо не знает, либо не умеет формулировать свои мысли (и таки да, где он нашел у Object equalsTo - я вот не понимаю). Если ты не помнишь какие-то детали - это простительно, но если ты не понимаешь, как в твоем языке работает сравнение объектов - просто иди и еще поучи.
Нууу, я бы так сказал: на Optional, тот что из JRE, вообще плевать. Есть нормальные реализации, которые работают как надо (open source). То что Optional не умеет исключения - это наоборот, логично, и не должен. В общем, я эти соображения понял, но скажем для меня они не имеют особого смысла.
Нет, не так. Нет доказанных измерений ее эффективности. Вот вы же их тоже не привели, не заметили?
Т.е. типичная статья, агитирующая за применение TDD, выглядит как-то так: "А у меня получилось повысить эффективность при внедрении TDD". А я смотрю на это, и понимаю, что никаких выводов про свою работу и свой проект сделать не могу. Потому что те задачи, которые призвана решать методика TDD, я давно и достаточно успешно решаю другими способами, и мне не нужен тест, чтобы описать, что должен делать код - я это способен держать в голове. Ну или я сразу пишу кусок кода, который будет пользоваться другим куском кода - вместо теста.
Разумеется, я это не интерполирую на других, кому-то другому методика может быть помогает. Но я без измерений ее внедрять не буду. А измерять производительность программистов, так чтобы это измерение было применимо к другим программистам, другой квалификации, опыта и т.п., почти никто не умеет, потому что это тупо сложно.
Ну я думаю так и было. Это была история про ковид, вряд ли кого оставило равнодушным, так что сто человек, которые восприняли все лично, вполне себе набралось.
На первый взгляд, не вижу разницы с Try. Вам не удается представить ошибку HTTP протокола в виде Exception? А что мешает? Вы же все равно расширяете типы отказов классами.
Ну т.е. в самом примитивном варианте, чисто в качестве иллюстрации:
Так она с самого начала была понятна. Если работодатель не может обеспечить в офисе, чтобы работника не отвлекали - разве это проблемы работника? Кроме того, скажем разработчики все равно не могут одинаково эффективно работать все 8 часов, так что отвлекаться в какой-то степени может быть даже полезно.
а инженеры и премия - мои.
Ну и мои тоже. И обеспечить нормальный баланс - это вероятно и ваша задача. Или вы хотите сказать, что на удаленке у вас больше шансов повлиять на них так, чтобы они не отвлекались вовсе и были продуктивны?
Не, я понимаю, что это в конце концов прототип, и все такое. Просто вот эта проблема, которую я попытался озвучить - она самая сложно формализуемая. Причем с обоих сторон - и когда кандидат вакансии подбирает, и наоборот, когда HR подбирает кандидатов. Т.е. все навыки - они ко всему прочему еще и взаимосвязаны, и если у кандидата, условно, написано React, это в 99% случаев означает, что он таки знает javascript и html, но возможно не наоборот. Т.е. набор навыков зачастую можно расширить, включив подразумеваемые.
Ну вообще, когда-то были приличные планшеты от HP (сейчас в каталоге не вижу). И еще есть такой класс, как раскладушки, у которых клавиатуру можно сложить под экран, и пользоваться как планшетом (хотя ради объективности - они тяжелые). Был у меня HP, я был очень им доволен. Для определенного класса задач хорошо.
Подобную схему уже предлагали много раз. И она не работает по очень простой причине: ну вот у вас в примере резюме перечислены навыки, и например я там вижу два, SQL и SSH. Ну так вот, сколько времени нужно на то, чтобы изучить тему, именуемую SSH (что бы там автор резюме под этим не подразумевал)? Я бы сказал, что неделю максимум. Сколько времени нужно, чтобы глубоко изучить SQL? Ну допустим неделю минимум. А так можно годами повышать свою квалификацию.
Эти два ключевых слова несравнимы про уровню сложности и времени на освоение. А у вас в модели они одинаковые. И они всегда будут одинаковые, потому что ни автор вакансии, ни автор резюме неспособны сформулировать в циферках тот уровень, который у кандидата имеется, и который нанимающему требуется.
И ровно тоже самое можно сказать про все остальные ключевые слова, и вообще про все, что в резюме написано. Потому что автор резюме считает, что пару лет поработал с SQL, и достаточно опытен, а мне, как нанимающему, нужно знание трех разных СУБД, и достаточно глубокое, и я резонно считаю, что такой опыт можно получить минимум за 5-10 лет. И это не значит, что кандидат плох - просто у нас с ним разный взгляд на оценку его опыта и знаний, и для выравнивания всего этого как раз нужно интервью, т.е. беседа двух естественных интеллектов.
Ну ок, я доверяю своим кругам. В смысле, они мне не врут (хотя я бы не был так уверен относительно всех своих знакомых). Но я не знаю (и не смогу узнать простыми средствами), каков уровень компетенции у моих знакомых. Т.е. они не врут - но прекрасно могут добросовестно заблуждаться, рекомендуя мне какие-то источники.
Хабр прекрасный пример того, что совершенно пустые статьи зачастую набирают много плюсов. И даже более того - они реально могут быть полезны тем, кто ставит эти плюсы, но например не мне. Нужно ли мне доверять тем, кто поставил плюсы статье, если я не знаю их уровень подготовки? Их интересов? Ну и так далее.
Ну да. А даже если она занимает ключевое первое место - мы не сможем это доказать.
Ну т.е. применительно скажем к своей команде, где я всех знаю, причем многих давно - все люди разные, и приносимая ими польза тоже разная. И стимулы у всех разные тоже. Кому-то может быть интересно работать (и зарабатывать меньше), имея свободное время взамен.
Из чего следует, что все сотрудники должны получать равную зарплату? Даже если я готов всем платить как топам - у меня совершенно нет понимания, что это будет реально полезно.
С позицией-то может и понятно, но для корректности, чтобы утверждать что модель хорошо работает, нужно бы сравнить с другой компанией в таких же условиях, и понять, будет ли она более или менее эффективна. А такой компании у нас как водится, под рукой нет.
Да, вы совершенно правы. Просто мне приходится немного работать с аналогами, Streamgate и SIDEC, а про сам дебезиум я скорее теоретически знаю, и он более широко известен.
Ну я бы начал с того, что надо упомянуть, что скорее всего миграция это процесс с инкрементальной догрузкой. А дальше уже можно думать про инструменты.
Не, я совершенно не хочу сказать, что ваш критерий плох. Я просто намекаю, что он иногда ограничен.
Да и увеличивая количество воркеров мы снижаем время выполнения, оставляя количество страниц неизменным.
Мы можем даже увеличить число страниц, если воркеры на разных машинах, при этом условно, хадуп, с его репликацией, позволяет нам эти страницы прочитать несколько раз с разных дисков, т.е. каждый воркер прочитает для себя по разу. Ну т.е. по вашему критерию, мы увеличили число страниц втрое - ровно три реплики у нас есть у блока, при этом общее время выполнения запроса сократилось. Если мы ровно этого и хотели - то для нас увеличение числа прочитанных блоков само по себе ничего не значит. Ну т.е. я клоню к тому, что нужно скорее всего считать как ресурсы все что мы потратили (число ядер * время, память * время, и т.п.), и делить на это дело показатель качества, т.е. скажем время выполнения запроса. Т.е. мы время сократили вдвое, а ресурсов выжрали вчетверо... Я понимаю что это модель будет сильно сложнее вероятно.
Ну в общем, да, "где есть bash, обычно так же есть python (т.е. линукс)", особенно с учетом того, что у автора в заголовке уточнение, что речь про линукс.
Но есть нюанс. Скажем, у меня коллеги пишут на питоне всякое, ML либо ETL, и у них по сравнению со мной (а я пишу на java или scala) проблема простая - нужно установить зависимости. Мне это не требуется. Ну т.е. есть - голый питон и голый баш. Все что нужно для работы скрипта - далеко не всегда. И даже далеко не всегда это в типичном случае оформляется как зависимость - потому что баш не обязывает. Поэтому выбор в сложном случае - более "промышленный" язык, где можно сформулировать, что нам нужно, скачать это условным nuget-ом в вашем случае, или maven в моем, посмотреть версии зависимостей, посмотреть уязвимости в них, ну и так далее.
При этом на таком (чрезвычайно простом для собеседующего) этапе прекрасно отсеиваются все, кто на самом деле не знает базы. И не понимает. Включая и автора, кстати, которые либо не знает, либо не умеет формулировать свои мысли (и таки да, где он нашел у Object equalsTo - я вот не понимаю). Если ты не помнишь какие-то детали - это простительно, но если ты не понимаешь, как в твоем языке работает сравнение объектов - просто иди и еще поучи.
Нууу, я бы так сказал: на Optional, тот что из JRE, вообще плевать. Есть нормальные реализации, которые работают как надо (open source). То что Optional не умеет исключения - это наоборот, логично, и не должен. В общем, я эти соображения понял, но скажем для меня они не имеют особого смысла.
Нет, не так. Нет доказанных измерений ее эффективности. Вот вы же их тоже не привели, не заметили?
Т.е. типичная статья, агитирующая за применение TDD, выглядит как-то так: "А у меня получилось повысить эффективность при внедрении TDD". А я смотрю на это, и понимаю, что никаких выводов про свою работу и свой проект сделать не могу. Потому что те задачи, которые призвана решать методика TDD, я давно и достаточно успешно решаю другими способами, и мне не нужен тест, чтобы описать, что должен делать код - я это способен держать в голове. Ну или я сразу пишу кусок кода, который будет пользоваться другим куском кода - вместо теста.
Разумеется, я это не интерполирую на других, кому-то другому методика может быть помогает. Но я без измерений ее внедрять не буду. А измерять производительность программистов, так чтобы это измерение было применимо к другим программистам, другой квалификации, опыта и т.п., почти никто не умеет, потому что это тупо сложно.
Ну я думаю так и было. Это была история про ковид, вряд ли кого оставило равнодушным, так что сто человек, которые восприняли все лично, вполне себе набралось.
На первый взгляд, не вижу разницы с Try. Вам не удается представить ошибку HTTP протокола в виде Exception? А что мешает? Вы же все равно расширяете типы отказов классами.
Ну т.е. в самом примитивном варианте, чисто в качестве иллюстрации:
И что изменилось?
Так она с самого начала была понятна. Если работодатель не может обеспечить в офисе, чтобы работника не отвлекали - разве это проблемы работника? Кроме того, скажем разработчики все равно не могут одинаково эффективно работать все 8 часов, так что отвлекаться в какой-то степени может быть даже полезно.
Ну и мои тоже. И обеспечить нормальный баланс - это вероятно и ваша задача. Или вы хотите сказать, что на удаленке у вас больше шансов повлиять на них так, чтобы они не отвлекались вовсе и были продуктивны?
Ну я могу вспомнить одну такую историю, за много лет. Т.е. бывает - но очень редко.
Речь именно о библиотеках. Я не в курсе, почему. так, но на практике у нас никто не пакует. Все ставят зависимости статически.
На мой взгляд - ну очень частично. Просто масштабы разных навыков ну очень уж разные.
Не, я понимаю, что это в конце концов прототип, и все такое. Просто вот эта проблема, которую я попытался озвучить - она самая сложно формализуемая. Причем с обоих сторон - и когда кандидат вакансии подбирает, и наоборот, когда HR подбирает кандидатов. Т.е. все навыки - они ко всему прочему еще и взаимосвязаны, и если у кандидата, условно, написано React, это в 99% случаев означает, что он таки знает javascript и html, но возможно не наоборот. Т.е. набор навыков зачастую можно расширить, включив подразумеваемые.
Ну вообще, когда-то были приличные планшеты от HP (сейчас в каталоге не вижу). И еще есть такой класс, как раскладушки, у которых клавиатуру можно сложить под экран, и пользоваться как планшетом (хотя ради объективности - они тяжелые). Был у меня HP, я был очень им доволен. Для определенного класса задач хорошо.
Подобную схему уже предлагали много раз. И она не работает по очень простой причине: ну вот у вас в примере резюме перечислены навыки, и например я там вижу два, SQL и SSH. Ну так вот, сколько времени нужно на то, чтобы изучить тему, именуемую SSH (что бы там автор резюме под этим не подразумевал)? Я бы сказал, что неделю максимум. Сколько времени нужно, чтобы глубоко изучить SQL? Ну допустим неделю минимум. А так можно годами повышать свою квалификацию.
Эти два ключевых слова несравнимы про уровню сложности и времени на освоение. А у вас в модели они одинаковые. И они всегда будут одинаковые, потому что ни автор вакансии, ни автор резюме неспособны сформулировать в циферках тот уровень, который у кандидата имеется, и который нанимающему требуется.
И ровно тоже самое можно сказать про все остальные ключевые слова, и вообще про все, что в резюме написано. Потому что автор резюме считает, что пару лет поработал с SQL, и достаточно опытен, а мне, как нанимающему, нужно знание трех разных СУБД, и достаточно глубокое, и я резонно считаю, что такой опыт можно получить минимум за 5-10 лет. И это не значит, что кандидат плох - просто у нас с ним разный взгляд на оценку его опыта и знаний, и для выравнивания всего этого как раз нужно интервью, т.е. беседа двух естественных интеллектов.
Ну ок, я доверяю своим кругам. В смысле, они мне не врут (хотя я бы не был так уверен относительно всех своих знакомых). Но я не знаю (и не смогу узнать простыми средствами), каков уровень компетенции у моих знакомых. Т.е. они не врут - но прекрасно могут добросовестно заблуждаться, рекомендуя мне какие-то источники.
Хабр прекрасный пример того, что совершенно пустые статьи зачастую набирают много плюсов. И даже более того - они реально могут быть полезны тем, кто ставит эти плюсы, но например не мне. Нужно ли мне доверять тем, кто поставил плюсы статье, если я не знаю их уровень подготовки? Их интересов? Ну и так далее.
Ну да. А даже если она занимает ключевое первое место - мы не сможем это доказать.
Ну т.е. применительно скажем к своей команде, где я всех знаю, причем многих давно - все люди разные, и приносимая ими польза тоже разная. И стимулы у всех разные тоже. Кому-то может быть интересно работать (и зарабатывать меньше), имея свободное время взамен.
Из чего следует, что все сотрудники должны получать равную зарплату? Даже если я готов всем платить как топам - у меня совершенно нет понимания, что это будет реально полезно.
С позицией-то может и понятно, но для корректности, чтобы утверждать что модель хорошо работает, нужно бы сравнить с другой компанией в таких же условиях, и понять, будет ли она более или менее эффективна. А такой компании у нас как водится, под рукой нет.
Только не в этом случае. Я бы сказал что автор как раз из "этих", из вашей тайной организации.
Да, вы совершенно правы. Просто мне приходится немного работать с аналогами, Streamgate и SIDEC, а про сам дебезиум я скорее теоретически знаю, и он более широко известен.
Ну я бы начал с того, что надо упомянуть, что скорее всего миграция это процесс с инкрементальной догрузкой. А дальше уже можно думать про инструменты.
Не, я совершенно не хочу сказать, что ваш критерий плох. Я просто намекаю, что он иногда ограничен.
Мы можем даже увеличить число страниц, если воркеры на разных машинах, при этом условно, хадуп, с его репликацией, позволяет нам эти страницы прочитать несколько раз с разных дисков, т.е. каждый воркер прочитает для себя по разу. Ну т.е. по вашему критерию, мы увеличили число страниц втрое - ровно три реплики у нас есть у блока, при этом общее время выполнения запроса сократилось. Если мы ровно этого и хотели - то для нас увеличение числа прочитанных блоков само по себе ничего не значит. Ну т.е. я клоню к тому, что нужно скорее всего считать как ресурсы все что мы потратили (число ядер * время, память * время, и т.п.), и делить на это дело показатель качества, т.е. скажем время выполнения запроса. Т.е. мы время сократили вдвое, а ресурсов выжрали вчетверо... Я понимаю что это модель будет сильно сложнее вероятно.
Ну в общем, да, "где есть bash, обычно так же есть python (т.е. линукс)", особенно с учетом того, что у автора в заголовке уточнение, что речь про линукс.
Но есть нюанс. Скажем, у меня коллеги пишут на питоне всякое, ML либо ETL, и у них по сравнению со мной (а я пишу на java или scala) проблема простая - нужно установить зависимости. Мне это не требуется. Ну т.е. есть - голый питон и голый баш. Все что нужно для работы скрипта - далеко не всегда. И даже далеко не всегда это в типичном случае оформляется как зависимость - потому что баш не обязывает. Поэтому выбор в сложном случае - более "промышленный" язык, где можно сформулировать, что нам нужно, скачать это условным nuget-ом в вашем случае, или maven в моем, посмотреть версии зависимостей, посмотреть уязвимости в них, ну и так далее.