На сколько я знаком с ним, divkit — это движок рендеринга, который на основе JSON умеет рендерить интерфейс. В Авито — это Beduin. Bricks же — это визуальная no code платформа над этим движком, которая позволяет не писать json, а управлять разметкой через интерфейс, то есть доступна не только разработчикам.
Кроме того, она дает механизмы релизов этой разметки и версионирования изменений. И еще много других механик.
Это синтетическое демо возможностей протокола и прироста производительности в 4-10 раз вы никогда не увидите на более или менее реальном примере. Посмотрите хотябы на результаты на моем не очень быстром интернете.
Так что прирост на 30-50% — это то, на что вы можете рассчитывать в реальности.
С чего вы взяли, что спецификация требует устанавливать только одно соединение с хостом? Их может быть множество, и в каждом соединении может существовать несколько потоков, которые грузят ресурсы одновременно.
Файлы cookie обычно хранятся на жестком диске в специальной папке браузера. Местоположение этой папки зависит от используемого браузера и операционной системы.
Вопрос номер два я не могу использовать картинки с локалхост в webgl без строки img.crossOrigin = ""
Видимо имелось в виду, что сам протокол не обязывает передавать идентификаторы сессий и не обязывает хранить некое состояние, привязанное к клиенту. Потому как чуть менее чем всегда приложения могут менять состояние и могут отличить одного клиента от другого.
Имелось в виду именно то, что написано. Протокол не умеет хранить состояние между запросами и это одна из главных его архитектурных особенностей. Передача данных через куки, это специальная механика, которая позволяет решить проблему передачи состояния через заголовки без необходимости менять архитектуру протокола. И об этом будет следующая статья.
Это зависит от соглашений, принятых в конкретной команде. Вообще создание ресурсов делают через POST, а изменение через PUT / PATCH.
Тут я правда ошибся, 201 для POST должен возвращаться. Спасибо, что подсветили.
Формат query string никак не специфицирован протоколом. Большинство серверов сейчас разбирают по аналогии с x-ww-form-urlencoded, но на заре веба можно было встретить строки запроса с другими разделителями (; например).
Все верно, формат не стандартизирован. Однако разделитель & является рекомендацией W3C и де-факто стандартом. Так что, как веб сервера делали это на заре своего существования не имеет никакого значения. Важно то, как это работает сейчас.
Тут вступает в игру Transfer-Encoding
Эти случаи будут рассмотрены в следующих статьях.
Во-вторых, результат множественного вызова должен приводить к таким же "последствиям", что и единичный вызов.
Тут правда не удачную формулировку выбрал. Спасибо, что подсветили. Поправил в статье.
Мы здесь все-таки говорим о маленьких объемах текста и в области рекламы. Для пользователей, особенно профессиональных, важно, какое количество текста они могут разместить в свое объявлении. А количество знаков — самы универсальный показатель.
Q: What is the difference between UCS-2 and UTF-16?
UCS-2 is obsolete terminology which refers to a Unicode implementation up to Unicode 1.1, before surrogate code points and UTF-16 were added to Version 2.0 of the standard. This term should now be avoided. UCS-2 does not describe a data format distinct from UTF-16, because both use exactly the same 16-bit code unit representations. However, UCS-2 does not interpret surrogate code points, and thus cannot be used to conformantly represent supplementary characters. Sometimes in the past an implementation has been labeled "UCS-2" to indicate that it does not support supplementary characters and doesn't interpret pairs of surrogate code points as characters. Such an implementation would not handle processing of character properties, code point boundaries, collation, etc. for supplementary characters.
С нулевым опытом вас никто в продуктовую компанию не возьмет. Только если есть стажерские программы и компания готова в вас вваливать кучу времени и денег на обучение.
У этого эмодзи не одна кодовая точка. Он состоит из строки, в которой есть три базовых эмодзи, соединенных через ZWJ, а каждый базовый эмодзи состоит из суррогатной пары.
В мессенджере вы конечно можете его исспользовать ???.
В принципе, тоже вариант, как другие, но подсчет будет не точный. Ведь любой символ не из bmp занимает две кодовые точки (суррогатные пары), а диакритические комбинации могут занимать сильно больше четырех.
На сколько я знаком с ним, divkit — это движок рендеринга, который на основе JSON умеет рендерить интерфейс. В Авито — это Beduin. Bricks же — это визуальная no code платформа над этим движком, которая позволяет не писать json, а управлять разметкой через интерфейс, то есть доступна не только разработчикам.
Кроме того, она дает механизмы релизов этой разметки и версионирования изменений. И еще много других механик.
Это хорошее замечание, спасибо, внесу правку в статью. Стоит только уточнить, что в HTTP/1.0 keep-alive не был стандартизирован.
Это синтетическое демо возможностей протокола и прироста производительности в 4-10 раз вы никогда не увидите на более или менее реальном примере. Посмотрите хотябы на результаты на моем не очень быстром интернете.
Так что прирост на 30-50% — это то, на что вы можете рассчитывать в реальности.
С чего вы взяли, что спецификация требует устанавливать только одно соединение с хостом? Их может быть множество, и в каждом соединении может существовать несколько потоков, которые грузят ресурсы одновременно.
Здравствуйте. Спасибо за приятный отзыв.
Компрессию заголовков можно принудительно выключить в HTTP/2. К сожалению, не могу сказать как это будет работать в связке с Kafka.
Файлы cookie обычно хранятся на жестком диске в специальной папке браузера. Местоположение этой папки зависит от используемого браузера и операционной системы.
Ваш вопрос не ясен.
Имелось в виду именно то, что написано. Протокол не умеет хранить состояние между запросами и это одна из главных его архитектурных особенностей. Передача данных через куки, это специальная механика, которая позволяет решить проблему передачи состояния через заголовки без необходимости менять архитектуру протокола. И об этом будет следующая статья.
Тут я правда ошибся, 201 для POST должен возвращаться. Спасибо, что подсветили.
Все верно, формат не стандартизирован. Однако разделитель
&является рекомендацией W3C и де-факто стандартом. Так что, как веб сервера делали это на заре своего существования не имеет никакого значения. Важно то, как это работает сейчас.Эти случаи будут рассмотрены в следующих статьях.
Тут правда не удачную формулировку выбрал. Спасибо, что подсветили. Поправил в статье.
Здравствуйте. Все это будет в следующих статьях.
Мы здесь все-таки говорим о маленьких объемах текста и в области рекламы. Для пользователей, особенно профессиональных, важно, какое количество текста они могут разместить в свое объявлении. А количество знаков — самы универсальный показатель.
Неплохая статья, но хотелось бы примеров, как правильно адаптировать html.
Про UCS-2
Можете подсказать какой-нибудь материал по этому вопросу?
Я, откровенно говоря, не понял в каких случаях JS может использовать UCS-2 когда разбирался с темой.
Место, занимаемое в БД зависит от реализации конкретной базы.
Не понял, почему в 8 раз больше?
Webp давно устарел. Надо использовать Avif там, где это возможно.
Такого не бывает)
С нулевым опытом вас никто в продуктовую компанию не возьмет. Только если есть стажерские программы и компания готова в вас вваливать кучу времени и денег на обучение.
В 2022 году рекомендовать jquery - это как рекомендовать использовать везде var.
debugger )
У этого эмодзи не одна кодовая точка. Он состоит из строки, в которой есть три базовых эмодзи, соединенных через ZWJ, а каждый базовый эмодзи состоит из суррогатной пары.
В мессенджере вы конечно можете его исспользовать ???.
В принципе, тоже вариант, как другие, но подсчет будет не точный. Ведь любой символ не из bmp занимает две кодовые точки (суррогатные пары), а диакритические комбинации могут занимать сильно больше четырех.
К сожалению, я не знаю, как в деталях работает поиск. Обязательно передам ваш комментарий коллегам.