Не ошибается тот, кто ничего не делает :) Что касается мотивации у меня были ситуации, когда без тестового на входе приходили толковые люди и уходили через 3 месяца, а вот с введением тестового минимальное время, которое человек работал после найма - это полтора года. Связано ли это с тестовым или нет, не знаю, стат тесты не проводил, но интуитивно кажется, что связано. Помимо мотивации сделанное тестовое задание по моему опыту еще коррелирует с низкой конфликтностью людей, это тоже может влиять на длительность последующей работы. Так что ошибка или не ошибка - это как обычно с какой стороны посмотреть. Про тяжесть найма - за 10 лет, которые я набираю с тестовым, ни разу не было, чтобы непосредственно поиск занимал бы дольше полутора месяцев.
тестовое обычно можно по-разному сделать приложив разное количество усилий, это не просто алгоритмическая задача. Обычно 4-6 часов раньше занимало у людей, сейчас с AI скорее всего быстрее.
На Java довольно много коммерческих игр, из успешных можно вспомнить, например, Minecraft или Slay the spire. В опенсорс крыле есть легендарная Pixel Dungeon https://github.com/watabou/pixel-dungeon. Помимо Jmonkey есть движок LibGDX https://libgdx.com/, на котором мне довелось писать игры еще 14 лет назад и который силами энтузиастов жив до сих пор, игру на нём можно будет собрать под любую платформу включая Ios(используя Robovm https://github.com/MobiVM/robovm). На LibGDX написан очень известный редактор для 2D анимаций Spine https://esotericsoftware.com/, который мои коллеги много лет использовали в коммерческих играх на Unity. В геймдеве очень популярен подход к архитектуре, который называется ECS - entity, component, system, для Java и под него есть готовая либа - Artemis https://github.com/junkdog/artemis-odb.
К чему это я всё? А к тому же, о чем пишет автор статьи - если вам нравится Java, вы хотите заняться разработкой игр и любите code-only подход, то есть множество инструментов, которые вам в этом помогут.
У меня тоже одно время была ситуация, когда 2-3 собеседования в день были нормой и иногда даже больше. Я от этого устал и уже 10 лет даю тестовые задания на входе до собеседования, а на самом собеседовании примерно половину времени посвящаю разбору тестового и прошу что-то в нем доделать или поменять. Статистика за всё это время в разные компании у меня примерно одинаковая: присылают решение тестовых примерно треть кандидатов из тех, кто был изначально заинтересован в вакансии, из них еще в 50% случаев сразу понятно, что говорить не о чем. В итоге собеседование я провожу примерно с 15% от исходного потока кандидатов из которых реально проходят собеседование примерно треть. Итог: из примерно 20 желающих в итоге нанимаю одного.
Мне повезло, я могу себе это позволить, поскольку всегда ханчу в небольшие команды и под свое руководство. Мне часто говорят, что таким образом я срезаю много толковых людей, кто не хочет делать тестовое. И я не спорю, для меня если человек не готов делать тестовое, значит он недостаточно мотивирован, хотя с профессиональной стороны он может быть на порядок сильнее, чем человек, которого я в конце концов найму. Обычно люди нанятые таким образом прекрасно вписываются в команду и достаточно хорошо мотивированы в том числе и для того, чтобы профессионально расти.
Когда речь идёт о потоковом найме в десятки команд и необходимости идти на "необходимые" компромисы - не завидую людям, кто этим занимается, и конечно лидам команд, куда приходят люди после такого потокового найма.
В прошлом году появился еще один важный тренд, по непонятной причине пропущенный в тексте: существенное повышение качества плагинов, выпускаемых уважающими себя компаниями - теперь всего за несколько месяцев они набирают тысячи скачиваний и сотни благодарных комментариев.
Ночной кошмар Мартина Фаулера - из кота вылезает сервис уборной для кота. Но к концу кошмар сменяется умиротворением - сухая еда это не сервис а заботливо переданный честный объект 😂
Если я правильно понял принцип, то что-то неприятное лучше выносить в сервисы и принимать не сами объекты, а айдишники, чтобы случайно их не запачкать, а приятное наоборот заботливо передавать объектом в конструкторе, поближе, так сказать, к полям. 🤗
Этому багу 30 лет. Я согласен с автором в том смысле, что выбрасываемые в рантайме UnsupportedOperationException - это зло и в sdk по-хорошему такого не должно быть в принципе, эти вещи нужно проверять в момент компиляции. Для этого исходные интерфейсы наверно стоило бы спроектировать по-другому изначально, например можно было бы базовый Collection разбить на несколько интерфейсов. Но это всё дела давно минувших дней, сейчас радикально поменять это уже нельзя. А что касается sequenced collections, то они сделаны вполне неплохо, на мой взгляд сильно не портят то, что уже было, и помогают в местах, где до этого был бойлерплейт/велосипеды.
Про память это условно, всё зависит от особенностей приложения, если у вас 32гб монолит, но масштабируетесь вы потому, что у вас на один эндпоинт, который потребляет при вызове 100 байт, миллион запросов в секунду, а остальное приложение просто пассивно висит в памяти, то да действительно скейлить всё приложение только ради одного эндпоинта странно и его нужно выносить. Однако если у вас нагрузка +- гомогенна на всё приложение, то распилив эти 32 гигабайта по микросервисам вы не получите преимуществ с точки зрения памяти, а скорее наоборот, поскольку помимо полезной нагрузки отдельные рантаймы будут потреблять память в то время как в монолите рантайм потребляет память один раз.
Что касается ресурсов, например коннекшенов, то здесь я соглашусь, за этим надо внимательно следить при масштабировании монолита, это может вызвать проблему, особенно если внешних ресурсов много и каждый из них используется только одним модулем. С другой стороны, например, если у вас подключение к одной базе, используется connection pool и модули работают с разными схемами, то как и в случае с памятью распилив приложение вы не получите преимуществ, а скорее наоборот.
Приведите, пожалуйста, пример. В общем случае это не так и зависит от платформы. Если у вас есть монолит, например на java, который потребляет 8Гб памяти, то распилив его, суммарная потребляемая память увеличится, поскольку для каждого микросервиса помимо полезной нагрузки будет подниматься отдельный jvm рантайм, потребляющий память. В случае монолита, такой рантайм только один.
Если это какой-то междусобойчик для просветленных, то зачем он в паблике на хабре. Если нет, то непонятно как минимум ничего. Почему отказ от транзакций? Какая государственная система? Причем здесь Эльбрус? Чем автора не устроила производительность jvm, какой версии и с чем он сравнивал?
С автором статьи согласен в том смысле, что менеджеры гораздо чаще воспринимают скрам как волшебную палочку, которая позволяет "за две недели сделать всё, что написано" (хотя, как подчеркивают многие комментаторы, методология на этом не настаивает). Если же команда работает по канбану, то шанс увидеть адекватного менеджера выше.
Микросервисы - это в первую очередь про управление командами и определенную интерпретацию принципа разделяй и властвуй для больших компаний. Когда компания и отдел разработки маленькие всё это теряет смысл и прослойки начинают съедать больше ресурсов, чем полезная нагрузка.
Java вообще не при чем. Первый микросервайс хел, который я увидел, был на ноде. Что касается инженеров и думать головой - нужен архитектор, кто придумает, как оно всё вместе будет работать вместе. К инженерам, которые пишут непосредственно код на любом языке, это не имеет отношения.
В таком случае я бы не стал называть приложение, состоящее из разрозненных бинарных файлов, потенциально имеющих разные версии, написанных на разных языках разными командами и по-разному взаимодействующих друг с другом монолитом. Для меня основным признаком монолита является то, что он работает через общую память и собирается как единое целое одной системой сборки, у чего есть понятные плюсы и минусы. Как только у вас появляются дополнительные части, пусть и лежащие на той же машине и работающие не через сеть, рассуждение об этом как о монолите может привести к неправильным выводам
Причиной было то, что крупным компаниям, где сотни и тысячи разработчиков работают над одной экосистемой без микросервисов никак и они стали популяризовать этот подход, чтобы сразу с рынка брать знакомых с ним людей. Компаниям со значительно меньшими отделами разработки это было далеко не так необходимо, но повинуясь моде и давлению крупных компаний (все конференции были только про микросервисы в те времена), во многих мелких компаниях начинали без разбора переходить на микросервисы. Из самых плачевных результатов, которые я встречал: люди занимаются прослойками - чинят очереди, ковыряют кубер, сравнивают версии микросервисов и ищут в них нестыковки, а бизнес фичи стоят по несколько спринтов.
Не ошибается тот, кто ничего не делает :) Что касается мотивации у меня были ситуации, когда без тестового на входе приходили толковые люди и уходили через 3 месяца, а вот с введением тестового минимальное время, которое человек работал после найма - это полтора года. Связано ли это с тестовым или нет, не знаю, стат тесты не проводил, но интуитивно кажется, что связано. Помимо мотивации сделанное тестовое задание по моему опыту еще коррелирует с низкой конфликтностью людей, это тоже может влиять на длительность последующей работы. Так что ошибка или не ошибка - это как обычно с какой стороны посмотреть.
Про тяжесть найма - за 10 лет, которые я набираю с тестовым, ни разу не было, чтобы непосредственно поиск занимал бы дольше полутора месяцев.
тестовое обычно можно по-разному сделать приложив разное количество усилий, это не просто алгоритмическая задача. Обычно 4-6 часов раньше занимало у людей, сейчас с AI скорее всего быстрее.
На Java довольно много коммерческих игр, из успешных можно вспомнить, например, Minecraft или Slay the spire. В опенсорс крыле есть легендарная Pixel Dungeon https://github.com/watabou/pixel-dungeon. Помимо Jmonkey есть движок LibGDX https://libgdx.com/, на котором мне довелось писать игры еще 14 лет назад и который силами энтузиастов жив до сих пор, игру на нём можно будет собрать под любую платформу включая Ios(используя Robovm https://github.com/MobiVM/robovm). На LibGDX написан очень известный редактор для 2D анимаций Spine https://esotericsoftware.com/, который мои коллеги много лет использовали в коммерческих играх на Unity. В геймдеве очень популярен подход к архитектуре, который называется ECS - entity, component, system, для Java и под него есть готовая либа - Artemis https://github.com/junkdog/artemis-odb.
К чему это я всё? А к тому же, о чем пишет автор статьи - если вам нравится Java, вы хотите заняться разработкой игр и любите code-only подход, то есть множество инструментов, которые вам в этом помогут.
У меня тоже одно время была ситуация, когда 2-3 собеседования в день были нормой и иногда даже больше. Я от этого устал и уже 10 лет даю тестовые задания на входе до собеседования, а на самом собеседовании примерно половину времени посвящаю разбору тестового и прошу что-то в нем доделать или поменять. Статистика за всё это время в разные компании у меня примерно одинаковая: присылают решение тестовых примерно треть кандидатов из тех, кто был изначально заинтересован в вакансии, из них еще в 50% случаев сразу понятно, что говорить не о чем. В итоге собеседование я провожу примерно с 15% от исходного потока кандидатов из которых реально проходят собеседование примерно треть. Итог: из примерно 20 желающих в итоге нанимаю одного.
Мне повезло, я могу себе это позволить, поскольку всегда ханчу в небольшие команды и под свое руководство. Мне часто говорят, что таким образом я срезаю много толковых людей, кто не хочет делать тестовое. И я не спорю, для меня если человек не готов делать тестовое, значит он недостаточно мотивирован, хотя с профессиональной стороны он может быть на порядок сильнее, чем человек, которого я в конце концов найму. Обычно люди нанятые таким образом прекрасно вписываются в команду и достаточно хорошо мотивированы в том числе и для того, чтобы профессионально расти.
Когда речь идёт о потоковом найме в десятки команд и необходимости идти на "необходимые" компромисы - не завидую людям, кто этим занимается, и конечно лидам команд, куда приходят люди после такого потокового найма.
В прошлом году появился еще один важный тренд, по непонятной причине пропущенный в тексте: существенное повышение качества плагинов, выпускаемых уважающими себя компаниями - теперь всего за несколько месяцев они набирают тысячи скачиваний и сотни благодарных комментариев.
https://plugins.jetbrains.com/plugin/24468-classic-ui
Ночной кошмар Мартина Фаулера - из кота вылезает сервис уборной для кота. Но к концу кошмар сменяется умиротворением - сухая еда это не сервис а заботливо переданный честный объект 😂
Если я правильно понял принцип, то что-то неприятное лучше выносить в сервисы и принимать не сами объекты, а айдишники, чтобы случайно их не запачкать, а приятное наоборот заботливо передавать объектом в конструкторе, поближе, так сказать, к полям. 🤗
Этому багу 30 лет. Я согласен с автором в том смысле, что выбрасываемые в рантайме UnsupportedOperationException - это зло и в sdk по-хорошему такого не должно быть в принципе, эти вещи нужно проверять в момент компиляции. Для этого исходные интерфейсы наверно стоило бы спроектировать по-другому изначально, например можно было бы базовый Collection разбить на несколько интерфейсов. Но это всё дела давно минувших дней, сейчас радикально поменять это уже нельзя. А что касается sequenced collections, то они сделаны вполне неплохо, на мой взгляд сильно не портят то, что уже было, и помогают в местах, где до этого был бойлерплейт/велосипеды.
Про память это условно, всё зависит от особенностей приложения, если у вас 32гб монолит, но масштабируетесь вы потому, что у вас на один эндпоинт, который потребляет при вызове 100 байт, миллион запросов в секунду, а остальное приложение просто пассивно висит в памяти, то да действительно скейлить всё приложение только ради одного эндпоинта странно и его нужно выносить. Однако если у вас нагрузка +- гомогенна на всё приложение, то распилив эти 32 гигабайта по микросервисам вы не получите преимуществ с точки зрения памяти, а скорее наоборот, поскольку помимо полезной нагрузки отдельные рантаймы будут потреблять память в то время как в монолите рантайм потребляет память один раз.
Что касается ресурсов, например коннекшенов, то здесь я соглашусь, за этим надо внимательно следить при масштабировании монолита, это может вызвать проблему, особенно если внешних ресурсов много и каждый из них используется только одним модулем. С другой стороны, например, если у вас подключение к одной базе, используется connection pool и модули работают с разными схемами, то как и в случае с памятью распилив приложение вы не получите преимуществ, а скорее наоборот.
Приведите, пожалуйста, пример. В общем случае это не так и зависит от платформы. Если у вас есть монолит, например на java, который потребляет 8Гб памяти, то распилив его, суммарная потребляемая память увеличится, поскольку для каждого микросервиса помимо полезной нагрузки будет подниматься отдельный jvm рантайм, потребляющий память. В случае монолита, такой рантайм только один.
Если это какой-то междусобойчик для просветленных, то зачем он в паблике на хабре. Если нет, то непонятно как минимум ничего. Почему отказ от транзакций? Какая государственная система? Причем здесь Эльбрус? Чем автора не устроила производительность jvm, какой версии и с чем он сравнивал?
А в чем вы видите проблему горизонтально масштабировать монолит?
С автором статьи согласен в том смысле, что менеджеры гораздо чаще воспринимают скрам как волшебную палочку, которая позволяет "за две недели сделать всё, что написано" (хотя, как подчеркивают многие комментаторы, методология на этом не настаивает). Если же команда работает по канбану, то шанс увидеть адекватного менеджера выше.
Когда на 100 микросервисов одна команда из 10 человек - это тоже проблема
Когда над монолитом работает сотня команд - это проблема
Масштабировать монолит по rps в сотне инстансов не проблема.
Микросервисы - это в первую очередь про управление командами и определенную интерпретацию принципа разделяй и властвуй для больших компаний. Когда компания и отдел разработки маленькие всё это теряет смысл и прослойки начинают съедать больше ресурсов, чем полезная нагрузка.
Java вообще не при чем. Первый микросервайс хел, который я увидел, был на ноде. Что касается инженеров и думать головой - нужен архитектор, кто придумает, как оно всё вместе будет работать вместе. К инженерам, которые пишут непосредственно код на любом языке, это не имеет отношения.
В таком случае я бы не стал называть приложение, состоящее из разрозненных бинарных файлов, потенциально имеющих разные версии, написанных на разных языках разными командами и по-разному взаимодействующих друг с другом монолитом. Для меня основным признаком монолита является то, что он работает через общую память и собирается как единое целое одной системой сборки, у чего есть понятные плюсы и минусы. Как только у вас появляются дополнительные части, пусть и лежащие на той же машине и работающие не через сеть, рассуждение об этом как о монолите может привести к неправильным выводам
И как эти бинари взаимодействуют?
Причиной было то, что крупным компаниям, где сотни и тысячи разработчиков работают над одной экосистемой без микросервисов никак и они стали популяризовать этот подход, чтобы сразу с рынка брать знакомых с ним людей. Компаниям со значительно меньшими отделами разработки это было далеко не так необходимо, но повинуясь моде и давлению крупных компаний (все конференции были только про микросервисы в те времена), во многих мелких компаниях начинали без разбора переходить на микросервисы. Из самых плачевных результатов, которые я встречал: люди занимаются прослойками - чинят очереди, ковыряют кубер, сравнивают версии микросервисов и ищут в них нестыковки, а бизнес фичи стоят по несколько спринтов.