Rouslan943

CapeRatel:

Сообщество живое русское есть где нибудь?

Язык программирования Go
Русскоязычный подкаст о Go

По клику на кнопку у неё меняется состояние. В данном случае - data атрибут.
По ховеру и по значению этого атрибута задано одинаковое оформление.

Самые большие затраты на ввод/вывод. Грубо говоря, если один запрос 90% времени ожидает I/O, то в случае 10 000 конкурентных запросов сервер 9,999% времени находится в ожидании I/O, а асинхронное выполнение позволяет это время использовать с пользой или попросту списать. В то время как многопоточный сервер, обрабатывающий 10k соединений, 90% времени будет тратить на переключение контекста, да и то, если памяти хватит.

Как человек, который 1.5 года учился java, а потом вышел работать с C# - точно могу сказать, разница несущественна. Специалисту всё равно какой инструмент он использует. Хотите наиболее производительное мобильное приложение - используете java, хотите desktop windows, вэб бэкенд, игры - C# (имхо). ML - python. Микроконтроллеры - C (C++). Хотите делать качественное ПО для всего вышеперечисленного, тогда я вам огорчу, серебряной пули нет придется использовать разные инструменты, но с опытом, вы поймёте, что различия весьма преувеличены.

Чем описывать тут своими словами лучше дать ссыль на хороший, годный доклад
https://habr.com/ru/company/oleg-bunin/blog/417461/

Макро и микрозадач нет, есть tasks и jobs (иногда таки называют микротасками). Tasks выполняются в цикле, по мере появления в коллстэке (это xhr, fetch, setTimeout, browser events), а jobs (Promise, Mutation observer) сразу после тасков в текущем цикле, причем если job был добавлен в этом цикле (в task или в job перед ним), то и выполнен он будет в этом же цикле, в отличие от таска. Это позволяет выполнить промис-цепочку почти синхронно, но добавляет опасность заблочить цикл.

В ноде все это работает по-другому.

Ну и евент луп не относится к javascript, а определяется окружением, в нашем случае - браузером.

К примеру вы отправили запрос в сеть чтобы получить фоточку, если использовался синхронный код, то поток бы заблокировался и приостановились все задачи и функции, пока фоточка идет из сети.

В случае асинхронного, планировщик не ждет пока придет ответ и передает управление следующей функции в месте где написано await. Когда придет ответ с фоточкой, планировщик снова передаст управление в то место где был написан await.

"Изолятом" в данном случае выступает функция обернутая во Future либо с указанием async.
— Код внутри изолированной функции будет выполнен последовательно.
— Функции обернутые во Future или определенные как async будут выполнены асинхронно, без ожидания выполнения других таких же асинхронных функций.
— Если вызвать sleep(300) в обычной функции, все уснет на 5 минут, ничего происходить не будет.
— Если вызвать await sleep(300) в асинхронной, то уснет только эта функция.
— await указывает планировщику что тут функция хочет подождать и он может передать управление любой другой.

Если бы наш мир был однопоточный и синхронный, то вы бы не проснулись утром, если бы я все еще продолжал писать это сообщение. Если бы наш мир был однопоточный и асинхронный, то планировщик отключал бы меня на какое-то время, при каждом упоминании await в этом ответе, чтобы другие люди могли заниматься своими делами.

Занимался системой коллективной лояльности полтора года.

Тут много неясного не с точки зрения программирования, а в первую очередь с юридической.

Во первых Вам нужно определиться с правовым статусом этих бонусов - это деньги или не деньги.
Если деньги - нужно реально открывать счет на клиента в банке или НКО, платить за клиента 13% ндфл, ну и все прелести 161-ФЗ.
Если не деньги - возникает вопрос обоснования финансовых переводов между юрлицами ну и накрывается идея выплат на карту.
Решения однозначного нет, каждая система лояльности идет по своему пути но в целом разработка схемы и юридического обоснования это месяцы.

С технической стороны - могу навскидку озвучить множество вариантов реализации, но отталкиваться нужно от потребностей партнеров:
Можно опубликовать свой шлюз наружу и надеяться что с ним будут интегрироваться.
Можно интегрироваться на уровне учетного ПО / сайта / crm партнеров подготовив модули под основные системы.
Можно делать пост-аналитику банковской выписки партнера.
Можно запустить отдельные интерфейсы на своей стороне с минимальной интеграцией.
В одних сферах бизнеса партнеров лучше работает одно, в других - другое.

PS
Судя по вопросу Вы только в начале этого пути.
Крайне советую до начала проекта:
а) Проработать юридическую часть.
b) Найти первых якорных партнеров. Заодно поймете как им удобней с Вами интегрироваться.
В целом советую по крайней мере на старте идти по пути максимально простой для партнера интеграции.
Простой с точки зрения бизнеса (!), а не разработчика.

Да прост открываете psr и читаете, там и примеры есть.
Кстати, автозагрузка классов не имеет никакого отношения к ооп.

в принципе, все основы описаны тут php.net/manual/ru/language.oop5.autoload.php

Вы б лучше описали что конкретно непонятно, тогда можно было б отвечать более предметно.