В реальной жизни у этого класса будет хотя бы один метод, что не даст подставить пустой объект.
Более того, даже и не пустой объект с полем foo можно туда положить - и он всё равно будет не ClassFoo. Потому instanceof проверяет именно JS-ный прототип, что крайне странно для TS, с моей точки зрения, но, тем не менее, является визуальным противоречием.
Странно потому, что зачем нам проверять тип класса, если надо важно его содержимое, относительно которого прекрасно проходят все проверки.
Преступник в вакууме одинаково угрожает как ребёнку, так и старушке. Если мы оцениваем среднюю безопасность всех жителей - то 1 преступник на 100 жителей причинит конкретному жителю в среднем больше ущерба за год, чем 1 на 1 000 000.
Если мы оцениваем склонность жителей к сознательным криминальным поступкам то, конечно, несознательных априори мы должны исключить.
Для "плановой экономики" как раз статистика и первостепенна. На основе неё строится и проверяется корректность выполнения плана.
А так статистику хоть с планом, хоть без плана можно дорисовывать и доинтерпретировать. Любой мэр даже без плана с большей радостью заявит о "трёхкратном падении преступности".
Если мы оцениваем безопасность в целом - то, конечно, надо брать всё население, от мала до велика. Т.е. соотношение бандитов к количеству потенциальных жертв.
Если оцениваем среднюю уголовную наклонность сознательных дееспособных граждан - конечно, надо брать другое количество.
Как техническое средство, естественно, кафка для синхронного взаимодействия подходит не так хорошо, как непосредственный сетевой вызов. Поэтому, "некостыльно" - наверное, не могу.
Но тем не менее, как раз при "архитектурных" решениях типа "везде делаем кафку" эти костыли, при логической необходимости синхронного взаимодействия, будут возникать.
Непосредственно отвечая на вопрос - самый банальный вариант отправлять сообщение и входить бесконечный цикл, ожидая некоего ответного сообщения, прежде, чем возобновить поток управления.
Restful, в отличие от сокетов, не техническая, а логическая концепция. И когда мы размышляем, как будем воплощать ту или иную прикладную область в реализацию - естественно, мы начинаем с модели взаимодействия данных. И дальше на основании этой модели внедряем подходящие технологии.
Это не самоцель, это выбор, на основании которого надо принимать дальнейшие решения.
Как написали ниже - конечно, без всяких протофайлов можно сериализовывать, не сложнее, чем обычный json, те же атрибуты.
Чтобы использовать RESTful стиль взаимодействия с преимуществами малого объёма передаваемых данных.
Упоминать надо, поскольку на моей практике часто люди, вместо того, чтобы точечно решить проблемы с этим объёмом, начинают переделывать вообще всё на grpc.
Преимущества и недостатки gRPC изначально связаны с парадигмой взаимодействия.
Если предполагается restful взаимодействие с понятной предметной областью - то классический Rest однозначно лучше. В его соглашениях все взаимодействия описаны, и есть много средств, успешно их использующих.
А если требуется RPC в произвольной форме - тогда, конечно, grpc на данный момент в общем случае самый логичный первый выбор.
P.S. Очень жаль, что не рассказали о том, что протобаф доступен без всякого grpc и протофайлов как форматтер в "обычном" рест-взаимодействии. Может сложиться впечатление, что для решения всех описанных проблем обязательно тянуть весь grpc.
Я бы поспорил, что объяснительная часть важнее. Какой интерес просто так объяснять (т.е. придумывать некое явно не наблюдаемое обоснование) тому, что уже произошло в непосредственном наблюдении.
Как раз интерес в предсказании новых непосредственно ощущаемых фактов, для которых объяснение есть всего лишь проверка корректности теории.
Я бы сформировал вокруг человека соответствующее командное отношение. Т.е. дал бы понять команде, что перед нами негативный пример (с точки зрения моего видения команды как её руководителя), самому товарищу, естественно, так же — что в нашей команде подобный подход является недопустимым (при этом дав понять, что всё поправимо). Есть много способов сделать вышеозначенное — от стиля общения до материальных поощрений.
Далее бы уже решала личная мотивация сотрудника. Если уволится — значит, уволится. Если качество провалится ниже — значит сами уволим. Исправится или впишется в некий другой круг обязанностей, где его сильные качества проявятся лучше — замечательно.
Там много всего произошло, и начинать надо, по мнению некоторых историков, не с ВОСР (которая готовилась большой группой товарищей, как раз проводивших внутри себя демократические процедуры), а 1905-го, если не с отмены крепостного права. Группа большевиков подхватила и направила революционный процесс в нужное (им) русло, а не сформировала его.
У Пучкова на канале интересный курс лекций Яковлева о предпосылках и ходе революции и ГВ. Рекомендую.
Я имел в виду, что для жителей страны правящий класс национально-ориентированного капитала лучше, чем далёкий дистанционно класс империалистов, использующих их как колонию (т.е., заинтересованных не больше, чем нужно для быстрой выкачки ресурсов и сбыта товаров). Понятно что тратили, на внешнюю политику все тратят.
Его ещё в 21 разрешили. НЭП, называется. Правда, с его свёртыванием, многое национализировалось, тем не менее, жёстко плановым в СССР было далеко не всё.
B->C нельзя построить из A->C и A->B. Придётся писать новую функцию.
Точно так же, как и для каждой новой трансформации универсального объекта в вашем примере.
TypeScript: худший лучший язык программирования
Более того, даже и не пустой объект с полем foo можно туда положить - и он всё равно будет не ClassFoo. Потому instanceof проверяет именно JS-ный прототип, что крайне странно для TS, с моей точки зрения, но, тем не менее, является визуальным противоречием.
Странно потому, что зачем нам проверять тип класса, если надо важно его содержимое, относительно которого прекрасно проходят все проверки.
Преступность в США и России: сравнительный обзор
И в России тренд, кстати, на увеличение продолжительности.
Преступность в США и России: сравнительный обзор
Повторю - смотря что сравнивать.
Преступник в вакууме одинаково угрожает как ребёнку, так и старушке. Если мы оцениваем среднюю безопасность всех жителей - то 1 преступник на 100 жителей причинит конкретному жителю в среднем больше ущерба за год, чем 1 на 1 000 000.
Если мы оцениваем склонность жителей к сознательным криминальным поступкам то, конечно, несознательных априори мы должны исключить.
gRPC в .NET — рецепты счастья
Скорее всего, называет для краткости HTTP без дополнительных прикладных протоколов сверху просто REST-ом.
Преступность в США и России: сравнительный обзор
Для "плановой экономики" как раз статистика и первостепенна. На основе неё строится и проверяется корректность выполнения плана.
А так статистику хоть с планом, хоть без плана можно дорисовывать и доинтерпретировать. Любой мэр даже без плана с большей радостью заявит о "трёхкратном падении преступности".
Преступность в США и России: сравнительный обзор
Для разных миллионов - разные цели.
Если мы оцениваем безопасность в целом - то, конечно, надо брать всё население, от мала до велика. Т.е. соотношение бандитов к количеству потенциальных жертв.
Если оцениваем среднюю уголовную наклонность сознательных дееспособных граждан - конечно, надо брать другое количество.
Преступность в США и России: сравнительный обзор
Половой шантаж у нас тоже присутствует, особенно в отношении малолетних. И "сексуальные домогательства" - это не изнасилование.
gRPC в .NET — рецепты счастья
Как техническое средство, естественно, кафка для синхронного взаимодействия подходит не так хорошо, как непосредственный сетевой вызов. Поэтому, "некостыльно" - наверное, не могу.
Но тем не менее, как раз при "архитектурных" решениях типа "везде делаем кафку" эти костыли, при логической необходимости синхронного взаимодействия, будут возникать.
Непосредственно отвечая на вопрос - самый банальный вариант отправлять сообщение и входить бесконечный цикл, ожидая некоего ответного сообщения, прежде, чем возобновить поток управления.
gRPC в .NET — рецепты счастья
Restful, в отличие от сокетов, не техническая, а логическая концепция. И когда мы размышляем, как будем воплощать ту или иную прикладную область в реализацию - естественно, мы начинаем с модели взаимодействия данных. И дальше на основании этой модели внедряем подходящие технологии.
Это не самоцель, это выбор, на основании которого надо принимать дальнейшие решения.
Как написали ниже - конечно, без всяких протофайлов можно сериализовывать, не сложнее, чем обычный json, те же атрибуты.
gRPC в .NET — рецепты счастья
Чтобы использовать RESTful стиль взаимодействия с преимуществами малого объёма передаваемых данных.
Упоминать надо, поскольку на моей практике часто люди, вместо того, чтобы точечно решить проблемы с этим объёмом, начинают переделывать вообще всё на grpc.
gRPC в .NET — рецепты счастья
Синхронность и асинхронность мало общего имеют с очередями и интернет-протоколами. Они связаны с особенностями потока управления.
Кафка вполне может использоваться для синхронного взаимодействия. Grpc - для асинхронного.
Их корректно сравнивать как средство доставки сообщений, например.
gRPC в .NET — рецепты счастья
Преимущества и недостатки gRPC изначально связаны с парадигмой взаимодействия.
Если предполагается restful взаимодействие с понятной предметной областью - то классический Rest однозначно лучше. В его соглашениях все взаимодействия описаны, и есть много средств, успешно их использующих.
А если требуется RPC в произвольной форме - тогда, конечно, grpc на данный момент в общем случае самый логичный первый выбор.
P.S. Очень жаль, что не рассказали о том, что протобаф доступен без всякого grpc и протофайлов как форматтер в "обычном" рест-взаимодействии. Может сложиться впечатление, что для решения всех описанных проблем обязательно тянуть весь grpc.
Физическая и математическая реальности
Я бы поспорил, что объяснительная часть важнее. Какой интерес просто так объяснять (т.е. придумывать некое явно не наблюдаемое обоснование) тому, что уже произошло в непосредственном наблюдении.
Как раз интерес в предсказании новых непосредственно ощущаемых фактов, для которых объяснение есть всего лишь проверка корректности теории.
Казнить нельзя помиловать
Казнить нельзя помиловать
Далее бы уже решала личная мотивация сотрудника. Если уволится — значит, уволится. Если качество провалится ниже — значит сами уволим. Исправится или впишется в некий другой круг обязанностей, где его сильные качества проявятся лучше — замечательно.
Scrum-мем на злобу дня
У Пучкова на канале интересный курс лекций Яковлева о предпосылках и ходе революции и ГВ. Рекомендую.
Генеральный конструктор vs Скрам-мастер
Генеральный конструктор vs Скрам-мастер
Генеральный конструктор vs Скрам-мастер
Лучшие практики, эмпирический опыт и математика
Точно так же, как и для каждой новой трансформации универсального объекта в вашем примере.