Стейблкоины. Как привязывают и почему не отвязывается!?

Стэйблы будущего это основанные на Ergo - SigmaUSD/DexyGold/SigmaGold и самое лютое - ChainCash

Круглосуточная трансляция CCTV IP Камеры на Youtube

На правах шутки. Откройте форточку этому господину.

AMD — вечная канарейка Intel

Насколько я читал там тема была даже не с IBM, а с оборонкой, которая требовала не просто second-source, а тупо наличие нескольких поставщиков для участия в тендерах

Странная архитектура

ой, да я целые куски кода иногда внедряю через какой-то то if и проверку feature flag, а потом перед окончательным внедрением некоторое время остается

if(true){...}

Как снимали первого «Чужого» и почему он намного страшнее, чем кажется

Четвертый прекрасен, ибо ЖПЖ тоже умеет снимать, отчетливо видно такой европейский стиль что-ли.

Создание сервера для онлайн ММО игр на PHP ч. 10 — Открытый бесшовный мир в 2D игре

Я про то, что во время перехода игрока между серверами он может временно быть одновременно на двух серверах, виртуально, чтоб игроки этих серверов в момент перехода его ощущали как бы на их сервере. Это как DSG коробки с двумя сцеплениями

Создание сервера для онлайн ММО игр на PHP ч. 10 — Открытый бесшовный мир в 2D игре

Так у них бой и локация это тоже отдельный процесс на каком-то сервере.

Создание сервера для онлайн ММО игр на PHP ч. 10 — Открытый бесшовный мир в 2D игре

Посмотрите как-нить доклад варгейминга про WoT, у них очень забавная архитектура, вплоть до того, что один бой (ну типа локация в вашем случае) может быть запущен на соседних серверах одновременно, чтоб в случае падения одного процесса игроки плавно переключаются на соседний процесс. В вашем случае для "плавности" игрок переходящий через шов может какое-то время одновременно обсчитываться в двух локациях, чтоб игроки этих локаций как бы видели его со своих сторон. Или я не так понял?
Да и логин сервера обычно к игровым отношения не имеют

MariaDB, фрагментация, varchar и печалька

Хоть кто-то проверил в реальном примере то, о чем я говорил на хабре уже не раз. Особенно камраду @FanatPHP. В нашем случае, мы знаем, что некоторые наши данные не меньше условных 128 не больше 255, и жертвуя местом используем varchar 255, но fixed row format и AriaDB Engine (по факту это char, ибо место на строку фиксируется максимальным размером данных). Зато скорость и отсутствие фрагментации. Ибо на 30 миллионах строк optimize на нашем древнем железе (Baremetal: Xeon E5-2609, 32Gb RAM. MariaDB VM: 4 core, 12GB RAM) будет делаться сутки :-)

Пишем Telegram бота для распознавания голосовых сообщений и их обработки с помощью AI

Более того, он и под Windows взлетает с полтычка даже на "полярисах", но в любом варианте требуется CPU не ниже intel core третьего поколения (там добавили FP16).

Плюсом достойные результаты зависят от модели, условно 500 мегабайтная делает ошибочки, 1500 Мб уже существенно лучше, но тут уж все зависит от размера доступной памяти как в системе, так и на GPU.

Пишем Telegram бота для распознавания голосовых сообщений и их обработки с помощью AI

И наконец, последний аргумент в пользу whisper - цена. Он кратно дешевле.

Он вообще-то в опесорсе, ставите себе на сервер и никаких ограничений + умеет чисто на CPU, правда медленнее, чем с GPU.

Советский UNIX. Как в СССР ковали собственную операционную систему

Мало кто догадывается, что если отрезать один бит от КОИ-8, то текст превращался в несколько неправильную, но понятную транслитерацию в ASCII

Рендеринг на сервере и HTMX — это будущее

ставит/снимает классы ошибки с самого поля и прилежащего HTMLSpanElement, которому в textContent записывает/снимает сообщение об ошибке, стандартное из HTMLInputElement.validationMessage или своё, самодельное :)

Я уже написал, там и так проверяются все поля, но как раз через нормальную работу с Validation API, то есть биндим на form событие invalid, где в замыкании переопределяем стандартное поведение (вот те baloon браузерные погасить) и вызываем уже свою функцию которая будет куда надо выдавать сообщения, стандартные или нет (кстати в event.target у формы при таком событии как раз невалидный input). Мы это делаем не через текст в самом блоке, а через дата атрибуты и CSS - можно посмотреть ниже пример, мы не навешиваем класссы, псевдокласс :invalid и так сам навешивается

Плюс этого подхода в том, что при даже отправке формы и серверной валидации мы можем через setCustom вызвать всю эту цепочку автоматически

Рендеринг на сервере и HTMX — это будущее

весьма любопытную технику

Эта техника используется довольно широко, вплоть до того, что если в Accept нет application/json, то отдаем json с заголовком text/plain

Рендеринг на сервере и HTMX — это будущее

Технические моменты, на моем скриншоте еще что-то подобное

input:invalid + .error-block::before {
  /* icon */
}
input:invalid + .error-block::after {
    content: attr(data-content);
}
input + .error-block {
  display: none;
}
input:invalid + .error-block {
  display: flex;
}

И соответственно, меняя атрибут data-content можно текст ошибки менять, не меняя содержимое самого блока ошибки напрямую

Рендеринг на сервере и HTMX — это будущее

input это событие такое? Хм.. Надо почитать про это, ни разу что-то не пользовался. А в целом исторически, ибо не все нажатия кнопок в полях ввода вызывают change, а отпускание кнопки keyup таки да. Плюс там местами (в конкретном случае название города) на keyup навешан выбор города из разрешенных (мы берем НП своего региона с населением 1000+ граждан, в более мелких смысла нет)

Рендеринг на сервере и HTMX — это будущее

Переключатель чего? проверки reportValidity?
В зависимости от поля, change или keyup для текстовых

Рендеринг на сервере и HTMX — это будущее

Да, но она просто устанавливает HTMLInputElement.validationMessage в кастомное, к валидации на вводе это отношение не имеет.

Не совсем, если сообщение не пустое - то и state становится invalid, если пустое - то state сбрасывается на валидный.

It's vital to set the message to an empty string if there are no errors. As long as the error message is not empty, the form will not pass validation and will not be submitted.

А уж как вы обернете reportValidity() это реально вторично, мы вот так сделали например

В данном случае мы в textContent  у ошибок ничего не добавляем, только меняем data атрибут и контент из него попадает через :before + :after с помощью CSS. Нам так показалось удобнее (просто пустые элементы с классом в шаблоне)

Рендеринг на сервере и HTMX — это будущее

Я же не говорю, что JS не нужен совсем. Минимальная валидация средствами браузера есть и работает. Хотите плюшек - делайте с JS, но, внимательно прочитайте, что я писал. Для минимальной не нужен. Для плюшек понадобится, но хорошим вариантом должно быть то, что плюшки используют этот же API, для единообразия. Ибо setCustomValidity() в стандарте не просто так - а именно для этого. А уж как вы оформите сообщения (а они оформляются) и :invalid states – это вторично

Рендеринг на сервере и HTMX — это будущее

Ну тут боюсь они еще не определились окончательно, но учитывая что 90% их это Chromium, то да :-)