Как стать автором
Обновить
15
0
Stanislav Spiridonov @foal

Человек

Отправить сообщение

Для меня огромным преимуществом 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 в ассиметричном шифровании. Никто же не рассуждает о том, что делать в случае компрометации открытого ключа - бред же?

Для непонятливых - отпечаток пальца это открытая всем информация, её невозможно скомпрометировать, ну или считайте, что он изначально скомпрометирован :)

Отвечая на ваш вопрос - ничего делать не буду. Тут вопрос о доверии. И чётком понимании что мой (как и любой другой) отпечаток пальца уже сейчас, как вы говорите "спёрт".

Живите теперь с этим.

Не очень понимаю процесс.

  1. В разных системах (мой ноут, сейф на полке, входной замок, банк) информация о пальце хранится и обрабатывается по-разному. Нельзя украсть палец с входной двери и пройти в банк.

  2. Информация о пальце, даже если она и хранится на стороне сервера вам ничего не даст. Это открытая информация, для её получения не нужно ничего ломать - она есть на каждом стакане, который я трогал - её невозможно скомпрометировать по определению.

    Скажем так, я не вижу реальной возможности скомпрометировать палец. Есть уязвимости на уровне железок, но это скорее вопрос к конкретному сервису, а не идее аутентификации по пальцу.

Я вот как подсел на GWT так на нем и еду. Правда я больше по бакенду, поэтому мне Java на клиенте и нравится :)

Не могу сказать, что 11 вывела ОС на новый уровень

Вот мне тоже так казалось, а потом я был вынужден вернуться на 10 и тут я понял... Короче, пришлось менять ноут, чтобы вернутся на 11 :)

Наверное, потому что не было нужды запускать 30 с лишним копий, чтобы справится с нагрузкой. В странах, где нагрузка меньше вполне хватает 8-15 копий и этой проблемы нет.

Ну вообще-то функциональность Кафки не ограничивается шиной сообщений. Это не "лютая дичь". Например, Kafka Streams превосходно хранят свои состояния внутри самой Кафки. Наши потребности прекрасно укладываются в эту концепцию.

Что бы не причинять вам напрасную боль, могу пояснить, что и Mongo и ES и Redis не играют роль основных источников данных. Для этого у нас есть PostgreSQL. Но он довольно далеко - между ним и монолитом есть RabbitMQ, еще один слой на Java, потом RabbitMQ + еще Java, потом начинаются Mongo и ES и Redis и только потом монолит, о котором я писал :) И это только одна веточка (online), а есть еще B2B, отделения, автоматы (vending machine).

Что касается целостность то у бизнеса нет таких требований и раньше не было. То, что так было реализовано, реально не значит, что это нужно. Скорее это было следствие используемых технологий и большой концентрации данных в одном месте - ведь монолит это не только о коде, но и о данных. При редизайне системы до нас стало доходить, что данные можно разделить на разные независимые потоки с разными требованиями к целостности и сохранности данных.

Я думаю, что для монолита гораздо проще контролировать зависимости между модулями. Если каждый модуль - это отдельный проект, то зависимости между проектами явно прописаны.

Да, так можно делать, я сам для DAO (или сервисов) всегда создавал два модуля, один с интерфейсами, второй с реализацией. На второй зависимость со скопом runtime. Вот только часто вы такие проекты видели? Я нет.

Если у компании несколько автономных команд разработки.

Да, разговор именно о них. Стартапу заморачиваться с микросервисами (если только это не цель их идеи) нет смысла.

Да, вы правы. Очень часто некорректно сравнивают сложность монолита и отдельного микросервиса, в то время как надо сравнивать хотя бы монолит и экосистему всех микросервисов которые выполняют его функции. Вот только потенциал у второй сложной системы намного больше. Я с трудом представляю потенциальный ИИ, который можно прикрутить к управлению монолитом. В случае с микросервисами - легко.

Да! Но не изначально, а она накапливалась там годами, помноженными на количество разработчиков. Ведь тот же кэш надо было делать отдельным Hazelcast кластером, что сняло бы львиную долю нагрузки с сети и решило проблему с источниками данных. Но было сделано, что сделано, тогда это казалось разумным, а текущие требования к нагрузке никто не мог представить.

Вот только монолит не откатить лет на семь назад, чтобы легко поправить это. И таких проблем там не мало. Каждая ошибка (как и хорошее решение) в архитектуре за несколько лет обрастает кодом. И исправить её ой как не просто. А грубой силой исправить (масштабировать) этого монстрика ну очень сложно :)

Я еще добавлю - просмотра относительно статической информации. Плюс некритичной ко скорости обновления. Ваш новый вопрос/ответ может легко появится в общем доступе секунд через 20-30 после его добавления. Не удивлюсь, что и позже — это некритично для этого сервиса.

Хмм... Ну не знаю. У нас заказчики это бизнес, который зарабатывает деньги не на разработке софта. Его модой не приведёшь. Клиентам (B2С) важна бесперебойная работа приложений и отделений. Им пофиг на чем все это едет.

1
23 ...

Информация

В рейтинге
Не участвует
Откуда
Praha, Hlavni Mesto Praha, Чехия
Дата рождения
Зарегистрирован
Активность