Для тех, кто не в курсе этим (auto.offset.reset) параметром определяется какое смещение Кафка будет использовать для новых консьюмеров (кто еще не имеет установленное смещение). Для уже существующих этот параметр игнорируется.
С цифрами спорить не буду. С выводами полностью не согласен - не упрощает и не улучшает. Это как в word отступы между абзацами не стилями форматировать, а добавлением новых строк.
Для меня огромным преимуществом MapStruct стало то, что с его помощью можно формально проверить комплектность (все нужные свойства) мапинга. Представьте приложение, которое читает данные с RabbitMQ записывает их до Redis и раздаёт потом через REST (несколько версий).
8 уровней мапирования :) Если я использую MapStruct то пре правильной настройке появление/удаление/(частично изменение) атрибута в RabbitMqObject приведёт к ошибке компиляции RabbitMqObject -> ApplicationModel и я буду вынужден решать эту проблему сразу как она возникнет.
Вы же сами писали, что изобретать свой язык запросов — это зло. Но абзацем ниже предложили именно это - свой язык, основанный на SQL.
Еще один камень преткновения — это то, что вы посылаете запрос как строчку. Строка — это хорошо для человека, но у вас же пользователь не будет писать запрос. Вы его кодом соберёте. А на стороне сервера кодом разберёте. А зачем? Ведь проще послать уже структурированный запрос, как у вас в начале JSON. И ошибок будет меньше, и код проще.
MqExtension - отличная вещь. В git мне её очень не хватает.
Довольно часто хочется иметь локальные изменения для версионных файлов, но не думать при коммите, что там по делу, а что локально для тебя. Так вот все эти вещи у меня в MQ хранились.
В общем вы правы. Но то, что Mercurial хранит весь граф модификаций иногда очень помогает. У меня есть форк проекта с GitHub (https://github.com/foal/gwt-time), структуру (не исходники) которого пришлось значительно изменить. Так вот git не может адекватно накатить изменения с оригинального проекта, а Mercurial легко. И это притом, что история коммитов просто идентична.
Вы абсолютно правильно подметили, что это открытые данные. И из этого вытекает, что их невозможно скомпрометировать. Все эти статьи - "ваш отпечаток могут узнать!" - яйца выеденного не стоят. Просто считайте изначально, что ваш отпечаток известен каждому. И решайте сами пользоваться этим или нет.
Уважаемый, вы все пытаетесь спорить, думая, что вам возражают :)
Что значит - "опасения, что палец сопрут". Нет! Его уже спёрли. И я уверен, что разработчики биометрических систем основываются на этом. А поэтому если вы доверяете конкретному экземпляру такой системы, то пользуйтесь на здоровье. Либо нет.
Но не надо кричать, что система безопасна, пока ваш отпечаток пальца в тайне, а потом беда-беда. Это ложь.
Просто считайте, что ваш отпечаток пальца это open key в ассиметричном шифровании. Никто же не рассуждает о том, что делать в случае компрометации открытого ключа - бред же?
Для непонятливых - отпечаток пальца это открытая всем информация, её невозможно скомпрометировать, ну или считайте, что он изначально скомпрометирован :)
Отвечая на ваш вопрос - ничего делать не буду. Тут вопрос о доверии. И чётком понимании что мой (как и любой другой) отпечаток пальца уже сейчас, как вы говорите "спёрт".
O! @tagir_valeevуже в переводе на Хабре :)
Мне голову сломал FORTH. До сих пор, как вспомню так вздрогну :)
Для тех, кто не в курсе этим (auto.offset.reset) параметром определяется какое смещение Кафка будет использовать для новых консьюмеров (кто еще не имеет установленное смещение). Для уже существующих этот параметр игнорируется.
https://helixteamhub.cloud/ Up to 1Gb free (https://www.perforce.com/products/helix-teamhub/free-account).
С цифрами спорить не буду. С выводами полностью не согласен - не упрощает и не улучшает. Это как в word отступы между абзацами не стилями форматировать, а добавлением новых строк.
Вот только он (google style) не ОБЩЕПРИНЯТ.
Really? А я уверен, что на табуляции. Точнее на табуляции для лидирующих отступов и пробелах для всего остального.
Это сарказм?
Для меня — это отказ от поддержки Java Annotation Processing. Плюс невозможность работы в Eclipse.
В Чехии есть, можно вернуть назад любой перевод в одно касание.
Для меня огромным преимуществом MapStruct стало то, что с его помощью можно формально проверить комплектность (все нужные свойства) мапинга. Представьте приложение, которое читает данные с RabbitMQ записывает их до Redis и раздаёт потом через REST (несколько версий).
RabbitMqObject -> ApplicationModel -> (RedisPersistance?) -> ApplicationModel -> REST1.0...REST5.0
8 уровней мапирования :) Если я использую MapStruct то пре правильной настройке появление/удаление/(частично изменение) атрибута в RabbitMqObject приведёт к ошибке компиляции RabbitMqObject -> ApplicationModel и я буду вынужден решать эту проблему сразу как она возникнет.
А как для копирование использовать ConEmu?
Вы же сами писали, что изобретать свой язык запросов — это зло. Но абзацем ниже предложили именно это - свой язык, основанный на SQL.
Еще один камень преткновения — это то, что вы посылаете запрос как строчку. Строка — это хорошо для человека, но у вас же пользователь не будет писать запрос. Вы его кодом соберёте. А на стороне сервера кодом разберёте. А зачем? Ведь проще послать уже структурированный запрос, как у вас в начале JSON. И ошибок будет меньше, и код проще.
MqExtension - отличная вещь. В git мне её очень не хватает.
Довольно часто хочется иметь локальные изменения для версионных файлов, но не думать при коммите, что там по делу, а что локально для тебя. Так вот все эти вещи у меня в MQ хранились.
На счет
rerereне знаю - не пробовал. У меня этот проект изначально был в Mercurial. А там все просто работает "из коробки".Сейчас то я в основном с Git работаю - так просто по жизни проще.
В общем вы правы. Но то, что Mercurial хранит весь граф модификаций иногда очень помогает. У меня есть форк проекта с GitHub (https://github.com/foal/gwt-time), структуру (не исходники) которого пришлось значительно изменить. Так вот git не может адекватно накатить изменения с оригинального проекта, а Mercurial легко. И это притом, что история коммитов просто идентична.
Вы абсолютно правильно подметили, что это открытые данные. И из этого вытекает, что их невозможно скомпрометировать. Все эти статьи - "ваш отпечаток могут узнать!" - яйца выеденного не стоят. Просто считайте изначально, что ваш отпечаток известен каждому. И решайте сами пользоваться этим или нет.
Уважаемый, вы все пытаетесь спорить, думая, что вам возражают :)
Что значит - "опасения, что палец сопрут". Нет! Его уже спёрли. И я уверен, что разработчики биометрических систем основываются на этом. А поэтому если вы доверяете конкретному экземпляру такой системы, то пользуйтесь на здоровье. Либо нет.
Но не надо кричать, что система безопасна, пока ваш отпечаток пальца в тайне, а потом беда-беда. Это ложь.
Просто считайте, что ваш отпечаток пальца это open key в ассиметричном шифровании. Никто же не рассуждает о том, что делать в случае компрометации открытого ключа - бред же?
Для непонятливых - отпечаток пальца это открытая всем информация, её невозможно скомпрометировать, ну или считайте, что он изначально скомпрометирован :)
Отвечая на ваш вопрос - ничего делать не буду. Тут вопрос о доверии. И чётком понимании что мой (как и любой другой) отпечаток пальца уже сейчас, как вы говорите "спёрт".
Живите теперь с этим.