Привет, спасибо за рассказ. Возникла пара вопросов:
4000 разработчиков в штате — пугающая цифра. Есть ли возможность немного описать разбиение людей по каким-то продуктам/группам? Или это не только Озон, но и какие-то другие проекты вашей фирмы?
Платформенные команды забрали к себе все вкусные задачи, позволив продуктовым командам только разрабатывать бизнесовые фичи. Как вы боритесь с выгоранием людей в продуктовых командах, где нет никаких технологических челленджей, и нужно просто использовать готовые managed сервисы?
> вы же, наверно, вкурсе о больших накладных расходах при создании record-классов
Больших расходов по сравнению с чем? С созданием обычных объектов, или не пулом объектов?
в runtime — для платформ или движков JVM, V8, а теперь и Ruby с его JIT-компиляцией. Чтобы для них произвести инлайниг, сначала происходит JIT-компиляция, а вместо байт-кодов уже вставляется машинный код. Это тоже можно рассматривать как встраивание.
Понятно, что статья про go, и это лишь сноска на полях, но всё же. Есть ли какой-то внятный источник, почему мы это можем рассматривать, как встраивание? Для меня это не глядит корректным, но, может быть, кто-то авторитетный решил, что это корректно.
А какая область применения у такого хранилища? Подозреваю, что для баз данных это не подойдет из-за перфоманса, а также из-за того что многие БД сами занимаются репликацией и шардированием данных, и не требуется такая функциональность.
Это и так понятно. Про какие конкретно операции идет речь? Например, вы общаетесь с pg через epoll, что именно блокируется (пока не смотрел код, может там и не epoll)?
Хм, мне изначально казалось, что именно этот код вызывается, но после вашего вопроса я стал сомневаться, так как пакет Apache BCEL.
Я попробовал поискать по исходникам, но сходу не нашёл никакого другого места с такой же логикой. Так что, пока не могу сказать точно, ошибя я изначально или нет.
> Вопрос: Рассматривали ли Вы описанный мной способ реализации Вашей задачи? Если — да, то почему остановились на своем варианте — чем он показался Вам выигрышней?
Честно говоря, не рассматривал, так как не знал / не помнил о такой возможности, в то время как кастомные процессоры аннотаций когда-то делал.
А как в случае с com.sun.source.util.Plugin унзнавать, какие элементы нужно обрабатывать, а какие — нет? Как я понимаю, зарегистрировать свой TaskListener мы легко можем, а вот часть про обработку кастомной аннотации, или чего-то другого, что даст мне список нужных классов для анализа, я пока не вижу.
Больших расходов по сравнению с чем? С созданием обычных объектов, или не пулом объектов?
Понятно, что статья про go, и это лишь сноска на полях, но всё же. Есть ли какой-то внятный источник, почему мы это можем рассматривать, как встраивание? Для меня это не глядит корректным, но, может быть, кто-то авторитетный решил, что это корректно.
Подскажите, пожалуйста, про какие блокирующие операци тут идет речь (это документа из раздела про PostgreSQL)?
Сам на С++ не пишу, но хочется понять, как реализован драйвер для PG, чтобы сравнивить с java-подходами.
Я попробовал поискать по исходникам, но сходу не нашёл никакого другого места с такой же логикой. Так что, пока не могу сказать точно, ошибя я изначально или нет.
Извините, но не знаю, какой верный перевод на русский язык.
Спасьбо за комментарий.
> Вопрос: Рассматривали ли Вы описанный мной способ реализации Вашей задачи? Если — да, то почему остановились на своем варианте — чем он показался Вам выигрышней?
Честно говоря, не рассматривал, так как не знал / не помнил о такой возможности, в то время как кастомные процессоры аннотаций когда-то делал.
А как в случае с com.sun.source.util.Plugin унзнавать, какие элементы нужно обрабатывать, а какие — нет? Как я понимаю, зарегистрировать свой TaskListener мы легко можем, а вот часть про обработку кастомной аннотации, или чего-то другого, что даст мне список нужных классов для анализа, я пока не вижу.