На мой взгляд, каждый должен отвечать за себя, и в данном случае автору данной статьи, стоило сохранять бОльшую нейтральность, а не опускаться на уровень другого автора.
Представьте, какой-нибудь студент будет брать интервью у Uncle Bob'a, а тот будет ему отвечать, что тот вообще не рабирается в программировании и архитектуре, и должен сперва что-то сделать достойное, чем вообще разговаривать
PaulMaly, спасибо за статью. Получилось почти что неплохо. Но лично для меня
интересной и главное НЕ злой, представив все как некое подобие интервью автора оригинальной статьи со мной
в этом пункте вы полностью провалились. Ни разу не видел хорошего интервью, где интервьюируемый переходит на личности и оскорбления интервьюера. Как минимум поскольку последний чаще всего заведомо хуже разбирается в теме.
Если выкинуть все эти переходы на личности и эмоции с вашей стороны, то статья отличная
Я пошёл читать скинутую статью и возникли вопросы (посколько я ниразу не специалист):
trial drug that effectively blocks the cellular door SARS-CoV-2 uses to infect its hosts.
Тут написано, что блокируется клеточный вход через ACE2
Our new study provides very much needed direct evidence that a drug — called APN01 (human recombinant soluble angiotensin-converting enzyme 2 — hrsACE2) ...
А здесь, что просто добавляется в тело "растворимый" ACE2
Now we know that a soluble form of ACE2 that catches the virus away
(цитата ученого)
APN01 imitates the human ACE2. The virus binds to soluble ACE2/APN01 instead of ACE2 on the cell surface
А это уже другая статья, которая подтверждает предыдущий тезис
Получается, что лекарство не блокирует ничего, а просто "запутывает" вирус? Т.е. вместо того, чтобы внедриться в 100 клеток, вирус внедрится в 99 "частиц" нового лекарства, и в 1 клетку
Вопрос о % и что это не страшно, поднимался и обсуждался в т.ч. на хабре уже много раз:
Бабушкам и дедушкам не легче от того, что среди молодежи показатели завышены. У них бессимптомное течении болезни очень редко. И по ним показатели более менее реальны
Системе здравоохранения не легче от того, что относительные оценки сильно завышены. У них абсолютные значения превышают пропускную способность
Я сам категорично не воодушевлён карантином по ряду причин. И считаю, что его эффективность сильно ниже, чем пагубные последствия (в т.ч. для здоровья). Но это моя субъективная оценка и личное мнение. Я никому не предлагаю играться с цифрами и считать, что реально ничего плохого не происходит из-за вируса.
Но предлагаю не поднимать и обмусоливать одни и те же вопросы на хабре мильён раз.
Задача 8 ад. Ответил неправильно и долго не мог понять, чем другие локи не угодили.
Через 5 минут увидел, что поле то public. Не, это серьёзно? Сейчас ещё есть люди, кто на автомате все поля private/protected/package private не делает?
Ну т.е. использование synchronizedList и не-создание копии входящего списка, видимо, было мало для bad practice
И после таких вопросов:
Сделать шаг к вершине и прокачаться на интересных задачах ты можешь в команде НСПК.
Угу, проблема в том, что в 99% случаев, все называют главной проблемой монолита — сильная связанность кода (например половина пунктов из коммента ниже).
Что не имеет совершенно ничего общего с монолитом. Можно иметь такую же связанность кода и на микросервисах. А можно разбить всё на независимые модули в рамках одного монолита и тем самым решить бОльшую часть проблем.
И лично я согласен с автором предыдущего коммента: по мне хорошо организованный монолит это лучше чем зоопарк технологий.
Но я согласен и с вами, в довольно больших проектах, монолит тоже приведёт к страданиям. Если вам требуется больше нескольких запущенных инстансов монолита и у вас очень много функциональности
Как всегда, вопрос баланса: микросервисы это дороже и сложнее, поэтому их есть смысл выбирать, только когда это действительно обосновано. А не когда люди банально не умеют писать модули или хотят поиграться с новой технологией
Нельзя взять отдельное предложение из текста и сказать, что статья о нём
значит каждый из нас понимает статью, event sourcing и event driven архитектуры по-разному. По-моему статья именно об этом.
Но мне кажется у нас черезчур разное понимание этих вещей. И в комментариях хабра, мы будем слишком долго приходить к общему пониманию, поэтому предлагаю остаться при своих мнениях :)
В любом случае спасибо за разговор и буду очень признателен, если ещё поделитесь ссылочками на статьи/презентации об архитектуре, про которую вы говорите. Учиться тому, что не знаешь или не понимаешь, всегда полезно
Не объём, а "в объёме" — стандартный речевой оборот.
понял, спасибо, прошу прощения!
Да боже упаси
так и статья о том же. "События Event Sourcing не должны выдаваться наружу во внешний мир!"
Важный момент, тут речь не о запросах (я про "Сложный запрос занырнул в брокер"), а о событиях. Внешние события определяются отправителем и от получателя не зависят (т.к. отправителю все равно, сколько получателей есть, кто они, и есть ли вообще).
В мысленном эксперименте выше про "событие изменения реквизитов пользователя": кто должен подгонять это событие под "ровно в том объеме, в котором он ожидает"? Отправитель? Или вы же говорите о промежуточном слое трансляторов, типа Apache Camel?
не совсем понял эту фразу. Как можно понимать объём?
С каких пор в нормальных реализациях event-driven архитектур он знает о чём-то большем чем брокер сообщений?
Он знает структуру данных в сообщении (какие поля должны быть).
И эта структура та же самая, что и используется сервисом-отправителем внутри своего собственного event store
Проблема не в том, что другой сервис "знает" реализацию вашего хранилища. А в том, что вы неявно, но жестко связываете структуру данных в своем хранилище и АПИ
И, если, например, вы захотите скрыть какие-то поля от внешних сервисов, это не получится. Можно скрывать только отдельные типы событий, но это не настолько гранулярно
Вы правы, что возможны два варианта, но в контексте статьи об Event Sources, всё же подразумевается именно второй вариант (лог событий). На картинке это Event Sourcing Event
А первый вариант автор предлагает как решение проблемы. Соответственно на картинке это Domain Event
События в EventSourcing это по факту (единственное*) хранилище. Кроме событий, вы больше ничего не храните и текущее состояние данных это результат воспроизведения всех событий по одному.
Например, ваш event store для сервиса пользователей выглядит следующим образом:
Событие1: ФИО пользователя Х изменено на "Иванов Иван Иваныч"
Событие2: Возрас пользователя Х изменен на 25
И тут мы решаем в этом сервисе изменить ФИО на фамилию, имя отчество, и исправить опечатку "возрас" на "возраст"
Локально код поменяли, старые события не трогаем (это же хистори, не принято), поэтому сделали беквард компатибл, и поехали стали слать новые события
Тут в наш event store попадает
Событие 3: Пользователь Х. Возраст 30, Фамилия Сидоров
С точки зрения сервиса пользователей, всё в порядке, все поля ожидаемые.
Но как к этому событию должен отнестись сторонний сервис? Он ничего ни про "фамилию", ни про "возраст" не знает. И не сможет распарсить новый формат событий
Каким образом публикуя событие я раскрываю свой уровень хранения?
События = ваш способ хранения данных. Сохраняя события (и ничего кроме них), и потом выставляя эти же самые события наружу, вы полностью связываете своё хранилище и API
Но надо признать, что подобная проблема есть и у многих REST/CRUD/ORM приложений. Завели entity, и она одновременно используется как для внутреннего хранения, так и для REST API. С одной стороны удобно, с другой стороны уже нельзя просто так взять и что-то оптимизировать в работе с БД.
* очень часто дополнительно к событиям делают materialized view/snapshot/cache, для увеличения производимости. Но все они могут быть выкинуты и построены заново исходя из очереди событий.
Тогда ошибка будет другой (не Array access) и только в случае, если параметр помечен как @NotNull (либо на основе анализа Идея догадается, что он должен быть не null)
Хм, непонятно, почему решили сделать с объявлением дополнительной переменной (myVar instanceof String str)
В котлине, насколько я знаю, можно просто с изначальной переменной дальше работать, будто она этого типа
В JEP про это написано: мы не хотим ad hoc а хотим pattern matching. Но имхо это странно — усложнять имеющийся синтакс ради потенциальной новой фичи, которая может быть ещё совершенно иначе будет реализована
Да ещё и на ровном месте добавлять смесь проблем с перекрытием переменных и умных условий
Ради интереса: а почему именно толстого и почему именно JVM? Кажется сейчас мир движется в сторону технологий типа электрона. И, на мой взгляд, это имеет смысл, т.к. фронт-енд девелоперам привычнее и интереснее писать UI, чем джавистам/дотнетчикам и т.п.
В прошлой компании я поработал полгода с Java FX, и не назвал бы этот опыт строго положительным. Есть много плюсов по сравнению со Swing (bindings, "css", получше выглядит), но в целом помедленнее, побольше багов и некоторые вещи тяжело кастомизируются.
И, при возможности, я бы для проектов выбирал всякие электроны для десктопов, чем java FX. По крайней мере с точки зрения скорости и удобства разработки.
(удалено, дубликат)
Я не защищаю оригинальную статью.
На мой взгляд, каждый должен отвечать за себя, и в данном случае автору данной статьи, стоило сохранять бОльшую нейтральность, а не опускаться на уровень другого автора.
Представьте, какой-нибудь студент будет брать интервью у Uncle Bob'a, а тот будет ему отвечать, что тот вообще не рабирается в программировании и архитектуре, и должен сперва что-то сделать достойное, чем вообще разговаривать
PaulMaly, спасибо за статью. Получилось почти что неплохо. Но лично для меня
в этом пункте вы полностью провалились. Ни разу не видел хорошего интервью, где интервьюируемый переходит на личности и оскорбления интервьюера. Как минимум поскольку последний чаще всего заведомо хуже разбирается в теме.
Если выкинуть все эти переходы на личности и эмоции с вашей стороны, то статья отличная
Я пошёл читать скинутую статью и возникли вопросы (посколько я ниразу не специалист):
Тут написано, что блокируется клеточный вход через ACE2
А здесь, что просто добавляется в тело "растворимый" ACE2
(цитата ученого)
А это уже другая статья, которая подтверждает предыдущий тезис
Получается, что лекарство не блокирует ничего, а просто "запутывает" вирус? Т.е. вместо того, чтобы внедриться в 100 клеток, вирус внедрится в 99 "частиц" нового лекарства, и в 1 клетку
Я правильно понял?
ПС за термины прошу строго не судить
Почитать можно здесь
https://twitter.com/WHO/status/1240409217997189128
https://www.meduniwien.ac.at/web/en/about-us/news/detailsite/2020/news-im-maerz/alleged-research-results-of-the-wiener-uniklinik-around-the-covid-19-virus-are-fake-news/
Только почитать, наверно, нужно не вам, а товарищу сверху.
Т.к. инфа фейк
Вопрос о % и что это не страшно, поднимался и обсуждался в т.ч. на хабре уже много раз:
Я сам категорично не воодушевлён карантином по ряду причин. И считаю, что его эффективность сильно ниже, чем пагубные последствия (в т.ч. для здоровья). Но это моя субъективная оценка и личное мнение. Я никому не предлагаю играться с цифрами и считать, что реально ничего плохого не происходит из-за вируса.
Но предлагаю не поднимать и обмусоливать одни и те же вопросы на хабре мильён раз.
Задача 8 ад. Ответил неправильно и долго не мог понять, чем другие локи не угодили.
Через 5 минут увидел, что поле то
public. Не, это серьёзно? Сейчас ещё есть люди, кто на автомате все поля private/protected/package private не делает?Ну т.е. использование
synchronizedListи не-создание копии входящего списка, видимо, было мало для bad practiceИ после таких вопросов:
Очень интересные задачи.
Мукачайтесь с ними самиУгу, проблема в том, что в 99% случаев, все называют главной проблемой монолита — сильная связанность кода (например половина пунктов из коммента ниже).
Что не имеет совершенно ничего общего с монолитом. Можно иметь такую же связанность кода и на микросервисах. А можно разбить всё на независимые модули в рамках одного монолита и тем самым решить бОльшую часть проблем.
И лично я согласен с автором предыдущего коммента: по мне хорошо организованный монолит это лучше чем зоопарк технологий.
Но я согласен и с вами, в довольно больших проектах, монолит тоже приведёт к страданиям. Если вам требуется больше нескольких запущенных инстансов монолита и у вас очень много функциональности
Как всегда, вопрос баланса: микросервисы это дороже и сложнее, поэтому их есть смысл выбирать, только когда это действительно обосновано. А не когда люди банально не умеют писать модули или хотят поиграться с новой технологией
значит каждый из нас понимает статью, event sourcing и event driven архитектуры по-разному. По-моему статья именно об этом.
Но мне кажется у нас черезчур разное понимание этих вещей. И в комментариях хабра, мы будем слишком долго приходить к общему пониманию, поэтому предлагаю остаться при своих мнениях :)
В любом случае спасибо за разговор и буду очень признателен, если ещё поделитесь ссылочками на статьи/презентации об архитектуре, про которую вы говорите. Учиться тому, что не знаешь или не понимаешь, всегда полезно
понял, спасибо, прошу прощения!
так и статья о том же. "События Event Sourcing не должны выдаваться наружу во внешний мир!"
Важный момент, тут речь не о запросах (я про "Сложный запрос занырнул в брокер"), а о событиях. Внешние события определяются отправителем и от получателя не зависят (т.к. отправителю все равно, сколько получателей есть, кто они, и есть ли вообще).
В мысленном эксперименте выше про "событие изменения реквизитов пользователя": кто должен подгонять это событие под "ровно в том объеме, в котором он ожидает"? Отправитель? Или вы же говорите о промежуточном слое трансляторов, типа Apache Camel?
не совсем понял эту фразу. Как можно понимать объём?
Он знает структуру данных в сообщении (какие поля должны быть).
И эта структура та же самая, что и используется сервисом-отправителем внутри своего собственного event store
Проблема не в том, что другой сервис "знает" реализацию вашего хранилища. А в том, что вы неявно, но жестко связываете структуру данных в своем хранилище и АПИ
И, если, например, вы захотите скрыть какие-то поля от внешних сервисов, это не получится. Можно скрывать только отдельные типы событий, но это не настолько гранулярно
Вы правы, что возможны два варианта, но в контексте статьи об Event Sources, всё же подразумевается именно второй вариант (лог событий). На картинке это Event Sourcing Event
А первый вариант автор предлагает как решение проблемы. Соответственно на картинке это Domain Event
События в EventSourcing это по факту (единственное*) хранилище. Кроме событий, вы больше ничего не храните и текущее состояние данных это результат воспроизведения всех событий по одному.
Например, ваш event store для сервиса пользователей выглядит следующим образом:
И тут мы решаем в этом сервисе изменить ФИО на фамилию, имя отчество, и исправить опечатку "возрас" на "возраст"
Локально код поменяли, старые события не трогаем (это же хистори, не принято), поэтому сделали беквард компатибл, и поехали стали слать новые события
Тут в наш event store попадает
С точки зрения сервиса пользователей, всё в порядке, все поля ожидаемые.
Но как к этому событию должен отнестись сторонний сервис? Он ничего ни про "фамилию", ни про "возраст" не знает. И не сможет распарсить новый формат событий
События = ваш способ хранения данных. Сохраняя события (и ничего кроме них), и потом выставляя эти же самые события наружу, вы полностью связываете своё хранилище и API
Но надо признать, что подобная проблема есть и у многих REST/CRUD/ORM приложений. Завели entity, и она одновременно используется как для внутреннего хранения, так и для REST API. С одной стороны удобно, с другой стороны уже нельзя просто так взять и что-то оптимизировать в работе с БД.
* очень часто дополнительно к событиям делают materialized view/snapshot/cache, для увеличения производимости. Но все они могут быть выкинуты и построены заново исходя из очереди событий.
Тогда ошибка будет другой (не
Array access) и только в случае, если параметр помечен как@NotNull(либо на основе анализа Идея догадается, что он должен быть не null)Интересный пример, но "такой проблемы нет" только в случае атомарности оператора?
Я, к сожалению, не нашел ничего про concurrency в pattern matching
Логично, спасибо
Хм, непонятно, почему решили сделать с объявлением дополнительной переменной
(myVar instanceof String str)В котлине, насколько я знаю, можно просто с изначальной переменной дальше работать, будто она этого типа
В JEP про это написано: мы не хотим ad hoc а хотим pattern matching. Но имхо это странно — усложнять имеющийся синтакс ради потенциальной новой фичи, которая может быть ещё совершенно иначе будет реализована
Да ещё и на ровном месте добавлять смесь проблем с перекрытием переменных и умных условий
Понятно, спасибо!
Ради интереса: а почему именно толстого и почему именно JVM? Кажется сейчас мир движется в сторону технологий типа электрона. И, на мой взгляд, это имеет смысл, т.к. фронт-енд девелоперам привычнее и интереснее писать UI, чем джавистам/дотнетчикам и т.п.
В прошлой компании я поработал полгода с Java FX, и не назвал бы этот опыт строго положительным. Есть много плюсов по сравнению со Swing (bindings, "css", получше выглядит), но в целом помедленнее, побольше багов и некоторые вещи тяжело кастомизируются.
И, при возможности, я бы для проектов выбирал всякие электроны для десктопов, чем java FX. По крайней мере с точки зрения скорости и удобства разработки.
Разумеется, такой выбор не всегда возможен.
Я с этим не спорю. Как по мне, 80% Мюнхена относительно серые и непрезентабельные.
Но фото, на котором 50% вокзала закрыто стройкой, не очень репрезентативно. Был бы просто вокзал (стремный, но без ремонта), вопросов бы не было