Если взять Хабр, то рандомный автор публикуется редко, но по своей совокупности материалы таких авторов создают разнообразный контент на протяжении длительного периода времени. И самое главное, что эти публикации попадают в общую ленту.
Взять любой канал в телеге, если это не юмор, не новости, то читаешь узкоспециализированную инфу. Рано или поздно наступает перенасыщение. И канал автора становится неинтересен. Аналог ленты в телеге - это папки, которые состоят из тех каналов, которые пробились через информационный шум. И в этой папке-ленте нет места для новых рандомных каналов, я о них никогда не узнаю. Да и папка с подборкой каналов также с течением времени становится неинтересной. Не хватает рекомендаций рандомного канала.
В Яндекс.Такси можно было бы завести семейные учётные записи, чтобы получать информацию об истории передвижения связанных аккаунтов. С возможностью не делиться информацией по конкретным поездкам.
Я думаю, что внутреннюю проверку по линии безопасности они сразу провели, увидели, что проблемы нет: довезли, высадили. И с водителем поговорили. Поэтому их поведение мне полностью понятно. В том числе нежелание предоставить информацию о передвижении клиентов посторонним.
А супруге можно было бы подарить смарт часы или фитнес браслет, чтобы при звонке вибрировал на руке, когда телефон лежит в сумке.
Скажите, а рассматривали ли вы возможность технической защиты программного кода? Не посещала ли мысль, что кто-то один купит лицензию, а потом по рукам распространит версию Про со всеми наворотами?
Веб-компоненты - это просто кастомные DOM-элементы, поэтому и жизненный цикл начинается с connectedCallback.
В веб компонентах логика отображения смешивается с обычной логикой работы
Вот как раз наоборот, веб-компоненты заточены только под отображение и взаимодействие с пользователем через шину событий. Логика, как и при работе с классическими элементами, обычно выносится отдельно.
Там только строки, в атрибутах, нет типизация получается, вот это и плохо
Если работать только через атрибуты, то, конечно, будут строки. И это потому что разметка страницы - это текст. Если же идет речь о том, как передать объект компоненту для его обработки, то пропишите соответствующий метод или свойство в классе веб-компонента, и вызывайте потом в коде.
adoptedStyleSheets - Есть решение лучше, чем писать стили в js
adoptedStyleSheets используется для подключения текстового содержимого в качестве css-таблицы в тень элемента. Причем это делается в connectedCallback. Само же содержимое стиля может быть вынесено в отдельный esm-модуль. Так что смешения тут никакого нет. Да и логика существования самого веб-компонента не нарушена. Потому что веб-компонент - это все-таки про вьюху.
Согласен, что плодить новые сущности в виде кастомных компонентов надо тогда, когда можно существенно упростить разметку. Джаваскриптовое поведение можно и через is аккуратно подключить, оставляя понятные всем теги.
Графоманство в ТЗ больше для юридических вопросов. Например, исполнитель что-то не так сделал, тогда конкретно начинают тыкать в такой-то пункт сто страничного ТЗ.
Я тоже сторонник макетов, схем, таблиц. И только в случае необходимости письменных пояснений.
Один из недостатков: json-rpc в спецификации не гарантирует порядок результатов при пакетных запросах. Но я бы не сказал, что это фатально. Если разработчику важен порядок в массиве результатов, то он просто учтет этот момент у себя в коде. То, что нет четко закреплённого списка ошибок - тоже спорный момент.
Статус 200 - это просто успешный транспорт payload. И дело тут не в батчинге.
Насколько я помню, куки по мнению РКН персонифицируют пользователя. По этой причине всю информацию связанную с сессией надо хранить. Понятное дело, что куки разные бывают: одни для персонификации, другие для сохранения настроек отображения сайта и т.п. Но я не увидел нигде: законодатель разделяет эти понятия или нет. Как кому-то потом рассказывать какие у нас куки.
Если не так, то буду рад. Если есть ссылки на нормативную базу, буду только рад.
Все верно сказали. Классические сниппеты явно нельзя использовать. Только динамическое подключение джаваскриптом сайта. Писать такое пару строк.
Когда дают согласие на куки, то можно в localstorage записать инфу. Далее, проверяем при загрузке страницы если такая пометка в localstorage имеется, то динамически добавляем теги скриптов с метриками.
Вот кстати не факт, что выигрыш в производительности будет: так-то и подключение к бд тоже несёт накладные расходы, в виде организации подключения по tcp, проверка прав пользователя и опять же чтения данных из группы файлов. Если необходимо работать с развесистыми данными, писать, читать, уделять внимание безопасности, то да, тут работа с СУБД лучше. А если выбирать между чтением и разбором мелкого json и использованием огромной махины СУБД для той же цели, то первое может быть более оптимальным выбором. Тем более, если чтение, то блокировки файлов не будет.
Если взять Хабр, то рандомный автор публикуется редко, но по своей совокупности материалы таких авторов создают разнообразный контент на протяжении длительного периода времени. И самое главное, что эти публикации попадают в общую ленту.
Взять любой канал в телеге, если это не юмор, не новости, то читаешь узкоспециализированную инфу. Рано или поздно наступает перенасыщение. И канал автора становится неинтересен. Аналог ленты в телеге - это папки, которые состоят из тех каналов, которые пробились через информационный шум. И в этой папке-ленте нет места для новых рандомных каналов, я о них никогда не узнаю. Да и папка с подборкой каналов также с течением времени становится неинтересной. Не хватает рекомендаций рандомного канала.
Пиринговый webrtc существенно помогает в решении проблемы нехватки ресурсов.
Прикольно. Нейронка локальная или расшифровка через облако? В опенсорсе есть она? Интересно было бы посмотреть ее.
Постгрес выбирают, потому что в некоторых организациях требуют использовать ПО из реестра. Плюс официальная техподдержка.
В Яндекс.Такси можно было бы завести семейные учётные записи, чтобы получать информацию об истории передвижения связанных аккаунтов. С возможностью не делиться информацией по конкретным поездкам.
Я думаю, что внутреннюю проверку по линии безопасности они сразу провели, увидели, что проблемы нет: довезли, высадили. И с водителем поговорили. Поэтому их поведение мне полностью понятно. В том числе нежелание предоставить информацию о передвижении клиентов посторонним.
А супруге можно было бы подарить смарт часы или фитнес браслет, чтобы при звонке вибрировал на руке, когда телефон лежит в сумке.
Все круто! Спасибо, что делитесь. Нет ли проблемы рассинхрона видео и аудио потоков?
Согласен. А еще спасает мысль о том, что в чужом коде программистам будет тяжело разобраться, проще обратиться к разработчику напрямую.
Сейчас, на всякий, рассматриваем KPHP (разработка VK) - он позволяет компилировать php-код в бинарник.
Очень классно написали. Спасибо.
Скажите, а рассматривали ли вы возможность технической защиты программного кода? Не посещала ли мысль, что кто-то один купит лицензию, а потом по рукам распространит версию Про со всеми наворотами?
Веб-компоненты - это просто кастомные DOM-элементы, поэтому и жизненный цикл начинается с connectedCallback.
Вот как раз наоборот, веб-компоненты заточены только под отображение и взаимодействие с пользователем через шину событий. Логика, как и при работе с классическими элементами, обычно выносится отдельно.
Если работать только через атрибуты, то, конечно, будут строки. И это потому что разметка страницы - это текст. Если же идет речь о том, как передать объект компоненту для его обработки, то пропишите соответствующий метод или свойство в классе веб-компонента, и вызывайте потом в коде.
adoptedStyleSheets используется для подключения текстового содержимого в качестве css-таблицы в тень элемента. Причем это делается в connectedCallback. Само же содержимое стиля может быть вынесено в отдельный esm-модуль. Так что смешения тут никакого нет. Да и логика существования самого веб-компонента не нарушена. Потому что веб-компонент - это все-таки про вьюху.
+1. Действительно! Я-то думал, что будущее уже наступило и все давно поддерживается) Вот оно что. Тогда только кастомное имя остаётся.
https://caniuse.com/mdn-html_global_attributes_is
Спасибо, что делитесь опытом, интересная работа.
Кстати, а почему всё-таки от ваниллы отказались? С какими сложностями столкнулись?
Согласен, что плодить новые сущности в виде кастомных компонентов надо тогда, когда можно существенно упростить разметку. Джаваскриптовое поведение можно и через is аккуратно подключить, оставляя понятные всем теги.
Графоманство в ТЗ больше для юридических вопросов. Например, исполнитель что-то не так сделал, тогда конкретно начинают тыкать в такой-то пункт сто страничного ТЗ.
Я тоже сторонник макетов, схем, таблиц. И только в случае необходимости письменных пояснений.
Можете раскрыть мысль почему long polling по вашему мнению будет дешевле?
Один из недостатков: json-rpc в спецификации не гарантирует порядок результатов при пакетных запросах. Но я бы не сказал, что это фатально. Если разработчику важен порядок в массиве результатов, то он просто учтет этот момент у себя в коде. То, что нет четко закреплённого списка ошибок - тоже спорный момент.
Статус 200 - это просто успешный транспорт payload. И дело тут не в батчинге.
Насколько я помню, куки по мнению РКН персонифицируют пользователя. По этой причине всю информацию связанную с сессией надо хранить. Понятное дело, что куки разные бывают: одни для персонификации, другие для сохранения настроек отображения сайта и т.п. Но я не увидел нигде: законодатель разделяет эти понятия или нет. Как кому-то потом рассказывать какие у нас куки.
Если не так, то буду рад. Если есть ссылки на нормативную базу, буду только рад.
К get-запросу на получение скрипта можно было бы просто добавить "?<lottie_file_version>".
А так, работа с кешем на таком уровне - это больше про офлайн pwa.
Требование к хранению собранной информации о пользователе предъявляется же к администратору сайта.
Все верно сказали. Классические сниппеты явно нельзя использовать. Только динамическое подключение джаваскриптом сайта. Писать такое пару строк.
Когда дают согласие на куки, то можно в localstorage записать инфу. Далее, проверяем при загрузке страницы если такая пометка в localstorage имеется, то динамически добавляем теги скриптов с метриками.
Вот кстати не факт, что выигрыш в производительности будет: так-то и подключение к бд тоже несёт накладные расходы, в виде организации подключения по tcp, проверка прав пользователя и опять же чтения данных из группы файлов. Если необходимо работать с развесистыми данными, писать, читать, уделять внимание безопасности, то да, тут работа с СУБД лучше. А если выбирать между чтением и разбором мелкого json и использованием огромной махины СУБД для той же цели, то первое может быть более оптимальным выбором. Тем более, если чтение, то блокировки файлов не будет.