Это не совсем так. Если вас что-то не устраивает, вы всегда можете собрать команду единомышленников и продолжить. Могу привести пример из своего опыта, в своё время существовал AOT компилятор Java кода под иос под названием RoboVM: https://github.com/robovm/robovm, их с потрохами купил майкрософт и недолго думая на следующий год убил https://venturebeat.com/business/following-xamarin-acquisition-microsoft-will-kill-its-robovm-service-in-april-2017/ Мэйнтейнера разумеется по-майкрософтовски озолотили и скорее всего в контракте прописали, что этим больше заниматься не надо. Казалось бы всё, финита. Но нет, появился форк, который прекрасно дожил до наших дней, последние комиты в мастер за прошлый месяц https://github.com/MobiVM/robovm. Опенсурс силён тем, что если людям что-то сильно надо, то они могут заняться этим сами несмотря ни на что. Всё остальное, включая что кто-то чей-то PR не принял и почему это произошло - наносное.
Они исправились, потому что это было хорошо для их бизнеса. В случае, который мы рассматриваем, в текущих обстоятельствах, для бизнеса мэйнтейнеров флюттера хорошо другое. А если говорить про рандомного одинокого мэйнтэйнера, то как ему лучше делать, решает только он сам. Правда случались прецеденты, когда из-за этого были проблемы у всех (https://en.wikipedia.org/wiki/Npm_left-pad_incident), но это скорее говорит про незрелость платформы в те годы, а по-хорошему мэйнтэйнер должен иметь право делать то, что он считает нужным в рамках тех возможностей, которые ему предоставляются платформой. В конце концов он тратит своё время, а в случае компаний свои деньги и упрекать их за некую предвзятость - это то же самое, что ругаться на киоск с бесплатным мороженным, что он неудобно стоит.
Казалось бы open source у вас никто не отнимает. Код открыт, лицензия щадящая, форкайте и наслаждайтесь. А что касается разрешения на коммиты, то это не про open source, по хорошему майнтэнер вообще может никого не слушать и делать, что хотеть, open source как таковой его ни к чему не обязывает кроме открытия кода.
Немного опережу автора, если вдруг вам интересно почитать первоисточник статьи, то он здесь https://medium.com/@ivankhodyrev/the-best-long-brief-history-of-database-management-systems-cb9a2421a578 . Статья randall не является дословным пересказом, но периодизация, общая структура повествования и многие детали взяты оттуда. Это важно, поскольку такая периодизация не общепризнана и является существенным упрощением, что признает автор статьи на medium. Реальная история развития баз данных гораздо сложнее структурирована, чем простое разделение на 10 летние периоды.
Про годичной давности или про свежие? Я бы про свежие почитал, поскольку меняется там всё быстро. Но с другой стороны, даже если там до сих пор всё плохо, если зарабатывать не в Аргентине и в крепкой валюте, то по слухам там вполне неплохо.
Диалектика на пальцах, буду знать, спасибо 😀 а по делу - это как на фондовом рынке, мы сейчас внизу или наверху? Кто угадал, тот получает всё. И, как уже написано, я бы не стал однозначно ставить на то, что люди сейчас слабые и времена нас ждут тяжелые(в мировом масштабе)
Всё, что вы пишете во-многом верно. Но есть нюанс. Вы утверждаете, что open source попроще вас не устраивает, т.е. предполагается, что вам нужны все или почти все фичи, которые есть в openstack. И под конец вы предполагаете, что сделаете все это сами. Чтобы это сделать в обозримые сроки и с хорошим качеством в моменте вам потребуется большая команда талантливых людей, значительная часть которой потом окажется не нужна. Как на российском рынке сейчас быстро найти такие ресурсы, мне, например, не очень понятно. Если же вы будете пилить openstack своим обычным отделом разработки, наняв "2-3 специалиста в помощь", я не уверен, что качество и/или сроки окажутся вменяемыми.
Статья выглядит теоретически обоснованной. Действительно, как кажется, разная среда должна порождать немного разных людей. Тем не менее из своего опыта я не могу однозначно сделать такой же вывод. Например, сейчас у меня в команде младшему разработчику 23 года, есть ребята кому 24 и 25. И ни про кого из них я не могу сказать, что они чего-то не могут, что могли мы в их годы. Да, во-многом мы разные, они смеются надо мной, когда я радуюсь добавлению понравившегося трека в свой плейлист, утверждая что никогда не будут слушать одно и то же дважды. Да, они ошибаются в рабочих вопросах, но делают это также, как делали мы в их годы. Да, иногда кажется, что у них в голове каша, но я не могу поручиться, что в их годы у меня всё было идеально разложено по полочкам.
Короче говоря, обобщение, которое делает автор статьи очень привлекательно и, как видно из реакций, хорошо заходит публике, но я бы не стал делать на него однозначную ставку.
Статья написана поверхностно и более того присутствуют ошибки, которые выдают принципиальное непонимание рассматриваемой темы. Например, у автора были ожидания, что перейдя на реактивный подход latency одного запроса должно уменьшиться. На практике всё очень зависит от конкретных библиотек/серверов, но с теоретической точки зрения ожидать такое странно, если вы понимаете, как работает event loop, крутящийся внутри вашей "асинхронщины" и какую задачу он решает. Ну и конечно незаслуженно обойдён вниманием Loom, который в ближайшее время (после релиза 24 версии) сделает необходимость писать асинхронный код для задачи повышения утилизации железа весьма сомнительной.В качестве рекомендации "что почитать", я дам вам две ссылки: на мой комментарий, где я в трех параграфах просто и доступно пытаюсь рассказать про асинхронность в Java и где здесь место для Loom https://habr.com/ru/companies/spring_aio/articles/838912/comments/#comment_27217910, но если у вас есть время то лучше почитать блестящую статью Браина Гоетца, думаю, что после её прочтения у вас не останется вопросов: https://www.infoq.com/articles/java-virtual-threads
Не ошибается тот, кто ничего не делает :) Что касается мотивации у меня были ситуации, когда без тестового на входе приходили толковые люди и уходили через 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 желающих в итоге нанимаю одного.
Мне повезло, я могу себе это позволить, поскольку всегда ханчу в небольшие команды и под свое руководство. Мне часто говорят, что таким образом я срезаю много толковых людей, кто не хочет делать тестовое. И я не спорю, для меня если человек не готов делать тестовое, значит он недостаточно мотивирован, хотя с профессиональной стороны он может быть на порядок сильнее, чем человек, которого я в конце концов найму. Обычно люди нанятые таким образом прекрасно вписываются в команду и достаточно хорошо мотивированы в том числе и для того, чтобы профессионально расти.
Когда речь идёт о потоковом найме в десятки команд и необходимости идти на "необходимые" компромисы - не завидую людям, кто этим занимается, и конечно лидам команд, куда приходят люди после такого потокового найма.
В прошлом году появился еще один важный тренд, по непонятной причине пропущенный в тексте: существенное повышение качества плагинов, выпускаемых уважающими себя компаниями - теперь всего за несколько месяцев они набирают тысячи скачиваний и сотни благодарных комментариев.
Это не совсем так. Если вас что-то не устраивает, вы всегда можете собрать команду единомышленников и продолжить. Могу привести пример из своего опыта, в своё время существовал AOT компилятор Java кода под иос под названием RoboVM: https://github.com/robovm/robovm, их с потрохами купил майкрософт и недолго думая на следующий год убил https://venturebeat.com/business/following-xamarin-acquisition-microsoft-will-kill-its-robovm-service-in-april-2017/
Мэйнтейнера разумеется по-майкрософтовски озолотили и скорее всего в контракте прописали, что этим больше заниматься не надо. Казалось бы всё, финита. Но нет, появился форк, который прекрасно дожил до наших дней, последние комиты в мастер за прошлый месяц https://github.com/MobiVM/robovm.
Опенсурс силён тем, что если людям что-то сильно надо, то они могут заняться этим сами несмотря ни на что. Всё остальное, включая что кто-то чей-то PR не принял и почему это произошло - наносное.
Они исправились, потому что это было хорошо для их бизнеса. В случае, который мы рассматриваем, в текущих обстоятельствах, для бизнеса мэйнтейнеров флюттера хорошо другое. А если говорить про рандомного одинокого мэйнтэйнера, то как ему лучше делать, решает только он сам. Правда случались прецеденты, когда из-за этого были проблемы у всех (https://en.wikipedia.org/wiki/Npm_left-pad_incident), но это скорее говорит про незрелость платформы в те годы, а по-хорошему мэйнтэйнер должен иметь право делать то, что он считает нужным в рамках тех возможностей, которые ему предоставляются платформой. В конце концов он тратит своё время, а в случае компаний свои деньги и упрекать их за некую предвзятость - это то же самое, что ругаться на киоск с бесплатным мороженным, что он неудобно стоит.
"Очень жаль, что в 2025 году open source..."
Казалось бы open source у вас никто не отнимает. Код открыт, лицензия щадящая, форкайте и наслаждайтесь. А что касается разрешения на коммиты, то это не про open source, по хорошему майнтэнер вообще может никого не слушать и делать, что хотеть, open source как таковой его ни к чему не обязывает кроме открытия кода.
Сферический патриIТизм в вакууме. Наблюдать за этим явлением рекомендуется из самой дальней точки вселенной.
Немного опережу автора, если вдруг вам интересно почитать первоисточник статьи, то он здесь https://medium.com/@ivankhodyrev/the-best-long-brief-history-of-database-management-systems-cb9a2421a578 . Статья randall не является дословным пересказом, но периодизация, общая структура повествования и многие детали взяты оттуда. Это важно, поскольку такая периодизация не общепризнана и является существенным упрощением, что признает автор статьи на medium. Реальная история развития баз данных гораздо сложнее структурирована, чем простое разделение на 10 летние периоды.
Поделитесь пожалуйста ссылками на литературу, которую использовали для написания статьи
Про годичной давности или про свежие? Я бы про свежие почитал, поскольку меняется там всё быстро. Но с другой стороны, даже если там до сих пор всё плохо, если зарабатывать не в Аргентине и в крепкой валюте, то по слухам там вполне неплохо.
На хабре сложно такого не поймать, хотя последнее время ловится и другое, конечно
Могу пожелать успехов! Может заопенсорсите что-нибудь полезное по итогу 😉
Диалектика на пальцах, буду знать, спасибо 😀 а по делу - это как на фондовом рынке, мы сейчас внизу или наверху? Кто угадал, тот получает всё. И, как уже написано, я бы не стал однозначно ставить на то, что люди сейчас слабые и времена нас ждут тяжелые(в мировом масштабе)
Всё, что вы пишете во-многом верно. Но есть нюанс. Вы утверждаете, что open source попроще вас не устраивает, т.е. предполагается, что вам нужны все или почти все фичи, которые есть в openstack. И под конец вы предполагаете, что сделаете все это сами. Чтобы это сделать в обозримые сроки и с хорошим качеством в моменте вам потребуется большая команда талантливых людей, значительная часть которой потом окажется не нужна. Как на российском рынке сейчас быстро найти такие ресурсы, мне, например, не очень понятно. Если же вы будете пилить openstack своим обычным отделом разработки, наняв "2-3 специалиста в помощь", я не уверен, что качество и/или сроки окажутся вменяемыми.
Жаль, что не вижу Аргентину в статистике. Про неё не пишут?
Очень много слов, но не совсем понятна суть конфликта. Вас попросили выгрузить данные в эксель, а вы отказались?..
Статья выглядит теоретически обоснованной. Действительно, как кажется, разная среда должна порождать немного разных людей. Тем не менее из своего опыта я не могу однозначно сделать такой же вывод. Например, сейчас у меня в команде младшему разработчику 23 года, есть ребята кому 24 и 25. И ни про кого из них я не могу сказать, что они чего-то не могут, что могли мы в их годы. Да, во-многом мы разные, они смеются надо мной, когда я радуюсь добавлению понравившегося трека в свой плейлист, утверждая что никогда не будут слушать одно и то же дважды. Да, они ошибаются в рабочих вопросах, но делают это также, как делали мы в их годы. Да, иногда кажется, что у них в голове каша, но я не могу поручиться, что в их годы у меня всё было идеально разложено по полочкам.
Короче говоря, обобщение, которое делает автор статьи очень привлекательно и, как видно из реакций, хорошо заходит публике, но я бы не стал делать на него однозначную ставку.
Статья написана поверхностно и более того присутствуют ошибки, которые выдают принципиальное непонимание рассматриваемой темы. Например, у автора были ожидания, что перейдя на реактивный подход latency одного запроса должно уменьшиться. На практике всё очень зависит от конкретных библиотек/серверов, но с теоретической точки зрения ожидать такое странно, если вы понимаете, как работает event loop, крутящийся внутри вашей "асинхронщины" и какую задачу он решает. Ну и конечно незаслуженно обойдён вниманием Loom, который в ближайшее время (после релиза 24 версии) сделает необходимость писать асинхронный код для задачи повышения утилизации железа весьма сомнительной.В качестве рекомендации "что почитать", я дам вам две ссылки: на мой комментарий, где я в трех параграфах просто и доступно пытаюсь рассказать про асинхронность в Java и где здесь место для Loom https://habr.com/ru/companies/spring_aio/articles/838912/comments/#comment_27217910, но если у вас есть время то лучше почитать блестящую статью Браина Гоетца, думаю, что после её прочтения у вас не останется вопросов: https://www.infoq.com/articles/java-virtual-threads
Не ошибается тот, кто ничего не делает :) Что касается мотивации у меня были ситуации, когда без тестового на входе приходили толковые люди и уходили через 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