Извиняюсь за глупый вопрос, но важен мне для дальнейшего понимания (а хочется понять что такое CallContext, ExecutionContext, не пользовал, и что решает AKKA.NET, но застреваю раньше). Вы пишите: «Наверное, это первое, что только может прийти в голову. Мы генерируем GUID, логируем этот GUID еще до выхода из action'а и передаем его в сервис работы с API.»
Мне первое что пришло в голову — генерировать ГУИД еще на клиенте и передовать его со всеми запросами в хттп хеадере. В таком случае его и возвращать не надо. Умер запрос (пусть по таймауту, пусть по коду «ждите»), следующий запрос в цикле уже с тем же гуидом. Вопрос всего лишь в обертке js ajax методов. Почему это не работает?
ClearCase — это 1992. В 98ом году он умел все тоже что и гит (и мне так кажется был даже более удобным). Но мерж в мастер был медленными очень. По часу. Чекины в свою песочницу тоже. Может по этому народ Version Control ограниченно использовал. Часто дело просто в хардваре.
Разве суть лучше всего не описало бы указание штатных средств развертывания и управления сервисами? А впечатление это не плохо, зря агритесь, просто ну что еще можно сформировать в голове слушателея говоря «у нас архитектура микросервисов». Фоулеру можно было бы поверить, но если включить режим скептика, а такие времена что он всё время включен, микросервисы тоже озанчают too many different things. И NoSql в конейнере и рдбмс вне контейнера (это стандартная рекомендация docker) всё микросервисы. И одинокий сервис генерации id вдали от монолита — тоже типа микросервис.
Я вас понял так — вы более хотите подчеркнуть область ваших интересов, а не точно описать архитектуру создаваемых систем. Опять же не ищите подвоха. Уважаю вас и ваш труд.
Практический вопрос: вот представляют мне систему и говорят «у нас она на микросервисках», какой вопрос задать, чтобы он не повисал в воздухе? Потому что «докер используете» обычно неприятно повисает (если докер не используется).
А можно спросить умных людей что кроется за фразой «разрабатывать SPA держа в уме SSR» или может быть статья есть классическая?
Чтобы говорить более конкретно пусть будет пример: дашборд каких-нибудь биржевых индексов. Первое что приходит на ум: роутинг, чтобы было удобно указывать что же именно попадает под SSR (личные кабинеты, даже если они публичны, не интересны SEO). Что-то еще?
Вот вы правильно сказали «делал SOA», это с 2005ого года. Это как раз то о чем я спросить хотел: когда отказываются от SOA описывая свой проект и выбирают описание microservices architecture что хотят подчеркнуть? Очевидно вычлеянется какой-то один самый важный и мне кажется технический аспект, поскольку впечатление хотят произвести на технарей. Да и «одна ответсвенность» — это сильно субъективно, но может так. Или что брендовой шины нет (BizTalk, TIbco)? Но в любом случае управление микросервисами возможно только каким-то штатным инструментом (а значит и упаковкой в штатные контейнеры), так почему просто не назвать этот штатный инструмент? Что «личное хранилище данных» (NoSQL, 2009)? Но опять же обычно есть нормальный дб сервер (не в контейнере) имитирующий эту самую шину. Как вам кажется, какой аспект самый важный?
Вопрос не много в сторону, но давно хотел задать кому-нибудь смелому… Так вот, до 2015 года (появления статьи microservices в wiki), или до 2014 года, одноименной статьи Martin Fowler или до 2013 года, первой версии Docker'а, как выглядили микросервисы и как вы их от просто web/rest services отличали (утверждаете что пишите с 2009 года)? Не ищите подвоха, просто хочу разобраться в терминологии, раньше не было никаких микросервисов — а теперь вроде как все проекты стали «с микросервисной архитектурой», а когда переспросишь «доккер что ли используете?» — не понимают связи вопроса, хотя для меня связь очевидна (на собственной правоте не настаиваю).
Спасибо за ответ. Хочу понять «возможность прозрачного запуска» в чем непрозрачность сейчас (с точки зрения штатных средств управления контейнерами) 2) «без какого-либо переключения, одновременно, всех типов… контейнеров» — фраза не понятна, может имеется ввиду переключение между штатными средствами управления «разными типами контейнеров»?
На сколько я понимаю штатные средства — скриптовые, то хотелось бы увидеть разницу в скриптах.
Хотелось бы чтобы статьи (эта и предудущая) начинались с качественного описания решаемой проблемы.
И еще хотелось бы чтобы Микрософт понял что Стасу Павлову надо помочь рости в понимании зачем он пишет.
П.С. В предыдущей статье было сказано «Docker для Windows и Linux в одной системе, что упростит сборку и тестирование гетерогенных приложений, состоящих из контейнеров Docker для обеих платформ.»
var source = transaction.ReadList<int, string, double>("SELECT id, type, weight FROM dbo.ITEM_VIEW");
foreach ( var (id, type, weight) in source)
{
//...
}
Я понимаю какие вопросы могут быть к такому Data Access Layer, и наверно ими можно оправдать замечания к языку «новые фичи которые огорчают», тем не мнее, программисты с удовольствием будут использовать кортежи где архитектура им это позволяет.
T1,T2,T3 тут примитивы, поэтому за фразой «как ты не меняй внутренности класса T1» я опять не вижу никакой реальной проблемы. если поменялся протокол потока (добавилось поле в считываемый рекордсет) то переписал и спецификацию считывания: было Tuple<T1,T2,T3> Read<T1,T2,T3>() стало Tuple<T1,T2,T3,T4> Read<T1,T2,T3,T4>() У интерфейса построенного на кортежах не может поплыть более чем у пользователе интерфейса построенного на class и dataadapter.
Я понимаю так, что ваша озадаченность, это вопрос: «а что вы потом с кортежем делать будете», и далее сами отвечате: «вот были бы классы могли бы вовне скинуть»! Ответ: во-первых если не уходит IReadResult во вне то зачем его объявлять (например потому что то к тому что мы считали, должны добавить четвертое поле dateTime — и это другой class), и во-вторых не всегда внешней системе нужны C# classы, например при сериализации в json во внешнюю систему уйдет {5,«typeA»,0.1123} в любом случае, сериализуйте вы instance class или tuple.
Я имел ввиду абстрактную функциональность ввода вывода, которая может возвратить разные кортежи разной длины. Семью функций T1 Read>T1>(), Tuple<T1,T2> Read<T1, T2>() ,Tuple<T1,T2,T3> Read<T1, T2,T3>() и т.д.
А так вы правы, что Reflection не обязателен, возможно чтобы вернуть IReadResult передавать еще и «DataAdapter», где руками прописать как порождать IReadResult из трех byte[]. Все же это будет сложнее, чем задать спецификацию через generic параметры.
Пришел в голову еще один арумент, если первая функция T1 Read >T1>() не вызывает паники то и остальные (с кортежами, типа Tuple<T1,T2,T3,T4> Read<T1,T2,T3,T4>() ) не должны, они просто логическое ее продолжение.
Логичные имена дать можно var (id, type, weight) = Read<int, string, double>(); а про замокать, отнаследовать и инкапсулировать — повторю, далеко не всем необходимо иметь возможность мокать, наследовать и инкапсулировать иммутабельные структуры данных.
«вводи класс, делай интерфейс»… интерфейс не нужен когда речь идет о структурных immutable типах, что касется классов в них тоже может не быть необходимости. Например на уровне абстрактных библиотек ввода/вывода: вы можете предоставлять пользователю возможность считать из потока три записи byte[] Read(), затем предлогая пользователю самому привести их к ожидаемым типам, а можете предоставлять возможность считать кортеж (задавая спецификацию приведения типов как generic параметры: Tuple<int, string, double> Read<int, string, double>() ). Тоже самое можно сделать и передавая через generic параметер любой class и используя reflection обойти его свойства, но на мой взгляд это будет гораздо более медленно, многословно и ненадежно. Неужели вы так и поступите?
Спасибо за ответ. Я правильно понимаю, что и Component Architecture и Use Case диаграммы интерактивны и из них грубо говоря кликами (напр. «Credit Card» для юзе кейсов, кстати диаграма компонент — пережата, я там ничего разобрать не могу), можно дойти до типов данных? Или эти слои Data Architecture, Technology Architecture, Component Architecture, Application Architecture и т.п. — есть разные репозитории (документы?) без возможности «гиперссылки» между ними?
Интересно, «типы данных» где описываются в таком каталоге (если описываются). В компонентах? Меня что озадачивает, что на уровне бизнес логики обычно пропадает, тот факт что представления бизнес объектов в разных системах кардинально отличаются. Например, болванка (бизнес-объект) отправленная на станок с точки зрния ERP имеет код, длину и вес, а с точки зрения датчиков станка — имеет только длину и вес. Аналитик/архитектор может легко забыться и придумать «а от сюда, от станка получаем код, длину и вес», хотя кода то нет. Причем даже «вес» и «длина» могут быть разными и даже не вопрос едениц измерения (например потому что станок взвешивает с какой-нибудь приваренной ерунденью).
Или подобные проблемы вообще не рашаются каталогами архитектуры?
Хотелось бы ссылку на статью описывающую эту функциональность ASP Core. Может знаете потолковей? Так на лету я не понял о чем речь, а о Core хочется знать поболее. Фетч это видимо Fetch api, но далее уже не понятно: «от которых зависит рендерер »… Фетч в броузере, рендерер Core (razor?) сервер сайд, что общего? И как может не зависить рендерер от фетчей (кто и как определяет)?
Вижу что Polymer задеприкейтил External stylesheets в компонентах, но это не тоже самое что HTML templates и мнение что JSимпорты могут заменить HTML templates — не вполне убедительно (статический html все же кажется непоколебимым столпом). Если я правильно Вас понял.
Но мнение — что Shadow Dom и HTML Template могут устареть быстрее react звучит убедительно. Спасибо.
Мне не хватает головы понять как изменятся реакт и ангулар с широкой поддержкой Shadow DOM и HTML templates броузерами. Angular поддерживает Shadow Dom но непонятно как с HTML templates. Если кто-то добавит свои соображения по этому пункту к статье — буду благодарен.
Уй ты божечки, тристотретий Савонарола призвался, а есть еще люди которым подобная пропроведь в новинку.
Я что скажу. Ходите по митапам, пейте ангельское пиво, работайте стоя, получайте удовольствие от работы, а если «сердце не лежит» — меняйте места, позиции, фрилансите под пальмой. Все ОК. Если рынок позволяет — пользуйтесь.
Спасибо. А можете помочь мне представить как это работает, как хэндлер/обработчик кому нужна синхронность (например для сериализации) себя поведет получив таск-
«асинхронный итереатор». И если неправильно, то разве это не получается leak abstraction?
Мне первое что пришло в голову — генерировать ГУИД еще на клиенте и передовать его со всеми запросами в хттп хеадере. В таком случае его и возвращать не надо. Умер запрос (пусть по таймауту, пусть по коду «ждите»), следующий запрос в цикле уже с тем же гуидом. Вопрос всего лишь в обертке js ajax методов. Почему это не работает?
Я вас понял так — вы более хотите подчеркнуть область ваших интересов, а не точно описать архитектуру создаваемых систем. Опять же не ищите подвоха. Уважаю вас и ваш труд.
Практический вопрос: вот представляют мне систему и говорят «у нас она на микросервисках», какой вопрос задать, чтобы он не повисал в воздухе? Потому что «докер используете» обычно неприятно повисает (если докер не используется).
Чтобы говорить более конкретно пусть будет пример: дашборд каких-нибудь биржевых индексов. Первое что приходит на ум: роутинг, чтобы было удобно указывать что же именно попадает под SSR (личные кабинеты, даже если они публичны, не интересны SEO). Что-то еще?
Спасибо. Уровень Дидро. Перенесите в ру википедию целиком.
На сколько я понимаю штатные средства — скриптовые, то хотелось бы увидеть разницу в скриптах.
И еще хотелось бы чтобы Микрософт понял что Стасу Павлову надо помочь рости в понимании зачем он пишет.
П.С. В предыдущей статье было сказано «Docker для Windows и Linux в одной системе, что упростит сборку и тестирование гетерогенных приложений, состоящих из контейнеров Docker для обеих платформ.»
Можно ли рассказать в чем упрощение?
Я понимаю какие вопросы могут быть к такому Data Access Layer, и наверно ими можно оправдать замечания к языку «новые фичи которые огорчают», тем не мнее, программисты с удовольствием будут использовать кортежи где архитектура им это позволяет.
Я понимаю так, что ваша озадаченность, это вопрос: «а что вы потом с кортежем делать будете», и далее сами отвечате: «вот были бы классы могли бы вовне скинуть»! Ответ: во-первых если не уходит IReadResult во вне то зачем его объявлять (например потому что то к тому что мы считали, должны добавить четвертое поле dateTime — и это другой class), и во-вторых не всегда внешней системе нужны C# classы, например при сериализации в json во внешнюю систему уйдет {5,«typeA»,0.1123} в любом случае, сериализуйте вы instance class или tuple.
А так вы правы, что Reflection не обязателен, возможно чтобы вернуть IReadResult передавать еще и «DataAdapter», где руками прописать как порождать IReadResult из трех byte[]. Все же это будет сложнее, чем задать спецификацию через generic параметры.
Пришел в голову еще один арумент, если первая функция T1 Read >T1>() не вызывает паники то и остальные (с кортежами, типа Tuple<T1,T2,T3,T4> Read<T1,T2,T3,T4>() ) не должны, они просто логическое ее продолжение.
Логичные имена дать можно var (id, type, weight) = Read<int, string, double>(); а про замокать, отнаследовать и инкапсулировать — повторю, далеко не всем необходимо иметь возможность мокать, наследовать и инкапсулировать иммутабельные структуры данных.
Или подобные проблемы вообще не рашаются каталогами архитектуры?
Но мнение — что Shadow Dom и HTML Template могут устареть быстрее react звучит убедительно. Спасибо.
Я что скажу. Ходите по митапам, пейте ангельское пиво, работайте стоя, получайте удовольствие от работы, а если «сердце не лежит» — меняйте места, позиции, фрилансите под пальмой. Все ОК. Если рынок позволяет — пользуйтесь.
«асинхронный итереатор». И если неправильно, то разве это не получается leak abstraction?