Казалось бы тогда автор бы так и написал, называть аллокации мусором не очень корректно, даже если через некоторое время они таковым станут (а может и не станут, если у вас какой-нибудь кэш) :) Но даже в этом случае (опять же речь про java) аллоцировать объекты это не так дорого, как может показаться - в большинстве коллекторов объекты создаются в специальной области (eden), в которой отсутствует фрагментация, объекты создаются просто последовательно занимая память, что само по себе довольно быстро. Проблемы начинаются тогда, когда eden заполнится и нужно будет его очистить, а для этого в свою очередь нужно пройтись по графу живых объектов и скопировать их в соседнюю область, очистив попутно eden. Это уже дольше и опять же зависит не от количества мусора, а от количества живых объектов. Единственное на что существенно влияет "мусор" - это скорость с которой заполняется eden, т.е. как часто нужно вызывать gc алгоритм и копировать живые объекты. Но и тут - если мы признали, что бОльшая часть объектов попадающих в eden на момент сборки будет мусором, то значит копировать потребуется не так много объектов и происходить это будет тоже недолго.
Не знаю, как обстоит дело в go, но в java, например, это не так. Если взять любой коллектор на основе поколений, ему все равно сколько у вас мертвых объектов, поскольку он обойдет граф по живым, скопирует их все в соседний пустой регион (survivor space 1,2), а дальше просто объявит исходный регион пустым. Если бы это так не работало, то создавать что-то в куче было бы дорого и все поголовно пользовались бы пулами даже для простых объектов. Так делают крайне редко именно потому, что короткоживущие объекты на gc почти не влияют
At least a year - красивый эвфемизм, который на бизнесовом значит - если не перейдете в течение года - ваши проблемы.
То, как вы делаете что-то - это ваше личное дело, вопрос о тех людях, которые делают по-другому, чем вы и кому было не просто комфортно, а до некоторой степени идеально работать в старом UI (почитайте отзывы), которые пользовались продуктом много лет, платив за это приличные деньги и на мнение которых компания попросту наплевала.
Старый UI выносится в плагин, который они через год перестанут поддерживать. Гамбургер - это не вкусовщина, а дополнительный клик, которого раньше не было.
У каждого "неудобства" свои в завимости о личного опыта использования, но в чём "старички" сходятся так это в том, что их опыт ухудшился в новом UI. "Лучшая" компания так со своей пользовательской базой, в особенности той, которая исправно оплачивает продукт на протяжении многих лет, не поступает.
Изменения в новом UI - это плевок в лицо старым пользователям компании, в JB это прекрасно сознают, существует масса тредов, где люди полемизировали с представителями JB по этой теме. Основная проблема нового интерфейса в том, что если ты использовал большое количество возможностей IDE(а чем дольше опыт использования, тем выше вероятность такого сценария), то новый интерфейса субъективно оставляет тебя "без рук" и в полном ступоре: привычные эффективные сценарии использования, нарабатывавшиеся годами, больше не работают, а их замена зачастую предполагает дополнительные действия, что выглядит в лучшем случае как нечто излишнее. Почему нельзя было делать переход плавно и постепенно меняя небольшие части ui по чуть чуть, как это делалось до этого остается загадкой. После такого демонстративного кидка, называть продукты JB лучшими у меня и других "старичков", с которыми я знаком, язык больше не поворачивается, простите.
Как классно было ездить на лошадях. Не было выхлопных газов, дтп было на порядок меньше, кучеры были воспеты огромным количеством произведений литературной классики, эстетика, приобщение к культуре, русская тройка... эх что мы потеряли. В общем нужно сделать город, в котором будем передвигаться только на лошадях... Без шуток я бы в таком пожил недельку-другую. Скорее всего это бы стоило чуть дороже средней поездки в отель на море :)
Один из простых способов объяснить факты приведенные в статье - несоизмеримо меньшие в сравнении с большими городами рекламные бюджеты в регионах по очевидной причине их меньшей рентабельности. У нас принято преуменьшать силу воздействия рекламы, ведь "я никогда не покупаю то, что показывают в телевизоре", однако ее наличие - это очень мощный информационный фон, который если и не влияет на вас непосредственно, то как-то затрагивает ваше окружение, а через него и вас. Считать ли рекламу двигателем прогресса каждый выбирает для себя сам.
Кажется автор тонко тролит, чтобы собрать побольше комментариев :) Но мне не лень, я напишу. ORM + type safe querries (querydsl, hibernate criteria api, jooq) позволили сэкономить сотни тысяч долларов на поддержке проектов, в которых мне посчастливилось участвовать. Как я это прикинул? В тех же проектах по различным причинам было много нативных sql запросов. И проблемы в том числе в продакшене, в том числе с даунтаймами возникали именно с ними. Это была постоянная головная боль у всех. Всё что было связано с ORM/type safe querries работало как часы, практически не требовало поддержки, разрабатывалось быстрее за счет нативных подсказок в IDE для соответствующего языка и за счет всего этого добавляло морали команде разработки.
Если вы не любите делать тестовые и при этом находятся компании, которые готовы взять вас без них - это прекрасно. Аналогично, если компания требует тестовое и в установленный срок способна закрыть вакансию - это тоже замечательно. Это рынок труда, здесь каждый решает свою задачу. Что касается того, что тестовые должны быть интересными - то да, здесь я совершенно согласен, чем интереснее тестовое, тем больше выполненных заданий вы соберете с кандидатов, тем больше шанс найти подходящего человека, если тестовые для вас являются обязательной частью процесса.
Если вы внимательно прочитали пост, то возможно догадываетесь, что никакая. Тестовые задания не имеют практического значения за исключением того, что описано мной выше. Если человек исходит из комерческой логики, что его время стоит деньги и тестовые задания должны быть соответственно оплачены, то он просто его не делает и мы нанимаем на вакансию другого более мотивированного по отношению к ней человека.
Из моего опыта самая главная часть собеседования - это тестовое задание до него. Оно фильтрует кандидатов и вопросы по нему являются органическим способом начать разговор на самом собеседовании, выяснить выполнялось ли оно самостоятельно и понять как человек привык решать технические проблемы, возникающие на практике.
Часто можно слышать, что супер сеньор не будет делать тестовое задание и таким образом значительная часть рынка уходит сквозь пальцы, и отчасти это правда, но еще правда в том, что невозможно оценить мотивированность человека только по встрече, а именно она является одной из основных составляющих дальнейшего успеха кандидата. Мотивация человека, выполнившего тестовое обычно не оставляет сомнений, человек просто пришедший на несколько этапов собеседования - это кот в мешке в плане мотивации.
Другим важным моментом является проверка реакции на критику. Одно дело, когда вы в ходе собеседования спрашиваете : "что будете делать, если ваше решение критикуют?" и совсем другое, когда человек уже потратил несколько часов своего времени и ему в лицо говорят, что он потратил их плохо. Реакция кандидата на такой поворот событий обычно является искренней и очень важной для понимания подходит ли он вам, а вы ему.
Подход с предварительным тестовым скорее всего плохо работает, когда найм идет в крупные компании на потоке, но в них обычно и спрос с каждого отдельного сотрудника меньше. Если же вы набираете людей в небольшую команду и тем более если вам еще и ими руководить, то методологии лучше предварительного тестового задания и беседы по нему и вокруг него, я не встречал, хотя и пробовал. Для статистики: опыт работы в отрасли 18 лет, из них последние 10 руководил командами разработки и занимался хантингом в них. Нанял за это время 32 человека, отсобеседовал больше сотни, отправил тестовое задание (автоматически/через hr/консалтеров) ~1000 раз, среднее время для закрытия вакансии составило ~3 недели, из 32 нанятых ни один не был уволен пока я был в компании, 3 уволились сами до того как я покидал компанию, как минимум 10 работают в тех же компаниях (но необязательно на тех же позициях), куда я их брал.
Разумеется предложенное автором некорректно. Нельзя путать стандартизацию с переводом. А доверять создание стандартов издательству, которое переводит техническую литературу, уж точно нельзя. Но допустим у нас появился какой-то комитет, который сказал, что у нас только засечки и все издательства обязаны следовать этому термину. Проблема в том, что рынок не обязан, и пока процесс стандартизации не пройдет внутри отрасли, любые попытки стандартизации извне будут натыкаться на то, что засечки засечкам где-то чуть чуть, а где-то сильно рознь, с учетом особенностей, сценария использования и т.д. И дабы это как-то отразить появится зоопарк засечек, которые потом отдельно придется мапить на технические термины самих разработчиков.
Интересно, не знал, уточните пожалуйста что имеете ввиду? Если речь про goroutines, то с Loom их нельзя сравнивать, поскольку для их работы нужно применять специальные конструкции языка, а для работы Loom не нужно.
Практически уверен, что после релиза Loom серьезно возьмутся за перформанс и в конечном счете доведут его до близких к асинк библиотекам значений, так было например с parallel streams, когда при появлении в Jdk8, они работали примерно в 2 раза медленнее, чем уже в Jdk11.
Мне кажется самое важное - это не перформанс в моменте, а то, насколько Loom в принципе способен поменять ландшафт современного девелопмента. Ни у одной другой платформы нет такой фичи, которая бы не требовала от программиста специальных приседаний на уровне кода для оптимального использования железа, а у Jdk появится.
Статья действительно по делу, но очень короткая и мало контекста. История развития систем хранения данных очень интересна сама по себе, когда-то давно пытался в ней разобраться, когда занимался небольшим стартапом в области СУБД, но поймал себя на том, что вся информация в разных разрозненных источниках, а хотелось чтобы было в одном месте, максимально просто и связно. В итоге написал статью на медиум, где попробовал собрать то, что удалось наисследовать, если кому интересно, она до сих пор доступна (а стартап больше нет :))
Как справедливо было замечено в других комментариях, ситуация ситуации рознь. От себя добавлю, что с годами приобрел понимание, что нужно делать даже если никто не просит, и это позволяет меньше тратить время в дальнейшем. Уже не на первом рабочем месте получается работать по следующей схеме: полгода/год в достаточно жестком режиме, выстраивая архитектуру нужным образом, потом 2-3 года со значительным запасом свободного времени и минимальным временем на maintenance и техдолг. Это работает если вы тимлид с полномочиями по организации работы и принятию технических решений. Второе условие - нужно немного залезть в бизнес и понять как он устроен.
Александр, поделитесь пожалуйста опытом использования GC Shenondoah: 1. Сколько примерно %CPU отъедает его использование по сравнению с другими GC, которые вы пробовали на ваших нагрузках? 2. Пробовали ли вы ZGC, почему выбрали именно Shenondoah?
Казалось бы тогда автор бы так и написал, называть аллокации мусором не очень корректно, даже если через некоторое время они таковым станут (а может и не станут, если у вас какой-нибудь кэш) :) Но даже в этом случае (опять же речь про java) аллоцировать объекты это не так дорого, как может показаться - в большинстве коллекторов объекты создаются в специальной области (eden), в которой отсутствует фрагментация, объекты создаются просто последовательно занимая память, что само по себе довольно быстро. Проблемы начинаются тогда, когда eden заполнится и нужно будет его очистить, а для этого в свою очередь нужно пройтись по графу живых объектов и скопировать их в соседнюю область, очистив попутно eden. Это уже дольше и опять же зависит не от количества мусора, а от количества живых объектов. Единственное на что существенно влияет "мусор" - это скорость с которой заполняется eden, т.е. как часто нужно вызывать gc алгоритм и копировать живые объекты. Но и тут - если мы признали, что бОльшая часть объектов попадающих в eden на момент сборки будет мусором, то значит копировать потребуется не так много объектов и происходить это будет тоже недолго.
Не знаю, как обстоит дело в go, но в java, например, это не так. Если взять любой коллектор на основе поколений, ему все равно сколько у вас мертвых объектов, поскольку он обойдет граф по живым, скопирует их все в соседний пустой регион (survivor space 1,2), а дальше просто объявит исходный регион пустым. Если бы это так не работало, то создавать что-то в куче было бы дорого и все поголовно пользовались бы пулами даже для простых объектов. Так делают крайне редко именно потому, что короткоживущие объекты на gc почти не влияют
То, как вы делаете что-то - это ваше личное дело, вопрос о тех людях, которые делают по-другому, чем вы и кому было не просто комфортно, а до некоторой степени идеально работать в старом UI (почитайте отзывы), которые пользовались продуктом много лет, платив за это приличные деньги и на мнение которых компания попросту наплевала.
Старый UI выносится в плагин, который они через год перестанут поддерживать.
Гамбургер - это не вкусовщина, а дополнительный клик, которого раньше не было.
Было много тредов, в которых это обсуждалось, например такой на официальном форуме:
https://intellij-support.jetbrains.com/hc/en-us/community/posts/8872880708370-Why-do-you-want-to-ruin-everything-with-new-UI
или в Реддите
https://www.reddit.com/r/Jetbrains/comments/yinae4/what_do_you_guys_think_about_the_new_ui/
У каждого "неудобства" свои в завимости о личного опыта использования, но в чём "старички" сходятся так это в том, что их опыт ухудшился в новом UI. "Лучшая" компания так со своей пользовательской базой, в особенности той, которая исправно оплачивает продукт на протяжении многих лет, не поступает.
Изменения в новом UI - это плевок в лицо старым пользователям компании, в JB это прекрасно сознают, существует масса тредов, где люди полемизировали с представителями JB по этой теме. Основная проблема нового интерфейса в том, что если ты использовал большое количество возможностей IDE(а чем дольше опыт использования, тем выше вероятность такого сценария), то новый интерфейса субъективно оставляет тебя "без рук" и в полном ступоре: привычные эффективные сценарии использования, нарабатывавшиеся годами, больше не работают, а их замена зачастую предполагает дополнительные действия, что выглядит в лучшем случае как нечто излишнее. Почему нельзя было делать переход плавно и постепенно меняя небольшие части ui по чуть чуть, как это делалось до этого остается загадкой. После такого демонстративного кидка, называть продукты JB лучшими у меня и других "старичков", с которыми я знаком, язык больше не поворачивается, простите.
Как классно было ездить на лошадях. Не было выхлопных газов, дтп было на порядок меньше, кучеры были воспеты огромным количеством произведений литературной классики, эстетика, приобщение к культуре, русская тройка... эх что мы потеряли. В общем нужно сделать город, в котором будем передвигаться только на лошадях... Без шуток я бы в таком пожил недельку-другую. Скорее всего это бы стоило чуть дороже средней поездки в отель на море :)
Один из простых способов объяснить факты приведенные в статье - несоизмеримо меньшие в сравнении с большими городами рекламные бюджеты в регионах по очевидной причине их меньшей рентабельности. У нас принято преуменьшать силу воздействия рекламы, ведь "я никогда не покупаю то, что показывают в телевизоре", однако ее наличие - это очень мощный информационный фон, который если и не влияет на вас непосредственно, то как-то затрагивает ваше окружение, а через него и вас. Считать ли рекламу двигателем прогресса каждый выбирает для себя сам.
Кажется автор тонко тролит, чтобы собрать побольше комментариев :) Но мне не лень, я напишу. ORM + type safe querries (querydsl, hibernate criteria api, jooq) позволили сэкономить сотни тысяч долларов на поддержке проектов, в которых мне посчастливилось участвовать. Как я это прикинул? В тех же проектах по различным причинам было много нативных sql запросов. И проблемы в том числе в продакшене, в том числе с даунтаймами возникали именно с ними. Это была постоянная головная боль у всех. Всё что было связано с ORM/type safe querries работало как часы, практически не требовало поддержки, разрабатывалось быстрее за счет нативных подсказок в IDE для соответствующего языка и за счет всего этого добавляло морали команде разработки.
Если вы не любите делать тестовые и при этом находятся компании, которые готовы взять вас без них - это прекрасно. Аналогично, если компания требует тестовое и в установленный срок способна закрыть вакансию - это тоже замечательно. Это рынок труда, здесь каждый решает свою задачу. Что касается того, что тестовые должны быть интересными - то да, здесь я совершенно согласен, чем интереснее тестовое, тем больше выполненных заданий вы соберете с кандидатов, тем больше шанс найти подходящего человека, если тестовые для вас являются обязательной частью процесса.
Если вы внимательно прочитали пост, то возможно догадываетесь, что никакая. Тестовые задания не имеют практического значения за исключением того, что описано мной выше. Если человек исходит из комерческой логики, что его время стоит деньги и тестовые задания должны быть соответственно оплачены, то он просто его не делает и мы нанимаем на вакансию другого более мотивированного по отношению к ней человека.
Из моего опыта самая главная часть собеседования - это тестовое задание до него. Оно фильтрует кандидатов и вопросы по нему являются органическим способом начать разговор на самом собеседовании, выяснить выполнялось ли оно самостоятельно и понять как человек привык решать технические проблемы, возникающие на практике.
Часто можно слышать, что супер сеньор не будет делать тестовое задание и таким образом значительная часть рынка уходит сквозь пальцы, и отчасти это правда, но еще правда в том, что невозможно оценить мотивированность человека только по встрече, а именно она является одной из основных составляющих дальнейшего успеха кандидата. Мотивация человека, выполнившего тестовое обычно не оставляет сомнений, человек просто пришедший на несколько этапов собеседования - это кот в мешке в плане мотивации.
Другим важным моментом является проверка реакции на критику. Одно дело, когда вы в ходе собеседования спрашиваете : "что будете делать, если ваше решение критикуют?" и совсем другое, когда человек уже потратил несколько часов своего времени и ему в лицо говорят, что он потратил их плохо. Реакция кандидата на такой поворот событий обычно является искренней и очень важной для понимания подходит ли он вам, а вы ему.
Подход с предварительным тестовым скорее всего плохо работает, когда найм идет в крупные компании на потоке, но в них обычно и спрос с каждого отдельного сотрудника меньше. Если же вы набираете людей в небольшую команду и тем более если вам еще и ими руководить, то методологии лучше предварительного тестового задания и беседы по нему и вокруг него, я не встречал, хотя и пробовал. Для статистики: опыт работы в отрасли 18 лет, из них последние 10 руководил командами разработки и занимался хантингом в них. Нанял за это время 32 человека, отсобеседовал больше сотни, отправил тестовое задание (автоматически/через hr/консалтеров) ~1000 раз, среднее время для закрытия вакансии составило ~3 недели, из 32 нанятых ни один не был уволен пока я был в компании, 3 уволились сами до того как я покидал компанию, как минимум 10 работают в тех же компаниях (но необязательно на тех же позициях), куда я их брал.
Разумеется предложенное автором некорректно. Нельзя путать стандартизацию с переводом. А доверять создание стандартов издательству, которое переводит техническую литературу, уж точно нельзя. Но допустим у нас появился какой-то комитет, который сказал, что у нас только засечки и все издательства обязаны следовать этому термину. Проблема в том, что рынок не обязан, и пока процесс стандартизации не пройдет внутри отрасли, любые попытки стандартизации извне будут натыкаться на то, что засечки засечкам где-то чуть чуть, а где-то сильно рознь, с учетом особенностей, сценария использования и т.д. И дабы это как-то отразить появится зоопарк засечек, которые потом отдельно придется мапить на технические термины самих разработчиков.
Интересно, не знал, уточните пожалуйста что имеете ввиду? Если речь про goroutines, то с Loom их нельзя сравнивать, поскольку для их работы нужно применять специальные конструкции языка, а для работы Loom не нужно.
Практически уверен, что после релиза Loom серьезно возьмутся за перформанс и в конечном счете доведут его до близких к асинк библиотекам значений, так было например с parallel streams, когда при появлении в Jdk8, они работали примерно в 2 раза медленнее, чем уже в Jdk11.
Мне кажется самое важное - это не перформанс в моменте, а то, насколько Loom в принципе способен поменять ландшафт современного девелопмента. Ни у одной другой платформы нет такой фичи, которая бы не требовала от программиста специальных приседаний на уровне кода для оптимального использования железа, а у Jdk появится.
Статья действительно по делу, но очень короткая и мало контекста. История развития систем хранения данных очень интересна сама по себе, когда-то давно пытался в ней разобраться, когда занимался небольшим стартапом в области СУБД, но поймал себя на том, что вся информация в разных разрозненных источниках, а хотелось чтобы было в одном месте, максимально просто и связно. В итоге написал статью на медиум, где попробовал собрать то, что удалось наисследовать, если кому интересно, она до сих пор доступна (а стартап больше нет :))
https://ivankhodyrev.medium.com/the-best-long-brief-history-of-database-management-systems-cb9a2421a578
Как справедливо было замечено в других комментариях, ситуация ситуации рознь. От себя добавлю, что с годами приобрел понимание, что нужно делать даже если никто не просит, и это позволяет меньше тратить время в дальнейшем. Уже не на первом рабочем месте получается работать по следующей схеме: полгода/год в достаточно жестком режиме, выстраивая архитектуру нужным образом, потом 2-3 года со значительным запасом свободного времени и минимальным временем на maintenance и техдолг. Это работает если вы тимлид с полномочиями по организации работы и принятию технических решений. Второе условие - нужно немного залезть в бизнес и понять как он устроен.
Александр, поделитесь пожалуйста опытом использования GC Shenondoah:
1. Сколько примерно %CPU отъедает его использование по сравнению с другими GC, которые вы пробовали на ваших нагрузках?
2. Пробовали ли вы ZGC, почему выбрали именно Shenondoah?