Это какие браузеры? Я просто давно мечтаю о таком, но не видел нигде еще.
Поправил: это ещё не реализовано. Но скоро будет внедрено и в Chrome, и в Firefox:
Да, сами описания выглядят несколько громоздко, что немного напрягает.
>>>Автоматические генераторы есть, и тут уже больше философский вопрос, что первично — документация или код. Мне близок подход, когда сперва составляется осмысленная документация.>>>>
Я ничего не имею против этого подхода. Задавая свой вопрос, я никаких философских аспектов затрагивать не хотел. Мне действительно интересно, насколько сейчас распространён WSDL, как он поддерживается сообществом, какие есть вспомогательные инструменты.
>>>>Учитывая что эти форматы чаще употребляются сриптами чем читаются человеком (зачем это читать если можно посмотреть что в UI нагенерили для каждого endpoint) то логичность синтаксиса — это вопрос второй. >>>>
Даже для скриптов лучше писать в простом формате и без лишних «костылей».
>>>>Для RAML есть генераторы клиентов, как например AutoRest для .NET?>>>>
Есть, но пока что они находятся в очень «сыром» состоянии.
>>>>А вот коммунити — это наживается непросто. За RAML стоит одна компания, как и за API Blueprint. Swagger старается вовлечь сообщество в стандарт.>>>>>
За RAML стоит не одна компания. В разработке спецификаций принимали участие представители Cisco, PayPal, BoxInc. Насчёт коммьюнити — оно уже формируется (см., например, здесь: raml.org/projects.html)
1. Гораздо более простым и логичным синтаксисом описаний.
2. Возможностью расписать в документации гораздо большее количество параметров, чем в том же swagger и, самое главное, сделать это при помощи более простых и удобных конструкций (сравните те же описания схем безопасности или query-параметров).
3. Расширенными (по сравнению с тем же swagger) возможностями использования include'ов и наследования, благодаря чему документация получается более компактной и элегантной.
Единственное, в чём RAML пока что проигрывает Swagger — недостаточное количество разрабатываемых сообществом инструментов. Но это — дело наживное.
>>>К тому же, не сравнивайте миллиард китайцев с 150 лямами россиян, из которых лишь часть пользуется инетом<<<<
Китай — он тоже разный. Там есть не только богатые Пекин и Шанхай, но и куча забытых Богом и цивилизацией мест — например, неблагополучный как с политической, так и экономической точки зрения Синцзян-Уйгурский автономный район. Поинтересуйтесь, как в Китае живут на селе — там, мягко говоря, далеко не все гладко. С Интернетом в сельской местности в России (при всех имеющихся трудностях) получше будет.
Полное импортозамещение в случае с ПО вряд ли представляется возможным. Выше уже было сказано, почему.
Десятипроцентные налоги и прочие проекты подобного рода я считаю не просто глупостью, а прямым вредительством. В нашей стране давно уже назрела необходимость модернизации, которая невозможна без поддержки высокотехнологичных отраслей экономики. Высокотехнологичный сектор (см. опыт Китая, Сингапура, Бразилии), должен быть вообще не облагаемым налогами либо облагаемым по минимуму.
Поддержка отечественного производителя на госзакупках, думаю нужна. Здесь опять же можно воспользоваться китайским опытом.
Насчет менталитета — все верно. Но причины китайской нелюбви к западному ПО имеют не политико-идеологический, а культурный характер. Наши европейские представления о дизайне (о пространственном расположение элементов, цветах и т.п.) очень плохо вписываются в контекст китайской культуры. Это одна из причин, по которым они делают все свое. И получаются у них не хуже, а иногда даже лучше.
Добавлю, что китайцы еще в конце 1990-х — начале 2000-х старались не использовать продукты Microsoft. Уже тогда у них был свой пакет King Soft Office, специально адаптированный под работу с китайской письменностью.
Вы вообще за Уралом были когда-нибудь? На российском Дальнем Востоке были? Представляете себе, какие там расстояния? Если контент пойдет на Камчатку не через Новосибирск, а через Монголию, то это вообще будет не заметно — расстояние примерно одно и то же. Более того, для Дальнего Востока точки присутствия в том же Китае будут горазо выгоднее по целому ряду причин.
Прочитал Ваш комментарий, и у меня тут же возник вопрос: а есть ли вообще какие-нибудь CDN, у которых в России есть точки присутствия восточнее Новосибирска? В дальневосточном регионе, напримре, есть у кого-нибудь точки присутствия?
Это сильно зависит от задачи.
В статье описан самый простой пример, который, однако вполне можно считать рабочим вплоть до 300-500 KB минифицированных скриптов/CSS (30-70 KB с gzip). А это размер крупного SPA.
Если больше, то можно начинать думать об оптимизации. Самое простое — разнести вендор-файлы и файлы приложения. Приложение обновляется намного чаще, чем библиотеки, поэтому в основном клиенты будут перекачивать лишь малую часть данных.
Если приложение совсем большое (или в каких-то разделах используются тяжёлые библиотеки), то можно уже группировать по частям — common + отдельные файлы для каждого раздела. В статье об этом не написано, потому что в общем случае это делается нетривиальным образом — или всё разносить по файлам руками, имея риск что-то забыть/перепутать, или с самого начала выбирать архитектуру приложения, исходя из этого требования. Здесь можно отметить яндексовские BEM + bem-tools и более новый webpack.
Есть и другой интересный момент — если файлов становится слишком много (включая все скрипты, стили и картинки), то чтобы не нарваться на ограничение на число параллельных запросов на один домен, можно начинать разносить статику по разным поддоменам штук по 6 ссылок на каждый. Но здесь уже всё совсем индивидуально — надо тестировать, экспериментировать, проверять на различных типах подключения и т.д., иначе можно скорее потерять в скорости загрузки сайта.
Насчёт библиотек по CDN. Использовать сторонние скрипты в HTML я бы никогда не стал и никому не советую. Во-первых, добавляется ещё одна точка отказа. Все падают — и Гугл, и Яндекс, и, думаю, мало кому из ваших клиентов понравится увидеть полностью неработающий сайт только потому что какой-то из внешних ресурсов отвалился (а обычно их прям пачкой добавляют). Во-вторых, вы точно осознаёте, что загружая скрипт с чужого сервера, вы по сути даёте кому-то полный контроль за вашим сайтом? Популярный CDN, конечно, не будет скорее всего кого-то ломать, но его ведь могут и самого поломать.
Да и эффективность такого решения по моему мнению сильно преувеличена — вы скорее проиграете на резолве домена и разогреве кэша, чем при прогоне десятка килобайт по открытому TCP-соединению с разогретым congestion window. (Какой-то крупный сайт публиковал отчёт по поводу процента клиентов с разогретым кэшом на главной странице, и цифры там были далеко не большие.)
https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
Весьма любопытная дискуссия, в которой участвуют ведущие разработчики Prometheus и InfluxDB. Возможно, найдёте какие-то интересные мысли по теме.
>>>Автоматические генераторы есть, и тут уже больше философский вопрос, что первично — документация или код. Мне близок подход, когда сперва составляется осмысленная документация.>>>>
Я ничего не имею против этого подхода. Задавая свой вопрос, я никаких философских аспектов затрагивать не хотел. Мне действительно интересно, насколько сейчас распространён WSDL, как он поддерживается сообществом, какие есть вспомогательные инструменты.
Кстати, а существуют ли какие-нибудь генераторы интерактивной документации для WSDL?
Даже для скриптов лучше писать в простом формате и без лишних «костылей».
>>>>Для RAML есть генераторы клиентов, как например AutoRest для .NET?>>>>
Есть, но пока что они находятся в очень «сыром» состоянии.
>>>>А вот коммунити — это наживается непросто. За RAML стоит одна компания, как и за API Blueprint. Swagger старается вовлечь сообщество в стандарт.>>>>>
За RAML стоит не одна компания. В разработке спецификаций принимали участие представители Cisco, PayPal, BoxInc. Насчёт коммьюнити — оно уже формируется (см., например, здесь: raml.org/projects.html)
1. Гораздо более простым и логичным синтаксисом описаний.
2. Возможностью расписать в документации гораздо большее количество параметров, чем в том же swagger и, самое главное, сделать это при помощи более простых и удобных конструкций (сравните те же описания схем безопасности или query-параметров).
3. Расширенными (по сравнению с тем же swagger) возможностями использования include'ов и наследования, благодаря чему документация получается более компактной и элегантной.
Единственное, в чём RAML пока что проигрывает Swagger — недостаточное количество разрабатываемых сообществом инструментов. Но это — дело наживное.
Есть. Вот ссылка на инструмент для валидации: www.npmjs.com/package/raml-validate
Китай — он тоже разный. Там есть не только богатые Пекин и Шанхай, но и куча забытых Богом и цивилизацией мест — например, неблагополучный как с политической, так и экономической точки зрения Синцзян-Уйгурский автономный район. Поинтересуйтесь, как в Китае живут на селе — там, мягко говоря, далеко не все гладко. С Интернетом в сельской местности в России (при всех имеющихся трудностях) получше будет.
Десятипроцентные налоги и прочие проекты подобного рода я считаю не просто глупостью, а прямым вредительством. В нашей стране давно уже назрела необходимость модернизации, которая невозможна без поддержки высокотехнологичных отраслей экономики. Высокотехнологичный сектор (см. опыт Китая, Сингапура, Бразилии), должен быть вообще не облагаемым налогами либо облагаемым по минимуму.
Поддержка отечественного производителя на госзакупках, думаю нужна. Здесь опять же можно воспользоваться китайским опытом.
В статье описан самый простой пример, который, однако вполне можно считать рабочим вплоть до 300-500 KB минифицированных скриптов/CSS (30-70 KB с gzip). А это размер крупного SPA.
Если больше, то можно начинать думать об оптимизации. Самое простое — разнести вендор-файлы и файлы приложения. Приложение обновляется намного чаще, чем библиотеки, поэтому в основном клиенты будут перекачивать лишь малую часть данных.
Если приложение совсем большое (или в каких-то разделах используются тяжёлые библиотеки), то можно уже группировать по частям — common + отдельные файлы для каждого раздела. В статье об этом не написано, потому что в общем случае это делается нетривиальным образом — или всё разносить по файлам руками, имея риск что-то забыть/перепутать, или с самого начала выбирать архитектуру приложения, исходя из этого требования. Здесь можно отметить яндексовские BEM + bem-tools и более новый webpack.
Есть и другой интересный момент — если файлов становится слишком много (включая все скрипты, стили и картинки), то чтобы не нарваться на ограничение на число параллельных запросов на один домен, можно начинать разносить статику по разным поддоменам штук по 6 ссылок на каждый. Но здесь уже всё совсем индивидуально — надо тестировать, экспериментировать, проверять на различных типах подключения и т.д., иначе можно скорее потерять в скорости загрузки сайта.
Насчёт библиотек по CDN. Использовать сторонние скрипты в HTML я бы никогда не стал и никому не советую. Во-первых, добавляется ещё одна точка отказа. Все падают — и Гугл, и Яндекс, и, думаю, мало кому из ваших клиентов понравится увидеть полностью неработающий сайт только потому что какой-то из внешних ресурсов отвалился (а обычно их прям пачкой добавляют). Во-вторых, вы точно осознаёте, что загружая скрипт с чужого сервера, вы по сути даёте кому-то полный контроль за вашим сайтом? Популярный CDN, конечно, не будет скорее всего кого-то ломать, но его ведь могут и самого поломать.
Да и эффективность такого решения по моему мнению сильно преувеличена — вы скорее проиграете на резолве домена и разогреве кэша, чем при прогоне десятка килобайт по открытому TCP-соединению с разогретым congestion window. (Какой-то крупный сайт публиковал отчёт по поводу процента клиентов с разогретым кэшом на главной странице, и цифры там были далеко не большие.)