Добрый день. Примерно так и сделали в итоге, с бинарной сериализацией. Наша бинарная сериализация, которая упомянута в статье использует битовые маски в том числе, но не только их. Так же диапазоны и сокращения.
Ключевое, что битовую маску нельзя писать строкой как есть, иначе не будет никакой экономии, надо использовать Base64 сериализацию. Тратить байт на один бит это дорого, а в строковом представлении на каждый 1 или 0 будет уходить байт (кодировка заголовков ANSI).
На гитхабе возможно, но банк не может пользоваться гитхабом и прочими облачными продуктами.
На самом деле, проблема разграничения доступов вообще была последней, о которой думали на старте, не говоря о том, что в 2015-м этой фичи не было.
Два основных кошмара — отслеживание зависимостей на уровне файловой системы. Многие до сих пор это любят, как показывает общение с коллегами. Заставить разработчика работать через пакеты в одном репозитории очень тяжелая задача.
Вторая проблема — корректное отслеживание изменений, в каком компоненте что поменялось и с какой версией ее надо пересобрать и т.п. На маленьких отдельных репозиториях это делать было гораздо проще. Единая версия на репозиторий с несколькими компонентами это вообще жесткий антипаттерн.
На практике это оказалось удобно, далее шла эволюция.
Спасибо за уточнение. Тут я не специалист. Имел в виду именно диоптрии. Шлем текущим идеальным зрением воспринимается как раз как очки на -1,5 при -2,5 на глазах.
Угол у него явно лучше чем у Rift S и Quest. Прямо ощутимо лучше. Обзоры, которые говорят про его узость, похоже делали люди с какой-то другой анатомией, чем у меня. Но мне и Rift S совершенно нормально был.
С новыми VR шлемами типа Quest 2 и Reverb G2 вообще беда с производительностью. Как обладатель связки 5800X + 3080 и обоих шлемов могу сказать, что с одной стороны прямо расстроен, с другой восхищён.
Восхищён я уровнем картинки. Reverb G2 воспринимается на уровне зрения около нуля по нашей системе, когда 1 это идеальное. Говорю как человек, сделавший коррекцию с -2,5, до +1 и до этого переживший плавное падение. Т.е. в 90% случаев вы даже не будете знать, что у вас была деградация зрения. Цвета, чёткость, все блеск. Кино в нем выглядит как будто в imax смотришь. До физического предела человеческого зрения осталось очень не много. Rift S воспринимается теперь как кино на качественном VHS против Blu-ray. Quest 2 непринципиально хуже по разрешению, но проигрывает по цветам и яркости, зато беспроводной.
Расстроен я тем, что с таким уровнем картинки 3080 тупо не хватает. И не на проценты, а кратно. Если HL: Alyx играбелен на ультрах на 90 герц (около 110 fps), то большинство не настолько вылизанных игр безбожно тормозит. Пробовал SW Squadrons и Project Wingman. Приходится резать разрешение. Но впечатление от полёта с физическим джойстиком-палкой потрясающее.
Кратко — всем. Например, нет части функционала в Outlook, нельзя прикрепить календарь справа третьей колонкой, медленный рендеринг и очень тормозной скролл в Excel. Вообще он крайне медленно работает на более менее крупных таблицах. В Power Point куча мелочей сделана плохо, местами нет галочек в списках, если галка не выбрана, попробуй догадаться, что они вообще есть и т.п. Это, кстати, по всем приложениям. Нет аппаратного ускорения рендеринга. Это прямо видно. Ощущение, что работаешь в версии 97 года с натянутой шкуркой 365. Всего не вспомнишь. Плюс нет Visio, Project (Боже упаси от него, правда) и прочих более редких программ.
Могу вам пожелать всю жизнь работать в офисе под мак. Я лично не выдержал, продал MacBook Pro и iMac и счастливо вернулся на форточки, где можно удобно работать. Это мой личный и узкий кейс, но тем не менее. Пользователей офиса очень много, но офисные приложения даже на айпаде удобнее. А есть ещё всякие средства проектирования, Visual Studio и т.п. Не каждая сова натягивается на яблочный глобус.
Речь именно про major и при таких изменениях я с вами не соглашусь.
Во-первых, все же не проще. Много маленьких микросервисов тестируются проще за счет независимости кодовых баз. Меньше периметр тестирования. Можно даже автотестами API по принципу черного ящика.
Во-вторых, на практике это невероятно дорого, т.к. нужно синхронизировать всех и провести общий регресс. А если команд 10? А если 100? Это никто не делает для плагинов/пакетов.
Возможно я экстремист и за последние 4-5 лет отвык от мира без непрерывной поставки и микросервисов, но я просто не могу представить, как сейчас можно писать новые проекты не в рамках MSA, если, конечно, хватает инженерных компетенций и ресурсов на первоначальные инвестиции. Т.е., ИМХО, монолит может быть оправдан только для хардкорного стартапа на самой ранней стадии или для проекта, который вообще не планируется масштабировать, т.к. уже через 3-4 месяца работы плюсы MSA начнут ощущаться.
А потом надо обновить ядро или версию платформы/фреймворка. Технически все просто, максимум кратковременная остановка обслуживания. Если вы не Google, то это не критично.
Но вам надо обновить до новой версии и все плагины сразу! Тут собака и зарыта. Если у вас несколько команд, то за отдельный плагины отвечают разные команды, т.е. вам надо одновременно остановить развитие бизнес функционала во всех командах одновременно. А у одной из них дедлайн и тормозить нельзя. Ситуация «приплыли, все ждут». Особенно весело, когда вам надо обновиться, чтобы утечки памяти на уровне фреймворка устранить или похожее веселье. В итоге обновление превращается в совершенно адовый процесс, который стараются делать как можно реже, лучше никогда. Даже по SAFe у вас будет 4 окна в конце PI в год. Вот тут и помогает гетерогенность инструментов не в части тут пишем на Ruby, тут на Java, а в части разных версий одной и той же платформы. Процесс обновления доедет в асинхронном режиме по разным сервисам не блокируя бизнес. Это тоже стоит менеджерских усилий, но несоизмеримо меньших.
На мой скромный взгляд тут архитектура приложения вплотную сталкивается с «синхронизацией процесса разработки», а как говорят умные люди, корпоративная архитектура равна сумме ИТ и бизнес архитектур.
Естественно это работает для проектов достаточно крупного размера и мои замечания нерелевантны для команды в 5 человек, но в энтерпрайзе выбора пилить монолит давно уже просто нет.
Парадоксально, но производительность на микросервисах достигается проще. Можно тривиально не писать на диск, а в сеть, чтобы запись делал другой сервис. Это очевидно гораздо быстрее. Надежность достигается, например, работой через брокеры сообщений с механизмом гарантии доставки, типа того же RabbitMQ. При этом, в том коде, который считает логику нет лишнего кода и нет издержек на скорость запуска и размер приложения. Аналогично в том, который пишет. Если что, у меня есть практический опыт построения подобных решений с аптаймом в несколько лет с весьма серьезной нагрузкой.
Риск несовместимости можно минимизировать кучей способов, начиная с банальных тестов API.
И в статье также ничего нет про убойные фичи контейнеризованных сред, которые работают вокруг микросервисов. Sidecar это киллер фича. При грамотном проектировании код начинает переиспользоваться для приложений на разных технических стеках. Можно, например, вынести логирование в отдельный сервис и обновлять его не затрагивая бизнес код. Этакое распределенное АОП.
SAFe очень медленный и дорогой фреймворк, применяемый для работы с кучей унаследованных приложений, которые просто не поддерживают параллельную разработку несколькими командами, т.е. монолитов.
Если нужно что-то более мобильное и эффективное типа LeSS или Spotify, то вам нужны микросервисы. Без них реализовать вменяемое покрытие автотестами гораздо сложнее. Потом вы ловите проблему атомарных релизов (одна фича, один релиз). Даже при наличии хорошего покрытия монолита вы попадаете в ситуацию очереди релизов и скорости релиза. Нормальной частью процесса является раскатка функционала и последующий мониторинг на наличие ошибок и проблем производительности под нагрузкой, т.е. некоторый период охлаждения. Если они проявились в промышленной среде, то релиз надо откатить. Сколько этот период должен длиться? Если час, то вы можете сделать 8 релизов за рабочий день максимум. Сколько релизов делает разработчик в день? У нас 1 релиз в 3 дня. Тут мы получаем 24 разработчика в команде максимум и это крайне оптимистично. По факту охлаждение надо делать больше и предел команды меньше.
Что происходит при превышении этого предела? Начинаются релизные поезда и merge кучи фич в одну ветку релизный кандидат. Из неё фиг выкинешь фичу с ошибками. Начинается циклический хотфикс-тест-хотфикс. Тут, по нашим расчетам, мы теряем до трети пропускной способности команды.
Микросервисы это решают тем, что компоненты развертываются независимо и охлаждение у них независимое. Естественно есть куча способов снижения стоимости и рисков, но только за счёт этого окупается любая вменяемая сложность автоматизации инфраструктуры.
Ключевое, что битовую маску нельзя писать строкой как есть, иначе не будет никакой экономии, надо использовать Base64 сериализацию. Тратить байт на один бит это дорого, а в строковом представлении на каждый 1 или 0 будет уходить байт (кодировка заголовков ANSI).
Спасибо за конструктивный коментарий и быструю реакцию.
Статья автоматом получает минус за отсутствие "ката". Банальное неуважение к читателям.
Музыка доступна как отдельное приложение. Речь про «комбайн» в навигаторе, не более.
На самом деле, проблема разграничения доступов вообще была последней, о которой думали на старте, не говоря о том, что в 2015-м этой фичи не было.
Два основных кошмара — отслеживание зависимостей на уровне файловой системы. Многие до сих пор это любят, как показывает общение с коллегами. Заставить разработчика работать через пакеты в одном репозитории очень тяжелая задача.
Вторая проблема — корректное отслеживание изменений, в каком компоненте что поменялось и с какой версией ее надо пересобрать и т.п. На маленьких отдельных репозиториях это делать было гораздо проще. Единая версия на репозиторий с несколькими компонентами это вообще жесткий антипаттерн.
На практике это оказалось удобно, далее шла эволюция.
В соседней ветке уточнили, что речь шла про диоптрии. Тут я маху дал.
Согласен. Но тогда нужно ещё большее нативное разрешение шлему, т.к. сейчас 50% мало, а промежуточные мылят.
Спасибо за уточнение. Тут я не специалист. Имел в виду именно диоптрии. Шлем текущим идеальным зрением воспринимается как раз как очки на -1,5 при -2,5 на глазах.
Угол у него явно лучше чем у Rift S и Quest. Прямо ощутимо лучше. Обзоры, которые говорят про его узость, похоже делали люди с какой-то другой анатомией, чем у меня. Но мне и Rift S совершенно нормально был.
На таблицах для проверки зрения в России:
1 — идеальное зрение
В интервале 0-1 можно считать нормальным. Можно спокойно водить без очков.
С новыми VR шлемами типа Quest 2 и Reverb G2 вообще беда с производительностью. Как обладатель связки 5800X + 3080 и обоих шлемов могу сказать, что с одной стороны прямо расстроен, с другой восхищён.
Восхищён я уровнем картинки. Reverb G2 воспринимается на уровне зрения около нуля по нашей системе, когда 1 это идеальное. Говорю как человек, сделавший коррекцию с -2,5, до +1 и до этого переживший плавное падение. Т.е. в 90% случаев вы даже не будете знать, что у вас была деградация зрения. Цвета, чёткость, все блеск. Кино в нем выглядит как будто в imax смотришь. До физического предела человеческого зрения осталось очень не много. Rift S воспринимается теперь как кино на качественном VHS против Blu-ray. Quest 2 непринципиально хуже по разрешению, но проигрывает по цветам и яркости, зато беспроводной.
Расстроен я тем, что с таким уровнем картинки 3080 тупо не хватает. И не на проценты, а кратно. Если HL: Alyx играбелен на ультрах на 90 герц (около 110 fps), то большинство не настолько вылизанных игр безбожно тормозит. Пробовал SW Squadrons и Project Wingman. Приходится резать разрешение. Но впечатление от полёта с физическим джойстиком-палкой потрясающее.
Кратко — всем. Например, нет части функционала в Outlook, нельзя прикрепить календарь справа третьей колонкой, медленный рендеринг и очень тормозной скролл в Excel. Вообще он крайне медленно работает на более менее крупных таблицах. В Power Point куча мелочей сделана плохо, местами нет галочек в списках, если галка не выбрана, попробуй догадаться, что они вообще есть и т.п. Это, кстати, по всем приложениям. Нет аппаратного ускорения рендеринга. Это прямо видно. Ощущение, что работаешь в версии 97 года с натянутой шкуркой 365. Всего не вспомнишь. Плюс нет Visio, Project (Боже упаси от него, правда) и прочих более редких программ.
Могу вам пожелать всю жизнь работать в офисе под мак. Я лично не выдержал, продал MacBook Pro и iMac и счастливо вернулся на форточки, где можно удобно работать. Это мой личный и узкий кейс, но тем не менее. Пользователей офиса очень много, но офисные приложения даже на айпаде удобнее. А есть ещё всякие средства проектирования, Visual Studio и т.п. Не каждая сова натягивается на яблочный глобус.
Во-первых, все же не проще. Много маленьких микросервисов тестируются проще за счет независимости кодовых баз. Меньше периметр тестирования. Можно даже автотестами API по принципу черного ящика.
Во-вторых, на практике это невероятно дорого, т.к. нужно синхронизировать всех и провести общий регресс. А если команд 10? А если 100? Это никто не делает для плагинов/пакетов.
Возможно я экстремист и за последние 4-5 лет отвык от мира без непрерывной поставки и микросервисов, но я просто не могу представить, как сейчас можно писать новые проекты не в рамках MSA, если, конечно, хватает инженерных компетенций и ресурсов на первоначальные инвестиции. Т.е., ИМХО, монолит может быть оправдан только для хардкорного стартапа на самой ранней стадии или для проекта, который вообще не планируется масштабировать, т.к. уже через 3-4 месяца работы плюсы MSA начнут ощущаться.
Но вам надо обновить до новой версии и все плагины сразу! Тут собака и зарыта. Если у вас несколько команд, то за отдельный плагины отвечают разные команды, т.е. вам надо одновременно остановить развитие бизнес функционала во всех командах одновременно. А у одной из них дедлайн и тормозить нельзя. Ситуация «приплыли, все ждут». Особенно весело, когда вам надо обновиться, чтобы утечки памяти на уровне фреймворка устранить или похожее веселье. В итоге обновление превращается в совершенно адовый процесс, который стараются делать как можно реже, лучше никогда. Даже по SAFe у вас будет 4 окна в конце PI в год. Вот тут и помогает гетерогенность инструментов не в части тут пишем на Ruby, тут на Java, а в части разных версий одной и той же платформы. Процесс обновления доедет в асинхронном режиме по разным сервисам не блокируя бизнес. Это тоже стоит менеджерских усилий, но несоизмеримо меньших.
На мой скромный взгляд тут архитектура приложения вплотную сталкивается с «синхронизацией процесса разработки», а как говорят умные люди, корпоративная архитектура равна сумме ИТ и бизнес архитектур.
Естественно это работает для проектов достаточно крупного размера и мои замечания нерелевантны для команды в 5 человек, но в энтерпрайзе выбора пилить монолит давно уже просто нет.
Парадоксально, но производительность на микросервисах достигается проще. Можно тривиально не писать на диск, а в сеть, чтобы запись делал другой сервис. Это очевидно гораздо быстрее. Надежность достигается, например, работой через брокеры сообщений с механизмом гарантии доставки, типа того же RabbitMQ. При этом, в том коде, который считает логику нет лишнего кода и нет издержек на скорость запуска и размер приложения. Аналогично в том, который пишет. Если что, у меня есть практический опыт построения подобных решений с аптаймом в несколько лет с весьма серьезной нагрузкой.
Риск несовместимости можно минимизировать кучей способов, начиная с банальных тестов API.
И в статье также ничего нет про убойные фичи контейнеризованных сред, которые работают вокруг микросервисов. Sidecar это киллер фича. При грамотном проектировании код начинает переиспользоваться для приложений на разных технических стеках. Можно, например, вынести логирование в отдельный сервис и обновлять его не затрагивая бизнес код. Этакое распределенное АОП.
И забить на практику интеграционных системных демо
SAFe очень медленный и дорогой фреймворк, применяемый для работы с кучей унаследованных приложений, которые просто не поддерживают параллельную разработку несколькими командами, т.е. монолитов.
Если нужно что-то более мобильное и эффективное типа LeSS или Spotify, то вам нужны микросервисы. Без них реализовать вменяемое покрытие автотестами гораздо сложнее. Потом вы ловите проблему атомарных релизов (одна фича, один релиз). Даже при наличии хорошего покрытия монолита вы попадаете в ситуацию очереди релизов и скорости релиза. Нормальной частью процесса является раскатка функционала и последующий мониторинг на наличие ошибок и проблем производительности под нагрузкой, т.е. некоторый период охлаждения. Если они проявились в промышленной среде, то релиз надо откатить. Сколько этот период должен длиться? Если час, то вы можете сделать 8 релизов за рабочий день максимум. Сколько релизов делает разработчик в день? У нас 1 релиз в 3 дня. Тут мы получаем 24 разработчика в команде максимум и это крайне оптимистично. По факту охлаждение надо делать больше и предел команды меньше.
Что происходит при превышении этого предела? Начинаются релизные поезда и merge кучи фич в одну ветку релизный кандидат. Из неё фиг выкинешь фичу с ошибками. Начинается циклический хотфикс-тест-хотфикс. Тут, по нашим расчетам, мы теряем до трети пропускной способности команды.
Микросервисы это решают тем, что компоненты развертываются независимо и охлаждение у них независимое. Естественно есть куча способов снижения стоимости и рисков, но только за счёт этого окупается любая вменяемая сложность автоматизации инфраструктуры.