Нет, почему. Идея налога — чтобы не работающие оплачивали расходы на них по ОМС. Каждый ИП, даже без сотрудников и не имеющий оборотов платит в ПФ и ФОМС, чуть больше 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 позволяет экономить время на разработке клиента, а в ряде случаев и сервиса. Вы с этим принципиально не согласны?
Не уверен, что использовать vim для разработки на C# хорошая идея, есть специализированные инструменты, типа студии (которая бесплатная в community edition), в которой таких проблем нет.
(а) реализации SOAP на этой и той стороне отличаются (например, вы по-разному трактуете время без указания часового пояса)
(б) в WSDL (точнее, XSD) описаны далеко не все детали формата, а в паре мест стоит xs:any.
Если API кривой, то не важно REST он, не REST, проблемы всё равно будут.
(ц) авторизация… авторизация? авторизация, мать ее!
не понял вас тут
А что такого в «стоимости разработки REST»? Чем она радикально выше, чем разработка под SOAP?
Ну, как минимум, надо свой транспорт писать. Формирование JSON, запрос к удалённому компьютеру, считывание ошибок, протоколирование, парсинг JSON обратно в объекты. В реализации SOAP майкрософта это всё идёт из коробки, вызвал функцию на сгенерированном прокси-классе, обратно получил результат, случилась ошибка — вывалился exception. Это работает прозрачно, как будто всё происходит в рамках одного процесса.
(а) простота использования из браузерного кода
(б) опора на существующую HTTP-инфраструктуру (например, кэширование)
(ц) «встроенная» мультиформатность
(д) более очевидная семантика
Тут согласен, но это делает его в основном пригодным только для фронтэнда. Причём в рамках одного домена, из-за ограничения на кроссдоменные запросы.
Как по мне, самый большой недостаток REST — высокие затраты времени на разработку. Если API предоставляется через SOAP (так поступает большинство крупных компаний банковского, страхового и других B2B секторов), достаточно взять кодогенератор, который из WSDL файла сгенерирует прокси классы и всё, через 3 минуты ты можешь делать запросы, при этом особенности транспорта тебя не волнуют. Круче всего это реализовал Microsoft в своём WCF, где через конфигурационный файл можно выбрать любой транспорт, от http(s) до MSMQ (включая tcp и named pipes). WSDL файл и SOAP автоматически генерируются на основе кода.
А REST, вот я так в толк и не возьму, какие у него основные плюсы. Меньше данных передаётся? В мире единицы сайтов, для которых экономия на траффике в таких масштабах превысит стоимость разработки REST.
Всё структурно? Да хз, как бы да, но реально дебажить приходится смотря на все 7 мест, указанных в статье. И опять же, если следовать RESTful, то те моменты, которые через RPC решаются за один запрос, через RESTful за кучу. Не понимаю я его смысл как «эталона», короче.
Очень хочется иметь возможность брать вкладку и утаскивать её на второй монитор как отдельное окно браузера. В старом интерфейсе это можно было делать. А сейчас приходится извращаться с копированием/вставкой адреса.
При этом я согласен, что если нужен джуниор, то можно ограничиться и джуниором, нет смысла пихать туда сеньора. При этом нанимаемый джуниор должен быть профессиональным (для уровня джуниора) и ответственным, а не просто с горящими глазами и большими мечтами.
Я говорю о том, что уровень профессионализма и ответственности обратно пропорциональны риску. Чем квалифицированнее человек, тем более качественный продукт он может создать. Но создать нечто выдающееся, что выстрелит, может как новичок, так и профессионал. Поэтому сравнивая профессионала и юношу с горящими глазами, но с неизвестным уровнем профессионализма, как описывает автор, то у юноши риск будет гарантированно высоким, а вот награда как раз не изменится.
А что вы имели в виду?
В том то и дело, что судя по посылу статьи дело доходит до диалога. И поэтому такой подход слишком рискованный. А если человек нанимается по такому принципу условным техдиром не за свои деньги, а за деньги инвестора, то подход ещё и аморальный, ведь рискуешь чужими деньгами.
Кроме того, даже если человек раньше делал что-то крутое, не значит что он сможет сделать что-то подобное, будущее нельзя прогнозировать на основе прошлого.
По себе могу сказать, что когда времени было больше читал ленту вглубь на несколько страниц, сейчас только популярные статьи.
Кстати, 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 позволяет экономить время на разработке клиента, а в ряде случаев и сервиса. Вы с этим принципиально не согласны?
Если API кривой, то не важно REST он, не REST, проблемы всё равно будут.
не понял вас тут
Ну, как минимум, надо свой транспорт писать. Формирование JSON, запрос к удалённому компьютеру, считывание ошибок, протоколирование, парсинг JSON обратно в объекты. В реализации SOAP майкрософта это всё идёт из коробки, вызвал функцию на сгенерированном прокси-классе, обратно получил результат, случилась ошибка — вывалился exception. Это работает прозрачно, как будто всё происходит в рамках одного процесса.
Конкретный пример — работа с транзакциями, описание разницы есть тут: habrahabr.ru/post/131343
Тут согласен, но это делает его в основном пригодным только для фронтэнда. Причём в рамках одного домена, из-за ограничения на кроссдоменные запросы.
А REST, вот я так в толк и не возьму, какие у него основные плюсы. Меньше данных передаётся? В мире единицы сайтов, для которых экономия на траффике в таких масштабах превысит стоимость разработки REST.
Всё структурно? Да хз, как бы да, но реально дебажить приходится смотря на все 7 мест, указанных в статье. И опять же, если следовать RESTful, то те моменты, которые через RPC решаются за один запрос, через RESTful за кучу. Не понимаю я его смысл как «эталона», короче.