Предлагаю первый вариант.
Я на самом деле не работаю в медицине, поэтому оцениваю её с точки зрения пациента. Последняя наблюдаемая ситуация: бабушка, 78 лет, 11 вечера, боль в груди, приезжает неотложка, госпитализация, сразу направление на коронарографию (надеюсь правильно написал), через 4 часа после вызова ставят стент. Всё это делает по полису ОМС. На мой взгляд, это отличное качество работы. Но дело было в Питере, я не готов утверждать что во всех регионах также.
И я не готов утверждать что с точки зрения врачей всё хорошо, наверняка есть проблемы, о которых я не знаю. Но для пациентов проблем нет. А сборы с неработающих нужны в том числе и для того, чтобы у медперсонала ситуация стала лучше.
Это обязательное страхование, оно регулируется государством так, чтобы те, кто зарабатывает больше, платили за тех, кто зарабатывает меньше. Для сотрудников отчисления в ФОМС пропорциональны зарплате, для ИП когда доход превышает 300 000 в год, идёт дополнительный процент в ФОМС.
ОСАГО стоит совсем не одинаково, там коэффициенты идут от мощности двигателя и стоимость может отличаться в 3 раза при одинаковом страховом покрытии.
Более того, по принципу оплаты медицинских услуг — это однозначно страховка. Медучреждения выставляют счёт страховой компании по факту оказания услуг. Вы имеете право выбрать свою страховую компанию, в которую пойдут ваши отчисления. Программы страхования незначительно отличаются. В случае налогообложения такой подход невозможен, там идёт сбор денег в один источник и перераспределение через бюджет.
Вы, видимо, не очень умный человек, раз такие вещи пишите. Я ничего не буду комментировать про «отнять и поделить», в 1917 уже сделали раз, как-то не получилось безбедно жить.
Мне другое интересно, какой банк согласится взять $7 350 000 000 000 000 (произведения ваших волшебных 50 миллионов на 147 миллионов человек) и платить с неё процент? Куда он её вложит? Даже если такой банк найдётся, где гарантия, что эти деньги не будут выведены в офшор, а банк не будет обанкрочен? На шаг вперёд думать не пробовали?
А то как в анекдоте:
— Надо вам, мышки, стать ёжиками.
— А как нам стать ёжиками, сова?
— А это не ко мне, мышки, я стратегией занимаюсь.
Ну тогда бы пришлось и всю педиатрию выпиливать, и помощь пожилым. Подразумевается, что люди в трудоспособном возрасте за счёт своих взносов обеспечивают лечение нетрудоспособным. А если трудоспособные люди филонят, то денег не хватает. А потом отдельные, особо одарённые, начинают кричать про то, как тяжело в России жить и как всё плохо тут с медициной.
> А если человек не болеет, а за ОМС все равно платить (как платятся соцотчисления)? А если у вас большие соцотчисления, а у дворника они маленькие, а лечить вас будут по ОМС одинаково плохо?
Вы сами ответили на свой вопрос: «Государство в любом случае будет перераспределять деньги, нравится вам это или нет.». Кроме того, это основной принцип страхования, собираем со всех страхующихся небольшие суммы, чтобы в случае наступления страхового случая, выплатить большую. Кстати, вы зря ОМС ругаете, лечат по нему очень неплохо, в том числе и ВМП.
> Нет, мне ваша логика не нравится.
От этого она не становится менее логичной.
Нет, почему. Идея налога — чтобы не работающие оплачивали расходы на них по ОМС. Каждый ИП, даже без сотрудников и не имеющий оборотов платит в ПФ и ФОМС, чуть больше 20 000 в год. А так получается что человек налогов не платит, но имеет право на лечение, образование и т.п.
А смысл этого действа? Длина ключевых слов больше чем в английской версии, значит набирать дольше; части символов, типа [], {} нет в русской раскладке, т.е. придётся постоянно переключать раскладку. Плюс проект на 100% привязывается к русскоговорящим разработчикам, отдать его на запад или индусам для доработки уже не получится.
Я наверное не совсем корректно выразился. Под наградой я имею в виду именно готовый продукт, т.е. награда для работодателя. Его цель получить определённый результат, который ему может дать как профессионал, так и новичок. При этом вероятность того, что профессионал добьётся результата выше, чем у новичка. Вопрос расходов на оплату труда я обхожу стороной, потому что в самой статье они не поднимались.
При этом я согласен, что если нужен джуниор, то можно ограничиться и джуниором, нет смысла пихать туда сеньора. При этом нанимаемый джуниор должен быть профессиональным (для уровня джуниора) и ответственным, а не просто с горящими глазами и большими мечтами.
Поясните свою позицию, пожалуйста.
Я говорю о том, что уровень профессионализма и ответственности обратно пропорциональны риску. Чем квалифицированнее человек, тем более качественный продукт он может создать. Но создать нечто выдающееся, что выстрелит, может как новичок, так и профессионал. Поэтому сравнивая профессионала и юношу с горящими глазами, но с неизвестным уровнем профессионализма, как описывает автор, то у юноши риск будет гарантированно высоким, а вот награда как раз не изменится.
А что вы имели в виду?
Ну это да. Можно использовать типологию личности Майерс-Бриггс или соционику, как более точный анализ личности. Оцениваешь, насколько подходящий тип человека для этой работы и насколько он профессионален и ответственен. В этом случае получается хороший результат.
Пример: я нанял сисадмина практически без опыта работы, в универе он изучал археологию (!), но он страстно увлекался Линуксом. Выступал с докладами на конференциях Ubucon и контрибьютил в Дебиан-пакеты для археологов.
В том то и дело, что судя по посылу статьи дело доходит до диалога. И поэтому такой подход слишком рискованный. А если человек нанимается по такому принципу условным техдиром не за свои деньги, а за деньги инвестора, то подход ещё и аморальный, ведь рискуешь чужими деньгами.
Как-то слишком по-детски, имхо. Предпочитаю нанимать профессиональных и ответственных людей, а не тех, у кого работа это страсть. Ибо первые дают результаты, а вторые может быть их дадут.
Кроме того, даже если человек раньше делал что-то крутое, не значит что он сможет сделать что-то подобное, будущее нельзя прогнозировать на основе прошлого.
А вы только хабр анализировали или гиктаймс с мегамозгом тоже? Туда же часть хабов перенесли, не помню когда это случилось.
По себе могу сказать, что когда времени было больше читал ленту вглубь на несколько страниц, сейчас только популярные статьи.
Ну так туда заложена амортизация автомобиля. У меня на дизельном СсанЙонге ТО каждые 10 000 км, в среднем около 10-12 тысяч стоит. 863 км пробега — примерно 1 000 рублей к ТО. Плюс страховка, плюс амортизация автомобиля. Иногда его мыть приходится после пассажиров.
Кстати, 4 человека в машине это жёстко, блаблакар пишет, что 3 человека должны компенсировать стоимость топлива. Четвёртого сажать на 10 часовой маршрут не совсем этично. Сзади совсем не комфортно будет.
Вы же почему-то предложили не WS-Security, а «На практике, обычно выделяют отдельный метод для авторизации, который возвращает токен и этот токен используется в последующих запросах».
Не я предложил, это чаще всего встречается в существующих API, которые мы к себе интегрируема.
Вы почему-то считаете, что я считаю, что SOAP плохой, а REST — хороший. А я считаю, что каждый из них подходит для своей задачи, а для каких-то задач подходит что-то третье.
Я так считаю? Вы же начали отвечать на мой комментарий, пытаясь прицепиться к каждому пункту.
В этом утверждении говорится только о запросах, не о том, что REST решает. Это вы сами додумали.
В реальности это далеко не всегда так.
Несомненно, иногда приходится приложить дополнительные усилия. Но если API спроектирован хорошо, все прокси-классы сгенерируются и запросы можно будет делать сразу. Но это не проблема SOAP, а кривых рук разработчиков API.
В REST не стандартизовано, но в REST безопасность делегирована на транспортный уровень, а там, в свою очередь, есть устоявшиеся практики.
А что мешает использовать https для SOAP запросов? Что до практик, вы сами упоминали WS-Security. То что им не всегда следуют — не проблема SOAP, а кривизны рук разработчиков API. Это как машина, знаете, правила нарушает не она, а водитель.
В качестве развлечения предлагаю вам добавить в WCF подписание сообщений по ГОСТу.
Делал я подписание сообщений и ручную проверку сертификатов. Не по ГОСТу, а по AES, но с учётом того, что инфраструктура криптопровайдеров стандартизирована, а ГОСТовские провайдеры есть, не думаю что там будут особые сложности.
А в REST, кстати, это как-то очень просто делается? Там вроде только свелосипедить можно, https ГОСТ не особо уважает, насколько я знаю.
Очень просто. RPC вообще (и SOAP в частности) не имеет транзакционной семантики, ее всегда добавляет какой-то дополнительный инструмент. Соответственно, когда вам нужна распределенная транзакция, вы добавляете координатор и соответствующие вызовы — и вам, по большому счету, пофиг, куда их добавлять.
И что, есть реализации координаторов для REST?
SOAP и RPC (как и messaging или REST) — это парадигмы, между которыми есть крупные отличия, радикально влияющие на архитектуру решения.
Ну REST как бы больше ограничений накладывает. Тут и отсутствие состояний, и обязательное использование http, и жёстка завязка на предопределённые коды ответа и методы http. SOAP (simple object access protocol) и RPC (remote procedure call) по определению с этой стороны гораздо более гибкие.
Если API предоставляется через SOAP [...], достаточно взять кодогенератор, который из WSDL файла сгенерирует прокси классы и всё, через 3 минуты ты можешь делать запросы, при этом особенности транспорта тебя не волнуют.
Извините за бестактность, но вы русский язык знаете? В этом абзаце написано про то, что SOAP позволяет автоматически сгенерировать прокси классы, которые позволят сразу делать запросы не учитывая конкретных особенностей транспорта. Где вы тут увидели что SOAP решает?
Стандарты? WS-Security? Нет, не слышал. Вот в этом и проблема: каждый делает по-своему.
А в REST значит всё стандартизировано? Ну-ну.
Вы, видимо, не в курсе
А у вас класс Product откуда взялся? Сами написали? Ну круто. Хорошо если там 3 поля, а как начинаешь работать со страховыми продуктами, то там мама не горюй какой объём и вложенность. Помнится, интегрировали мы одну страховую, расчёт туристического страхования (не самый сложный продукт), объём сгенерированного кода был за 3 000 строк. Сколько по КАСКО (сложный продукт) я даже думать не хочу. Для аналогичного продукта другой страховой компании, написанного как раз на REST, было затрачено около 70 человекочасов дополнительно на транспорт.
Распределенные транзакции плохо удаются любому протоколу, не важно, RPC это или SOAP. Это проблема распределенности, а не протокола.
Обоснуйте
Если же вы будете сравнивать с любой другой устоявшейся парадигмой (messaging, REST), то выяснится, что различия более архитектурные, чем временные, и именно от архитектуры и надо плясать.
А SOAP и RPC — не архитектура? И что такое временные различия?
Ну конечно SOAP не решает, разве я это где-то говорил?
В HTTP есть простые и понятные способы аутентификации и авторизации. В SOAP с этим все весело, особенно когда вы делаете межвендорную (например, .net — Java) интеграцию.
На практике, обычно выделяют отдельный метод для авторизации, который возвращает токен и этот токен используется в последующих запросах, это не является проблемой.
Http-клиент, в любой разумной платформе из коробки.
У того же Microsoft для всего этого давно есть обертка (HttpRequestMessage/HttpResponseMessage) с расширениями.
Клиент то из коробки, но это не отменяет необходимость формирования JSON, запроса к удалённому компьютеру, считывания ошибок, протоколирования, парсинга JSON обратно в объекты. А клиент да, позволяет делать запрос не беспокоясь о TCP и нижележащих протоколах.
До первой проблемы, особенно проблемы формата 400 Bad Request без объяснений.
А REST тут чем лучше? Если тот же Bad Request без объяснений вываливается? Это вопрос качества реализации API, если она кривая, придётся мучиться.
Под транзакциями я понимаю ACID и не понимаю что там плохого.
Угу, а теперь давайте задумаемся, что мы не хотим писать два разных сервиса для веб-клиентов и мобильных клиентов, а после этого добавим сюда third-party. Вот, собственно, и вся интеграция для нормального веб-приложения.
Для B2C возможно, у B2B таких проблем обычно не стоит.
Вам не кажется, что мы с вами о разных вещах говорим? Моя позиция: REST переоценен, во многих ситуациях SOAP позволяет экономить время на разработке клиента, а в ряде случаев и сервиса. Вы с этим принципиально не согласны?
Я на самом деле не работаю в медицине, поэтому оцениваю её с точки зрения пациента. Последняя наблюдаемая ситуация: бабушка, 78 лет, 11 вечера, боль в груди, приезжает неотложка, госпитализация, сразу направление на коронарографию (надеюсь правильно написал), через 4 часа после вызова ставят стент. Всё это делает по полису ОМС. На мой взгляд, это отличное качество работы. Но дело было в Питере, я не готов утверждать что во всех регионах также.
И я не готов утверждать что с точки зрения врачей всё хорошо, наверняка есть проблемы, о которых я не знаю. Но для пациентов проблем нет. А сборы с неработающих нужны в том числе и для того, чтобы у медперсонала ситуация стала лучше.
ОСАГО стоит совсем не одинаково, там коэффициенты идут от мощности двигателя и стоимость может отличаться в 3 раза при одинаковом страховом покрытии.
Более того, по принципу оплаты медицинских услуг — это однозначно страховка. Медучреждения выставляют счёт страховой компании по факту оказания услуг. Вы имеете право выбрать свою страховую компанию, в которую пойдут ваши отчисления. Программы страхования незначительно отличаются. В случае налогообложения такой подход невозможен, там идёт сбор денег в один источник и перераспределение через бюджет.
Мне другое интересно, какой банк согласится взять $7 350 000 000 000 000 (произведения ваших волшебных 50 миллионов на 147 миллионов человек) и платить с неё процент? Куда он её вложит? Даже если такой банк найдётся, где гарантия, что эти деньги не будут выведены в офшор, а банк не будет обанкрочен? На шаг вперёд думать не пробовали?
А то как в анекдоте:
— Надо вам, мышки, стать ёжиками.
— А как нам стать ёжиками, сова?
— А это не ко мне, мышки, я стратегией занимаюсь.
Вы сами ответили на свой вопрос: «Государство в любом случае будет перераспределять деньги, нравится вам это или нет.». Кроме того, это основной принцип страхования, собираем со всех страхующихся небольшие суммы, чтобы в случае наступления страхового случая, выплатить большую. Кстати, вы зря ОМС ругаете, лечат по нему очень неплохо, в том числе и ВМП.
> Нет, мне ваша логика не нравится.
От этого она не становится менее логичной.
При этом я согласен, что если нужен джуниор, то можно ограничиться и джуниором, нет смысла пихать туда сеньора. При этом нанимаемый джуниор должен быть профессиональным (для уровня джуниора) и ответственным, а не просто с горящими глазами и большими мечтами.
Я говорю о том, что уровень профессионализма и ответственности обратно пропорциональны риску. Чем квалифицированнее человек, тем более качественный продукт он может создать. Но создать нечто выдающееся, что выстрелит, может как новичок, так и профессионал. Поэтому сравнивая профессионала и юношу с горящими глазами, но с неизвестным уровнем профессионализма, как описывает автор, то у юноши риск будет гарантированно высоким, а вот награда как раз не изменится.
А что вы имели в виду?
В том то и дело, что судя по посылу статьи дело доходит до диалога. И поэтому такой подход слишком рискованный. А если человек нанимается по такому принципу условным техдиром не за свои деньги, а за деньги инвестора, то подход ещё и аморальный, ведь рискуешь чужими деньгами.
Кроме того, даже если человек раньше делал что-то крутое, не значит что он сможет сделать что-то подобное, будущее нельзя прогнозировать на основе прошлого.
По себе могу сказать, что когда времени было больше читал ленту вглубь на несколько страниц, сейчас только популярные статьи.
Кстати, 4 человека в машине это жёстко, блаблакар пишет, что 3 человека должны компенсировать стоимость топлива. Четвёртого сажать на 10 часовой маршрут не совсем этично. Сзади совсем не комфортно будет.
Не я предложил, это чаще всего встречается в существующих API, которые мы к себе интегрируема.
Ну как бы да: msdn.microsoft.com/en-us/library/ff384250.aspx
Я так считаю? Вы же начали отвечать на мой комментарий, пытаясь прицепиться к каждому пункту.
В этом утверждении говорится только о запросах, не о том, что REST решает. Это вы сами додумали.
Несомненно, иногда приходится приложить дополнительные усилия. Но если API спроектирован хорошо, все прокси-классы сгенерируются и запросы можно будет делать сразу. Но это не проблема SOAP, а кривых рук разработчиков API.
А что мешает использовать https для SOAP запросов? Что до практик, вы сами упоминали WS-Security. То что им не всегда следуют — не проблема SOAP, а кривизны рук разработчиков API. Это как машина, знаете, правила нарушает не она, а водитель.
Делал я подписание сообщений и ручную проверку сертификатов. Не по ГОСТу, а по AES, но с учётом того, что инфраструктура криптопровайдеров стандартизирована, а ГОСТовские провайдеры есть, не думаю что там будут особые сложности.
А в REST, кстати, это как-то очень просто делается? Там вроде только свелосипедить можно, https ГОСТ не особо уважает, насколько я знаю.
И что, есть реализации координаторов для REST?
Ну REST как бы больше ограничений накладывает. Тут и отсутствие состояний, и обязательное использование http, и жёстка завязка на предопределённые коды ответа и методы http. SOAP (simple object access protocol) и RPC (remote procedure call) по определению с этой стороны гораздо более гибкие.
Извините за бестактность, но вы русский язык знаете? В этом абзаце написано про то, что SOAP позволяет автоматически сгенерировать прокси классы, которые позволят сразу делать запросы не учитывая конкретных особенностей транспорта. Где вы тут увидели что SOAP решает?
А в REST значит всё стандартизировано? Ну-ну.
А у вас класс Product откуда взялся? Сами написали? Ну круто. Хорошо если там 3 поля, а как начинаешь работать со страховыми продуктами, то там мама не горюй какой объём и вложенность. Помнится, интегрировали мы одну страховую, расчёт туристического страхования (не самый сложный продукт), объём сгенерированного кода был за 3 000 строк. Сколько по КАСКО (сложный продукт) я даже думать не хочу. Для аналогичного продукта другой страховой компании, написанного как раз на REST, было затрачено около 70 человекочасов дополнительно на транспорт.
Обоснуйте
А SOAP и RPC — не архитектура? И что такое временные различия?
На практике, обычно выделяют отдельный метод для авторизации, который возвращает токен и этот токен используется в последующих запросах, это не является проблемой.
Клиент то из коробки, но это не отменяет необходимость формирования JSON, запроса к удалённому компьютеру, считывания ошибок, протоколирования, парсинга JSON обратно в объекты. А клиент да, позволяет делать запрос не беспокоясь о TCP и нижележащих протоколах.
А REST тут чем лучше? Если тот же Bad Request без объяснений вываливается? Это вопрос качества реализации API, если она кривая, придётся мучиться.
Под транзакциями я понимаю ACID и не понимаю что там плохого.
Для B2C возможно, у B2B таких проблем обычно не стоит.
Вам не кажется, что мы с вами о разных вещах говорим? Моя позиция: REST переоценен, во многих ситуациях SOAP позволяет экономить время на разработке клиента, а в ряде случаев и сервиса. Вы с этим принципиально не согласны?