Если вы внимательно прочитаете изначальное сообщение, то речь там идёт про рефакторинг.
У нас вот например рефакторинг это часть процесса разработки. Не особо большие рефакторинги делаются "по ходу дела", во время работы над задачей.
А так как задачи идут по плану, то крайне редко люди пересекаются во время рефакторинга.
Большой рефакторинг это отдельная задача, про которую все в команде вкурсе.
И которую видно в джире, с описанием того, что там будет изменяться.
Все просто и процесс прозрачен и понятен любому участнику.
Какое там пересекаться в изменениях кода
Возможно вы всегда работаете в проектах на миллионы строк и всегда пилите разные участки. В обычных же проектах пересечься очень просто.
Банальный пример. У вас задача добавить одно поле в модельку для какой-то бизнес функции. У вашего коллеги своя бизнес функция, но тоже надо добавить поле в модельку. И понеслась) это поле участвует в куче мест (печати, экспорты, выгрузки, валидации, подписи и т.д. и т.п.), и вот уже одним полем в модельке затронуто 100500 классов включая какие-то общие интерфейсы… Это так, на вскидку, в реале вариантов очень много)
И самый кайф — решаются проблемы с рефакторингом! Переименовали класс? — коммит и деплой. Переделали сигнатуру метода? — коммит и деплой.
И как это работает в команде из больше чем одного человека?
Ты "поменял и задеплоил" и я тоже самое, ну чуток под другому, поменял и задеплоил. Оба тратим время на одно и тоже. И самое главное, каждую минуту надо пулить код, а то мало ли кто-то уже это всё поправил и сделал… Или не тоже самое сделал, но код теперь в таком состоянии, что твой коммит теряет смысл. Или придётся тратить кучу времени на коммуникации "Посоны, не трогайте класс FooBoo, я его сейчас менять буду", отвлекая команду.
Опять же постоянные "ревью на 10 мин" просто не дадут тебе нормально работать над своей задачей. Когда тебе постоянно надо чужие ревью смотреть как сосредоточиться на совей задаче?
Читал много по этой теме, доклады видел, но абсолютно все примеры максимально примитивны. На примитивщине любой подход будет работать. А как это будет жить когда хотя бы 10, 15 разработчиков одновременно меняют код? А если проекту при этом еще не 100 лет и изменения не точечные для багфикса?
В общем не могу понять, как это в принципе может работать) Тут и в обычном режиме, в команде из 10 человек, рефакторинг частенько проблематично вести, приходится его планово делать, а уж в таком хаосе КПД должно падать просто катастрофически...
Да что-то незаметно, чтоб эффективность работы правоохранительных органов за последние 10 лет хоть сколько-то выросла.
А как вы это оценивали? Можете скинуть ссылочку или привести свои данные?
Но судя по этому высказыванию
Да эти люди настолько обнаглели, что уже не стесняются на лок-скрине прямо на электронные кошельки деньги за расшифровку просить!
Вы говорите про РФ. Ну так эти компании не для органов РФ собирают данные) Они даже не РФ компании.
Но что-то я не замечаю повышения эффективности контекстной рекламы.
Вот тут полностью согласен. Даже не надо собирать много данных, чтобы увидеть, как тебе подсовывают кучу рекламы товара после его покупки)
… потому что не приносит пользы никому вообще. Совсем никому.
А вот для таких заявлений неплохо бы уже пруфы прикладывать. Хоть какие-то.
Потому что тот факт, что вы лично не понимаете как используется эта информация, совершенно не говорит о том, что она бесполезна.
Так а при чём тут Dell или любой другой производитель win/linux ноутов?
Они не выпускают ни OS, ни железо, ни драйвера под них. Просто беруг готовые комплектующие и объединяют в одном компьютере. Так делают вообще все. Ну может только в apple есть свои железки хитрые, под которые они дрова сами делают.
Тут надо пинать Nvidia, что они за столько лет не сподобились ответсвенно подойти к выпуску дров под линух. Больше некого.
Ну и очень интересно какие именно пляски у вас были? )
На Dell 5590 встали с полпинка, да и в целом, последние несколько лет проприетарные блобы в убунту просто ставятся и всё. Бывают ошибки конечно в дровах, но редко. Единственная проблема, и то она косвенно связана с дровами, это тиринг, с двухмониторными системами так и нет гарантированного решения. Но это проблема больше xorg и его костылей.
Ну чем вам кнопки стрелок так не нравятся, что вы над ними постоянно издеваетесь?
Почему Dell не в состоянии сделать их нормального размера, это какой-то невероятный рокет сайнс для вас?
Это всё проблемы софта чисто на Windows. Под Linux никаких микролагов нет вообще. Да и многих других проблем описываемых разными людьми тоже нет. Ни со звуком, ни с сетью ни других каких бы то ни было.
Охлаждение да, не очень. Жаль что в компании над этим совсем не задумываются, лепят что придётся. Но за такую цену сменить термоинтерфейс, чтобы все встало в норму, может быть вполне приемлемым решением. Тут уже самому надо решать. В любом случае, на этом железе не видел ноутов одноклассников, которые не долбятся под 100 градусов с завода. Такое ощущение, что все производители хором забили на это дело — пипл хавает же.
Затем, что когда-то давно ездил на 2106 и мне было "вполне хватит", а потом поездил на более хорошей машине и 2106 стало уже "не очень".
Тоже самое и здесь, разница не только в скорости, но и в комфорте.
144 даже в обычной работе за компом заметно комфортнее.
Но конечно же будет толпа людей утверждающих, что и 60 хватает для всего)
Как и раньше была толпа утверждающая, что SSD нужен только серверам для скорости, а дома и на HDD хорошо. И т.д. и т.п.
144 hz нужно только заядлым геймерам или для тех кто играет в киберспортивные игры на победу. В остальном 60 hz вполне хватает.
Звучит как BMW и Mercedes нужны только заядлым гонщикам и тем кто на работу опаздывает, остальным хватит и ВАЗ 2106.
В общем это вот ваше "хватит", у всех разное. И многим хочется комфорта вне зависимости от профессии. Я вот ни разу не гонщик и даже не профессиональный водитель, но предпочту ездить на BMW, а не на ВАЗ-2106, которого (если судить по вашему) вполне хватит ездить на работу...
У камней от Intel нашли очередную уязвимость, завязанную на возможность изменения напряжения. Ну и так как уязвимость аппаратная, то решение, как всегда, одно — запретить изменять его на уровне BIOS. Как следствие производители, по рекомендации Intel, начали выпускать версии биоса с заблокированной возможностью изменения напряжения.
Если уж очень хочется, то используйте топовые термопасты от Thermal Grizzly и наслаждайтесь снижением температур на 5-10 градусов по Цельсию
Я вот использовал топовую пасту от Thermal Grizzly — получил через 2 месяца вот такую поверхность на чипах процессора и видеокарты. И не я один. Так что совет со звёздочкой)
(Паста точно оригинал, покупалась в крупной сети и проверялась)
P.S. Можете еще раскрыть подробности "секретной" технологии закрытия вентиляционных отверстий в некоторых моделях?
На некоторых ноутах вентиляционные отверстия, вокруг вентиляторов, оказались наглухо закрыты, что вызвало не мало пересудов в интернете)
Было бы очень интересно узнать, от представителя компании, зачем так сделали.
Если бы вы внимательно читали, что я написал, то могли увидеть, что я не решаю "правильно" ли решена тема проекта.
Мы же не бизнес развиваем, а техническое собеседование проводим)
И меня интересует в первую очередь техническое решение и его объяснение почему именно так сделано. Это тема для обсуждения решения, а не далеко идущие выводы по паре строк кода.
Когда разовьетесь как инженер, вам станет понятно, что единственного "правильного" решения просто не существует. Всё можно сделать разными способами. А собеседование на примере проекта это всего лишь способ пообсуждать эти решения, чтобы понять как человек мыслит и принимает решения.
Например затем, что глупо делать далеко идущие выводы по паре строчек кода)
Причины появления такого кода на гитхабе могут быть самыми разными.
Помечаю как вопрос перед подготовкой к собесу, а дальше уже от объяснения кандидата зависит.
В данном конкретном случае кандидат не понимал, что делает. Просто "так привык" и "всегда так делали", т.е. он банально не понимал, что этот код значит.
Но меня вполне устроило бы объяснение в духе: "А, лол, это копипаста, очевидная хрень написана, потому что… и объяснение что там написано и почему не имеет смысл так писать".
Говорить за всех — моветон.
Если кандидат в CV даёт ссылку на гитхаб, всегда смотрю что за проекты делает кандидат и в каких участвует.
Это просто кладезь для собеседования. Куча предметных вопросов, а почему ты тут вот так сделал, а здесь вот так, а как можно по другому это решить?
Не надо задавать тупых вопросов, ответы на которые в гугле пачками висят.
И не надо выдумывать нестандартные вопросы, они сами из кода проистекают)
Как пример что там можно найти)
В одном из недавних интервью, кандидат с несколькими годами опыта в Java + Spring дал ссылку на гитхаб, а там на сервисах висят одновременно 3 аннотации: Component, Service, Repository. Было забавно слушать фантазии на тему того как спринг обработает эту ситуацию)
P.S. Проблема только в том, что на пару-тройку десятков последних соискателей гитхаб был только у одного.
Очень часто слышу эту фразу.
Можете пояснить свою мысль, какая ответственность имеется ввиду?
В случае срыва проекта (по вине разработчиков, в данном случае, конечно же) команда разработки полным составом должна сделать харакири?
Часто владельцу бизнеса только это и остаётся в итоге, а вот вся команда просто встаёт и идёт к другому работодателю. Так что не очень понятно, что вы вкладываете в понятие этой самой ответственности.
Если вы внимательно прочитаете изначальное сообщение, то речь там идёт про рефакторинг.
У нас вот например рефакторинг это часть процесса разработки. Не особо большие рефакторинги делаются "по ходу дела", во время работы над задачей.
А так как задачи идут по плану, то крайне редко люди пересекаются во время рефакторинга.
Большой рефакторинг это отдельная задача, про которую все в команде вкурсе.
И которую видно в джире, с описанием того, что там будет изменяться.
Все просто и процесс прозрачен и понятен любому участнику.
Возможно вы всегда работаете в проектах на миллионы строк и всегда пилите разные участки. В обычных же проектах пересечься очень просто.
Банальный пример. У вас задача добавить одно поле в модельку для какой-то бизнес функции. У вашего коллеги своя бизнес функция, но тоже надо добавить поле в модельку. И понеслась) это поле участвует в куче мест (печати, экспорты, выгрузки, валидации, подписи и т.д. и т.п.), и вот уже одним полем в модельке затронуто 100500 классов включая какие-то общие интерфейсы… Это так, на вскидку, в реале вариантов очень много)
И как это работает в команде из больше чем одного человека?
Ты "поменял и задеплоил" и я тоже самое, ну чуток под другому, поменял и задеплоил. Оба тратим время на одно и тоже. И самое главное, каждую минуту надо пулить код, а то мало ли кто-то уже это всё поправил и сделал… Или не тоже самое сделал, но код теперь в таком состоянии, что твой коммит теряет смысл. Или придётся тратить кучу времени на коммуникации "Посоны, не трогайте класс FooBoo, я его сейчас менять буду", отвлекая команду.
Опять же постоянные "ревью на 10 мин" просто не дадут тебе нормально работать над своей задачей. Когда тебе постоянно надо чужие ревью смотреть как сосредоточиться на совей задаче?
Читал много по этой теме, доклады видел, но абсолютно все примеры максимально примитивны. На примитивщине любой подход будет работать. А как это будет жить когда хотя бы 10, 15 разработчиков одновременно меняют код? А если проекту при этом еще не 100 лет и изменения не точечные для багфикса?
В общем не могу понять, как это в принципе может работать) Тут и в обычном режиме, в команде из 10 человек, рефакторинг частенько проблематично вести, приходится его планово делать, а уж в таком хаосе КПД должно падать просто катастрофически...
Производительность говорите?
Тут человек выбирал систему под разработку по жестам на тачпаде… а вы про виртуалки какие-то, эклипсы))
А вот за эту ссылку благодарю. Занимательное чтиво)
А как вы это оценивали? Можете скинуть ссылочку или привести свои данные?
Но судя по этому высказыванию
Вы говорите про РФ. Ну так эти компании не для органов РФ собирают данные) Они даже не РФ компании.
Вот тут полностью согласен. Даже не надо собирать много данных, чтобы увидеть, как тебе подсовывают кучу рекламы товара после его покупки)
А вот для таких заявлений неплохо бы уже пруфы прикладывать. Хоть какие-то.
Потому что тот факт, что вы лично не понимаете как используется эта информация, совершенно не говорит о том, что она бесполезна.
Так а при чём тут Dell или любой другой производитель win/linux ноутов?
Они не выпускают ни OS, ни железо, ни драйвера под них. Просто беруг готовые комплектующие и объединяют в одном компьютере. Так делают вообще все. Ну может только в apple есть свои железки хитрые, под которые они дрова сами делают.
Тут надо пинать Nvidia, что они за столько лет не сподобились ответсвенно подойти к выпуску дров под линух. Больше некого.
Ну и очень интересно какие именно пляски у вас были? )
На Dell 5590 встали с полпинка, да и в целом, последние несколько лет проприетарные блобы в убунту просто ставятся и всё. Бывают ошибки конечно в дровах, но редко. Единственная проблема, и то она косвенно связана с дровами, это тиринг, с двухмониторными системами так и нет гарантированного решения. Но это проблема больше xorg и его костылей.
Ну чем вам кнопки стрелок так не нравятся, что вы над ними постоянно издеваетесь?
Почему Dell не в состоянии сделать их нормального размера, это какой-то невероятный рокет сайнс для вас?
Это всё проблемы софта чисто на Windows. Под Linux никаких микролагов нет вообще. Да и многих других проблем описываемых разными людьми тоже нет. Ни со звуком, ни с сетью ни других каких бы то ни было.
Охлаждение да, не очень. Жаль что в компании над этим совсем не задумываются, лепят что придётся. Но за такую цену сменить термоинтерфейс, чтобы все встало в норму, может быть вполне приемлемым решением. Тут уже самому надо решать. В любом случае, на этом железе не видел ноутов одноклассников, которые не долбятся под 100 градусов с завода. Такое ощущение, что все производители хором забили на это дело — пипл хавает же.
Очень глупо троилите.
Это просто пример.
Затем, что когда-то давно ездил на 2106 и мне было "вполне хватит", а потом поездил на более хорошей машине и 2106 стало уже "не очень".
Тоже самое и здесь, разница не только в скорости, но и в комфорте.
144 даже в обычной работе за компом заметно комфортнее.
Но конечно же будет толпа людей утверждающих, что и 60 хватает для всего)
Как и раньше была толпа утверждающая, что SSD нужен только серверам для скорости, а дома и на HDD хорошо. И т.д. и т.п.
Звучит как BMW и Mercedes нужны только заядлым гонщикам и тем кто на работу опаздывает, остальным хватит и ВАЗ 2106.
В общем это вот ваше "хватит", у всех разное. И многим хочется комфорта вне зависимости от профессии. Я вот ни разу не гонщик и даже не профессиональный водитель, но предпочту ездить на BMW, а не на ВАЗ-2106, которого (если судить по вашему) вполне хватит ездить на работу...
Как он мог заметить, что работает дольше, незамечая этого?
У камней от Intel нашли очередную уязвимость, завязанную на возможность изменения напряжения. Ну и так как уязвимость аппаратная, то решение, как всегда, одно — запретить изменять его на уровне BIOS. Как следствие производители, по рекомендации Intel, начали выпускать версии биоса с заблокированной возможностью изменения напряжения.
До этой пасты он был зеркальным, а после его поверхность как будто протравили чем-то. Появилась куча микро пятен и вот таких.
Я вот использовал топовую пасту от Thermal Grizzly — получил через 2 месяца вот такую поверхность на чипах процессора и видеокарты. И не я один. Так что совет со звёздочкой)
(Паста точно оригинал, покупалась в крупной сети и проверялась)
P.S. Можете еще раскрыть подробности "секретной" технологии закрытия вентиляционных отверстий в некоторых моделях?
На некоторых ноутах вентиляционные отверстия, вокруг вентиляторов, оказались наглухо закрыты, что вызвало не мало пересудов в интернете)
Было бы очень интересно узнать, от представителя компании, зачем так сделали.
Интересно, кто выдумывает такую дичь автор книги или автор заметки?
Если бы вы внимательно читали, что я написал, то могли увидеть, что я не решаю "правильно" ли решена тема проекта.
Мы же не бизнес развиваем, а техническое собеседование проводим)
И меня интересует в первую очередь техническое решение и его объяснение почему именно так сделано. Это тема для обсуждения решения, а не далеко идущие выводы по паре строк кода.
Когда разовьетесь как инженер, вам станет понятно, что единственного "правильного" решения просто не существует. Всё можно сделать разными способами. А собеседование на примере проекта это всего лишь способ пообсуждать эти решения, чтобы понять как человек мыслит и принимает решения.
Например затем, что глупо делать далеко идущие выводы по паре строчек кода)
Причины появления такого кода на гитхабе могут быть самыми разными.
Помечаю как вопрос перед подготовкой к собесу, а дальше уже от объяснения кандидата зависит.
В данном конкретном случае кандидат не понимал, что делает. Просто "так привык" и "всегда так делали", т.е. он банально не понимал, что этот код значит.
Но меня вполне устроило бы объяснение в духе: "А, лол, это копипаста, очевидная хрень написана, потому что… и объяснение что там написано и почему не имеет смысл так писать".
Говорить за всех — моветон.
Если кандидат в CV даёт ссылку на гитхаб, всегда смотрю что за проекты делает кандидат и в каких участвует.
Это просто кладезь для собеседования. Куча предметных вопросов, а почему ты тут вот так сделал, а здесь вот так, а как можно по другому это решить?
Не надо задавать тупых вопросов, ответы на которые в гугле пачками висят.
И не надо выдумывать нестандартные вопросы, они сами из кода проистекают)
Как пример что там можно найти)
В одном из недавних интервью, кандидат с несколькими годами опыта в Java + Spring дал ссылку на гитхаб, а там на сервисах висят одновременно 3 аннотации: Component, Service, Repository. Было забавно слушать фантазии на тему того как спринг обработает эту ситуацию)
P.S. Проблема только в том, что на пару-тройку десятков последних соискателей гитхаб был только у одного.
Очень часто слышу эту фразу.
Можете пояснить свою мысль, какая ответственность имеется ввиду?
В случае срыва проекта (по вине разработчиков, в данном случае, конечно же) команда разработки полным составом должна сделать харакири?
Часто владельцу бизнеса только это и остаётся в итоге, а вот вся команда просто встаёт и идёт к другому работодателю. Так что не очень понятно, что вы вкладываете в понятие этой самой ответственности.