Насчёт привязки тройки к телефону: такая возможность была в 2016 году, ясно дело не очевидно (уже даже не припомню действия). Сейчас же можно сказать по большей части привязку заменили сервисом «Мобильный билет».
А еще есть актививация денег — то есть закинуть кое как денег на тройку можно, но пользоваться ими нельзя, надо ехать до метро.
А на этот счёт я скажу так: всё зависит от способа и инструмента зачисления денег на карту тройка.
Если вы пополняете «Кошелёк» тройки или конкретные билеты через мобильное приложение (партнёров), то действительно необходимо «Активировать» (по сути записать валидные данные на тройку) с помощью жёлтого терминала, которые установлены только в метро.
Но опять таки существует и официальное приложение (От ВТБ Банк Москвы, на их инфраструктуре держится система карты тройка), при пополнении через которое «Активация» терминалом не требуется (приложение записывает валидные данные).
Могу посоветовать обратить внимание на событие `response`:
page.on('response', response => {
// Skip http bad statuses.
if (!response.ok()) return;
const headers = response.headers();
// Skip any content that type not application/octet-stream
if (headers['Content-Type'] !== 'application/octet-stream') return;
const buffer = await response.buffer();
// Do what you want
});
await page.goto('https://example.com/some.file');
Вместо вызова `response.buffer()` можно ещё использовать `response.text()`, если работа идёт с текстовыми файлами.
P.S. этот код полностью исполняется в контексте Nodejs
Вот так habrahabr.ru/post/seo-optimizaciya-stati — не очень хорошо. Лучше, что бы робот сразу видел, что это страница, а не каталог. Т.е. вида habrahabr.ru/post/seo-optimizaciya-stati.html
Это никак не влияет ни на один фактор, поисковым системам всё-равно есть у страницы расширение или нет и это подтверждается официально. Информацию о типе ресурса поисковые роботы получают из HTTP заголовка Content-Type, если он не указан по умолчанию считается text/plain.
Но что--то мне подсказывает что это очень затратная операция и он делает это не для всего инетернет.
Ну там всё по уму сделано, чтобы минимизировать затраты во первых ускорены во много раз часы т.е. Date.now() через 1 реальную секунду будет отличаться в несколько раз больше чем на секунду. А ещё функция Math.random() возвращает заранее просчитанные дискретные значения. Вообщем там всё сделано, чтобы минимизировать затраты.
Так что используется это для всех страниц, а в плане рейтинга есть другие причины: т.к. страница при загрузке без рендера на клиенте содержит мало теоретически полезной для пользователя информации, то и весовой рейтинг получает меньше и это скорее недоработка.
Ну это не главное на самом деле, просто ветка пошла с того, что если добавить «дополнительные критерии», то React с JSX выпадет из рейтинга. Под этими «дополнительными критериями» подразумевалось в том числе и SEO. Так вот это сильно ошибочное утверждение т.к. есть опять таки тот же riot.js и как я указывал несколько выше NextJS, позволяющие делать универсальные приложения одинаково работающие как на клиенте, так и на сервере. Да даже без них есть ряд сервисов кеширующих клиентский рендер (на базе Chrome).
В мире SEO больше нет поддержки Ajax. Это от Google. Преимуществ нет.
Кто вам такую чушь сказал? Google как начал использовать робота основанного на Chrome так и использует, да некоторые фишки он не поддерживает т.к. на данный момент основан на Chrome 43. Но вся остальная поддержка JS и выливающихся остаётся.
А потом fetch запросы на клиенте упрощают жизнь в первую и непосредственную очередь для пользователей, а не роботов. А для роботов и пользователей без JS мы сами отрисовываем страницу.
React отрабатывает как на сервере так и на клиенте. Если клиент не поддерживает JS, нет проблем т.к. рендер дублируется на сервере. Если клиент поддерживает JS, при внутренних переходах он получает не всю страницу отрендеренную на сервере страницу, а только данные для рендера и уже клиент сам отрисовывает страницу, тем самым в том числе уменьшая объём передаваемых данных. Если кратко — это один и тот же код на React.
React с JSX не вывалится. Ведь главная проблема JS фреймворков в плане SEO была именно из-за того, что поисковые боты их не могли индексировать т.к. они рендерятся на клиенте (для этого нужен JS и немного иная логика робота), но у крупных поисковиков уже умеют как пару лет, а у остальных получаем индексирование с серверным рендерингом. В мире React для этого есть хороший фреймворк NextJS.
Правда ввиду невозможности наследования прозрачного цвета (тот же цвет, но с альфа каналом в нуле) и особенностей обработки градиентов в некоторых браузерах может получиться эффект перехода любого цвета в прозрачный чёрный.
Лично мне совершенно неясно, почему домены верхнего уровня выданы по одной штуке на государство — при том, что государства различаются по размеру ну очень сильно.
Почему же по одной штуке? Возможно это будет открытием, но у РФ 3 национальных домена .su, .ru и.рф под управлением Координационного центра национального домена сети Интернет (по сути гос. компания).
На мой взгляд, город с населением в миллион человек имеет такое же право на домен верхнего уровня, как и мелкое государство. В таком случае организации, ведущие деятельность в Москве, регистрировали бы домены в зоне верхнего уровня «msk»;
Очередное открытие: существуют домены верхнего уровня .moscow и.москва под управлением Фонда содействия развитию технологий и инфраструктуры Интернета. Другой пример .nyc у Нью-Йорка.
А чем больше доменов — тем ниже уровень монополизации в сфере регистрации доменов
А вам не достаточно 1572 домена верхнего уровня? По поводу регистраторов это уже никак не связано с количеством доменов верхнего уровня: регистраторы не равно администраторы, они лишь посредники.
Так же обращаю внимание, что ICANN работает с разными компаниями, так национальные домены разных стран управляются государственными компаниями соответствующих стран. Более того вообще говоря зарегистрировать домен верхнего уровня может любая компания, но если сможет доказать, что это действительно очень нужно. Например, Яндекс в прошлом году добились регистрации домена верхнего уровня (.yandex) для собственных нужд. И собственно Яндекс не единственные как-нибудь посмотрите вот этот список: https://www.iana.org/domains/root/db
Интеграция с системой умного дома будет, вообще у Яндекса в этом году достаточно сюрпризов и проектов о которых они ничего не говорят во всяком случае пока не говорят.
> В чем проблема сделать HTTP/2 без принудительного шифрования, как в HTTP/1.1, когда администратор сам решает, что ему надо — шифрование, производительность или и то, и то вместе взятое?
Так в текущем стандарте это и предусмотрено: хочешь используй HTTP/2 + SSL (h2), хочешь используй HTTP/2 only (h2c). Стандарт ни как принудительно не связывает HTTP/2 с SSL (только рекомендует), так же как и стандарт HTTP/1.1 не связывает его с SSL.
Например, за счёт одного TCP соединения HTTP/2 решает проблему съедаемого времени при открытии канала TCP+TLS, причём банально одно соединение = один handshake. Именно по этому его больше продвигают под флагом «SSL everywhere». Вообще воспринимать один TCP канал в HTTP/2 нужно как асинхронную, более долгосрочную альтернативу Keep-Alive в HTTP/1.1.
А на этот счёт я скажу так: всё зависит от способа и инструмента зачисления денег на карту тройка.
Если вы пополняете «Кошелёк» тройки или конкретные билеты через мобильное приложение (партнёров), то действительно необходимо «Активировать» (по сути записать валидные данные на тройку) с помощью жёлтого терминала, которые установлены только в метро.
Но опять таки существует и официальное приложение (От ВТБ Банк Москвы, на их инфраструктуре держится система карты тройка), при пополнении через которое «Активация» терминалом не требуется (приложение записывает валидные данные).
Вместо вызова `response.buffer()` можно ещё использовать `response.text()`, если работа идёт с текстовыми файлами.
P.S. этот код полностью исполняется в контексте Nodejs
Это никак не влияет ни на один фактор, поисковым системам всё-равно есть у страницы расширение или нет и это подтверждается официально. Информацию о типе ресурса поисковые роботы получают из HTTP заголовка Content-Type, если он не указан по умолчанию считается text/plain.
Так что используется это для всех страниц, а в плане рейтинга есть другие причины: т.к. страница при загрузке без рендера на клиенте содержит мало теоретически полезной для пользователя информации, то и весовой рейтинг получает меньше и это скорее недоработка.
Ну это не главное на самом деле, просто ветка пошла с того, что если добавить «дополнительные критерии», то React с JSX выпадет из рейтинга. Под этими «дополнительными критериями» подразумевалось в том числе и SEO. Так вот это сильно ошибочное утверждение т.к. есть опять таки тот же riot.js и как я указывал несколько выше NextJS, позволяющие делать универсальные приложения одинаково работающие как на клиенте, так и на сервере. Да даже без них есть ряд сервисов кеширующих клиентский рендер (на базе Chrome).
Кто вам такую чушь сказал? Google как начал использовать робота основанного на Chrome так и использует, да некоторые фишки он не поддерживает т.к. на данный момент основан на Chrome 43. Но вся остальная поддержка JS и выливающихся остаётся.
А потом fetch запросы на клиенте упрощают жизнь в первую и непосредственную очередь для пользователей, а не роботов. А для роботов и пользователей без JS мы сами отрисовываем страницу.
React отрабатывает как на сервере так и на клиенте. Если клиент не поддерживает JS, нет проблем т.к. рендер дублируется на сервере. Если клиент поддерживает JS, при внутренних переходах он получает не всю страницу отрендеренную на сервере страницу, а только данные для рендера и уже клиент сам отрисовывает страницу, тем самым в том числе уменьшая объём передаваемых данных. Если кратко — это один и тот же код на React.
Правда ввиду невозможности наследования прозрачного цвета (тот же цвет, но с альфа каналом в нуле) и особенностей обработки градиентов в некоторых браузерах может получиться эффект перехода любого цвета в прозрачный чёрный.
Почему же по одной штуке? Возможно это будет открытием, но у РФ 3 национальных домена .su, .ru и.рф под управлением Координационного центра национального домена сети Интернет (по сути гос. компания).
Очередное открытие: существуют домены верхнего уровня .moscow и.москва под управлением Фонда содействия развитию технологий и инфраструктуры Интернета. Другой пример .nyc у Нью-Йорка.
А вам не достаточно 1572 домена верхнего уровня? По поводу регистраторов это уже никак не связано с количеством доменов верхнего уровня: регистраторы не равно администраторы, они лишь посредники.
Так же обращаю внимание, что ICANN работает с разными компаниями, так национальные домены разных стран управляются государственными компаниями соответствующих стран. Более того вообще говоря зарегистрировать домен верхнего уровня может любая компания, но если сможет доказать, что это действительно очень нужно. Например, Яндекс в прошлом году добились регистрации домена верхнего уровня (.yandex) для собственных нужд. И собственно Яндекс не единственные как-нибудь посмотрите вот этот список: https://www.iana.org/domains/root/db
Так в текущем стандарте это и предусмотрено: хочешь используй HTTP/2 + SSL (h2), хочешь используй HTTP/2 only (h2c). Стандарт ни как принудительно не связывает HTTP/2 с SSL (только рекомендует), так же как и стандарт HTTP/1.1 не связывает его с SSL.
Например, за счёт одного TCP соединения HTTP/2 решает проблему съедаемого времени при открытии канала TCP+TLS, причём банально одно соединение = один handshake. Именно по этому его больше продвигают под флагом «SSL everywhere». Вообще воспринимать один TCP канал в HTTP/2 нужно как асинхронную, более долгосрочную альтернативу Keep-Alive в HTTP/1.1.