С цифрами спорить не буду. С выводами полностью не согласен - не упрощает и не улучшает. Это как в 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 в ассиметричном шифровании. Никто же не рассуждает о том, что делать в случае компрометации открытого ключа - бред же?
Для непонятливых - отпечаток пальца это открытая всем информация, её невозможно скомпрометировать, ну или считайте, что он изначально скомпрометирован :)
Отвечая на ваш вопрос - ничего делать не буду. Тут вопрос о доверии. И чётком понимании что мой (как и любой другой) отпечаток пальца уже сейчас, как вы говорите "спёрт".
В разных системах (мой ноут, сейф на полке, входной замок, банк) информация о пальце хранится и обрабатывается по-разному. Нельзя украсть палец с входной двери и пройти в банк.
Информация о пальце, даже если она и хранится на стороне сервера вам ничего не даст. Это открытая информация, для её получения не нужно ничего ломать - она есть на каждом стакане, который я трогал - её невозможно скомпрометировать по определению.
Скажем так, я не вижу реальной возможности скомпрометировать палец. Есть уязвимости на уровне железок, но это скорее вопрос к конкретному сервису, а не идее аутентификации по пальцу.
Наверное, потому что не было нужды запускать 30 с лишним копий, чтобы справится с нагрузкой. В странах, где нагрузка меньше вполне хватает 8-15 копий и этой проблемы нет.
С цифрами спорить не буду. С выводами полностью не согласен - не упрощает и не улучшает. Это как в 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 в ассиметричном шифровании. Никто же не рассуждает о том, что делать в случае компрометации открытого ключа - бред же?
Для непонятливых - отпечаток пальца это открытая всем информация, её невозможно скомпрометировать, ну или считайте, что он изначально скомпрометирован :)
Отвечая на ваш вопрос - ничего делать не буду. Тут вопрос о доверии. И чётком понимании что мой (как и любой другой) отпечаток пальца уже сейчас, как вы говорите "спёрт".
Живите теперь с этим.
Не очень понимаю процесс.
В разных системах (мой ноут, сейф на полке, входной замок, банк) информация о пальце хранится и обрабатывается по-разному. Нельзя украсть палец с входной двери и пройти в банк.
Информация о пальце, даже если она и хранится на стороне сервера вам ничего не даст. Это открытая информация, для её получения не нужно ничего ломать - она есть на каждом стакане, который я трогал - её невозможно скомпрометировать по определению.
Скажем так, я не вижу реальной возможности скомпрометировать палец. Есть уязвимости на уровне железок, но это скорее вопрос к конкретному сервису, а не идее аутентификации по пальцу.
Я вот как подсел на GWT так на нем и еду. Правда я больше по бакенду, поэтому мне Java на клиенте и нравится :)
Вот мне тоже так казалось, а потом я был вынужден вернуться на 10 и тут я понял... Короче, пришлось менять ноут, чтобы вернутся на 11 :)
Наверное, потому что не было нужды запускать 30 с лишним копий, чтобы справится с нагрузкой. В странах, где нагрузка меньше вполне хватает 8-15 копий и этой проблемы нет.
Нет :)