рендеринг и прочая херня типа гидротации - это переливаниие из пустого в порожнее. зачем стрjить что-то (типа json), это ведь в чистом виде строка. а потом из строки строить новую строку под названием HTML? ведь можно сразу построить HTML-строку и отдать её клиенту. к примеру серверу на java - "примитивные" jsp-страницы, всё находится в памяти, обращения к диску в основном это обращение к базе (если есть необходимость) так можно сразу строить вычисляемые элементы dom (таблицы, как вариант). исключается куча лишних действий. если разработчику не хватает мозгов по построению строки HTML, то это проблема руководства этого разработчика, нанявшего такого "знатока". ssr "медленный", конечно, если рассматривать его как преобразование из одной строки в другую. надо построить одну строку, потом её распарсить, преобразовать и построить уже отдаваемую в виде html..... "каждому клиенту надо отрисовку делать на сервере. Нагрузка на сервер.".... ага , а построить для каждого клиента json не нужно? у меня веб-приложения, страницы которых полностью строятся на сервере без рендеринга, и данные выводимые по запросам с этих страниц (таблицы и прочее) также строятся на сервере в виде html, и работает быстро. и на сервер нет нагрузки. "жухаться" не будет. проверено многократно, что построить json, что построить html для него однорангово
@fransua @Suvitruf данной проблемы нет, это ж websocket! одновременно редактировать одну ячейку не возможно т.к. невозможно одновременно зайти в одну ячейку, хотя бы потому что протокол последовательный и данные придут от одного клиента раньше. как ни крути. ну а раз пришли данные на занятость ячейки - сервер остальным просто разошлёт команды и данная ячейка у остальных должна "заблокироваться" для изменения..
как раз я правильно понял, да на сервере создается строка html, но она создается в два приема, сначала строится нечто вроде json, а потом "эмуляцией" браузера формируется html. но это двойная работа сервера. как вариант - html строку таблицы практически любой сложности можно сформировать в sql запросе и это не будет большой нагрузкой на sql-сервер (проверено). повторно, по навешиванию обработчиков. - сколько их? к примеру на таблицу любых размеров достаточно 2-х обработчиков - клик и дблклик, для доступа к любой ячейки. это такого добавления никаких тормозов не будет. сколько ещё ? ну 10-15 на остальные элементы, но и это не тормоз. а если использовать template - то и больше обрабатываемых элементов можно использовать без торможения страницы. следовательно - (если читать вики: Гидрата́ция (от др.-греч. ὕδωρ «вода») — присоединение молекулводы ) эти действия и есть присоединение воды, а точнее переливание из пустого в порожнее.
ssr - это преобразование чего-то, в html. а зачем это "чего-то" ? почему нельзя сразу в html? >>Но на полученный HTML надо навесить обработчики - это ж сколько обработчиков надо навешать? вообще то обработчики располагаются в конце страницы и вступают в действие когда вся страница уже отрендерена браузером. >> оживить реактовые компоненты. это ж надо городить ещё такое, что б ещё и оживлять.
почему нельзя сформировать полностью готовую страницу на сервере? а уж если что-то юзер вводит обрабатывать. а то получается передаем заготовку, передаем данные, и загружаем их в заготовку. причем не используем innerHTML. какая разница серверу формировать сразу строку html, и ещё json, передавать клиенту, а там парсить json, заполнять объекты? для браузера проще и быстрее обработать одну строку html. не делать т.н. серверный рендеринг, тратя время на формирование json, а потом преобразовывать в html, а сразу строить конечный html, уж если гонимся за милисекундами , то надо во всей системе, а не кровати двигать
хабр стал похож на отчетную страницу первого класса, огромное достижение - модальное окно.... ну ж если и выкладывать - то уж хотя бы c с использованием template, Shadow DOM, grid, ну и возможностью перемещения этого окна по экрану.
и за что плюсанули в карму? за приглашение от НЛО?
было б интересно почитать как развернуть из исходников, например это интересно для малинки, потому как выложенное готовое не последней версии для подобного железа. в инете насобирал по крохам, развернул, работает, но не факт, что оптимально.
Если интернет соединение было на какое-то время потеряно - так же будут потеряны сообщения, которые были отправлены в это время, нельзя их "подцепить".
не верно. брал модуль w5500, отправлял через него короткие данные, отображаемые в реальном времени в браузере, вынимал , во время передачи, коннектор из w5500 секунд на 10-15, и втыкал снова, никаких потерь не происходило, в w5500 есть буфер, в котором и накапливались эти данные. если посмотреть через wireshark, то можно заметить , что передача по ws идет с квитирование. как по мне, то использование в лоб json и ему подобных убивает достоинство ws, если разделить передаваемую инфу по ws на части : "команда", "разделитель", "данные", то можно более полно использовать возможности js для ws, а именно "рефлексию", типа xxx24®ddddddddd , где dddddd может быть и json и строка html тогда
con.onmessage = function (response) {
if (typeof (response.data) === 'string')
{
var rg = /^([a-z_0-9.]{1,})\|([\s\S]*)/i;
var r = rg.exec(response.data);
try {
if (r[1].includes('.'))
{
var d = r[1].split('.');
window[d[0]][d[1]](r[2]);
} else
{
window[r[1]](r[2]);
}
} catch (er) {
console.log('ошибка ' + er.stack);
console.log('вызов ' + r[1]);
console.trace();
}
}
что позволяет вызвать любую функцию или метод из класса. с передачей туда данных. вариант рабочий, проверенный. работает также и для шаблонов
--- Поскольку сервер веб-сокетов - это отдельное от основного бэкенда приложение, он ничего не знает о существующей базе данных.
одно это говорито том, что предстоит пройти велосипедостроение. php - обработчик запросом от клиента, но не ws . оно конечно похвально, что php стремится расширить своё применение, но увы .... это не серверные приложения, и всю прелесть ws просто теряют....
---PHP все еще может быть не первым вариантом для работы с веб-сокетами
теория - просто, даже при использовании цифры, сложности начинаются когда надо определить коэффициенты. хорошо если есть "единичное воздействие" , а если оно такое, что при его достижении система горит синим пламенем?
и правильно сделал, один раз а год закрктить, но зато с каким кайфом, и зависьью к самому себе, что у тебя есть такое, а еслиб жаба победила, скока мучениц было бы
мониторинг пульса лучше производить из показаний измерений фотоплетизмограммы , точнее из множества измерений из которых и строится Фотоплетизмограмма. будет намного больше информации для размышления о здоровье сосудов и сердца.
давление на запястье чисто теоретически измерить можно, но практически нужно выполнить кучу условий, измерял, проверял. НО! в реальной жизни - это не реально. а вот с пульсом - это отдельная тема, это https://ru.wikipedia.org/wiki/Фотоплетизмограмма . и вот тут ОГРОМНАЯ проблема с нашими врачами, из 5 посещённых кардиологов, сопровождающих послеинфартников, только один смог сказать что такое Фотоплетизмограмма.
а на самом деле эти "датчики" дают очень интересную информацию, показывают прямую и отражённую волны кровотока. НО!!! эти врачи не могут толком объяснить что и почему так ... сваливают всё на то, что это китайские безделушки. доверяют измерение пульса тонометру, пальцам, и не понимают, что эти "приборы" режут высокие частоты "пульса кровотока". показывают завышенный пульс, хотя на самом деле сам "электрический" пульс может быть нормальным, а повышенным он измеряется когда обратная, отраженная волна кровотока становится близка по амплитуде к прямой волне..... это проявляется при даже небольшой нагрузке.
ждал разбора алгоритмов управления и стабилизации, а тут «двигатель крутится, таходатчик измеряет, тиристор открывается, счётчик считает, микроконтроллер управляет»
а тут и описан алгоритм управления -ПИД, больше нечего рассказывать, и как управляется мотор, даже очень, очень подробно, в 90-х делал подобным образом на 51 контроллере терморегулятор - точность поддержания температуры 36.6градуса ±0.02 градуса, так что для данной точности и стабильность оборотов - выше крыши. а двигатели - аналогичные по типу стоят в дрелях.
по нынешним временам - это не критерий, а на практике - работал с ним а на 4 гигах, и на 8 гигах. проблем не испытывал. при 8-32 гигах настраивал на потребление памяти 1-2 гига , чтоб комфортнее было. Сопрягается с хромом для отладки. (работа на Java)
был реальный случай этак в середине 80-х…
были проверки по приходу на работу, и в одну из таких проверок один чел так и написал в объяснительной — опоздал на 5 минут, а на написание объяснительной 20, что вызвало задержку начала работы вместо 5 минут 25… Ох и шуму было…
карма убивает желание тут писать, спорить, высказывать мнение отличное от других. а контрольный выстрел кармы - ограничение на возможность что-то вообще писать, отвечать.
в голосовании нет пункта - заткнуть рот не согласному с мнением толпы
а график голосования за карму просто показывает, что возможность голосовать, писать остается всё у более у меньшего количества людей, не говоря уже о желающих это делать
рендеринг и прочая херня типа гидротации - это переливаниие из пустого в порожнее. зачем стрjить что-то (типа json), это ведь в чистом виде строка. а потом из строки строить новую строку под названием HTML? ведь можно сразу построить HTML-строку и отдать её клиенту. к примеру серверу на java - "примитивные" jsp-страницы, всё находится в памяти, обращения к диску в основном это обращение к базе (если есть необходимость) так можно сразу строить вычисляемые элементы dom (таблицы, как вариант). исключается куча лишних действий.
если разработчику не хватает мозгов по построению строки HTML, то это проблема руководства этого разработчика, нанявшего такого "знатока".
ssr "медленный", конечно, если рассматривать его как преобразование из одной строки в другую. надо построить одну строку, потом её распарсить, преобразовать и построить уже отдаваемую в виде html.....
"каждому клиенту надо отрисовку делать на сервере. Нагрузка на сервер.".... ага , а построить для каждого клиента json не нужно?
у меня веб-приложения, страницы которых полностью строятся на сервере без рендеринга, и данные выводимые по запросам с этих страниц (таблицы и прочее) также строятся на сервере в виде html, и работает быстро. и на сервер нет нагрузки.
"жухаться" не будет. проверено многократно, что построить json, что построить html для него однорангово
@fransua @Suvitruf
данной проблемы нет, это ж websocket! одновременно редактировать одну ячейку не возможно т.к. невозможно одновременно зайти в одну ячейку, хотя бы потому что протокол последовательный и данные придут от одного клиента раньше. как ни крути. ну а раз пришли данные на занятость ячейки - сервер остальным просто разошлёт команды и данная ячейка у остальных должна "заблокироваться" для изменения..
как раз я правильно понял, да на сервере создается строка html, но она создается в два приема, сначала строится нечто вроде json, а потом "эмуляцией" браузера формируется html. но это двойная работа сервера. как вариант - html строку таблицы практически любой сложности можно сформировать в sql запросе и это не будет большой нагрузкой на sql-сервер (проверено).
повторно, по навешиванию обработчиков. - сколько их? к примеру на таблицу любых размеров достаточно 2-х обработчиков - клик и дблклик, для доступа к любой ячейки. это такого добавления никаких тормозов не будет. сколько ещё ? ну 10-15 на остальные элементы, но и это не тормоз.
а если использовать template - то и больше обрабатываемых элементов можно использовать без торможения страницы.
следовательно - (если читать вики: Гидрата́ция (от др.-греч. ὕδωρ «вода») — присоединение молекул воды ) эти действия и есть присоединение воды, а точнее переливание из пустого в порожнее.
ssr - это преобразование чего-то, в html. а зачем это "чего-то" ? почему нельзя сразу в html?
>>Но на полученный HTML надо навесить обработчики - это ж сколько обработчиков надо навешать?
вообще то обработчики располагаются в конце страницы и вступают в действие когда вся страница уже отрендерена браузером.
>> оживить реактовые компоненты. это ж надо городить ещё такое, что б ещё и оживлять.
почему нельзя сформировать полностью готовую страницу на сервере? а уж если что-то юзер вводит обрабатывать. а то получается передаем заготовку, передаем данные, и загружаем их в заготовку. причем не используем innerHTML. какая разница серверу формировать сразу строку html, и ещё json, передавать клиенту, а там парсить json, заполнять объекты? для браузера проще и быстрее обработать одну строку html. не делать т.н. серверный рендеринг, тратя время на формирование json, а потом преобразовывать в html, а сразу строить конечный html, уж если гонимся за милисекундами , то надо во всей системе, а не кровати двигать
хабр стал похож на отчетную страницу первого класса, огромное достижение - модальное окно....
ну ж если и выкладывать - то уж хотя бы c с использованием template, Shadow DOM, grid, ну и возможностью перемещения этого окна по экрану.
и за что плюсанули в карму? за приглашение от НЛО?
было б интересно почитать как развернуть из исходников, например это интересно для малинки, потому как выложенное готовое не последней версии для подобного железа. в инете насобирал по крохам, развернул, работает, но не факт, что оптимально.
не верно. брал модуль w5500, отправлял через него короткие данные, отображаемые в реальном времени в браузере, вынимал , во время передачи, коннектор из w5500 секунд на 10-15, и втыкал снова, никаких потерь не происходило, в w5500 есть буфер, в котором и накапливались эти данные.
если посмотреть через wireshark, то можно заметить , что передача по ws идет с квитирование.
как по мне, то использование в лоб json и ему подобных убивает достоинство ws, если разделить передаваемую инфу по ws на части : "команда", "разделитель", "данные", то можно более полно использовать возможности js для ws, а именно "рефлексию",
типа xxx24®ddddddddd , где dddddd может быть и json и строка html
тогда
что позволяет вызвать любую функцию или метод из класса. с передачей туда данных.
вариант рабочий, проверенный. работает также и для шаблонов
--- Поскольку сервер веб-сокетов - это отдельное от основного бэкенда приложение, он ничего не знает о существующей базе данных.
одно это говорито том, что предстоит пройти велосипедостроение. php - обработчик запросом от клиента, но не ws . оно конечно похвально, что php стремится расширить своё применение, но увы .... это не серверные приложения, и всю прелесть ws просто теряют....
---PHP все еще может быть не первым вариантом для работы с веб-сокетами
это хорошо, что автор признался...
странно, что автор не упомянул про websocket, которые позволяют сократить трафик (уж если даже упомянул про экономию батарей)
телеграм так же открывается. и ничего, не дыра.
теория - просто, даже при использовании цифры, сложности начинаются когда надо определить коэффициенты. хорошо если есть "единичное воздействие" , а если оно такое, что при его достижении система горит синим пламенем?
и правильно сделал, один раз а год закрктить, но зато с каким кайфом, и зависьью к самому себе, что у тебя есть такое, а еслиб жаба победила, скока мучениц было бы
мониторинг пульса лучше производить из показаний измерений фотоплетизмограммы , точнее из множества измерений из которых и строится Фотоплетизмограмма. будет намного больше информации для размышления о здоровье сосудов и сердца.
давление на запястье чисто теоретически измерить можно, но практически нужно выполнить кучу условий, измерял, проверял. НО! в реальной жизни - это не реально. а вот с пульсом - это отдельная тема, это https://ru.wikipedia.org/wiki/Фотоплетизмограмма . и вот тут ОГРОМНАЯ проблема с нашими врачами, из 5 посещённых кардиологов, сопровождающих послеинфартников, только один смог сказать что такое Фотоплетизмограмма.
а на самом деле эти "датчики" дают очень интересную информацию, показывают прямую и отражённую волны кровотока. НО!!! эти врачи не могут толком объяснить что и почему так ... сваливают всё на то, что это китайские безделушки. доверяют измерение пульса тонометру, пальцам, и не понимают, что эти "приборы" режут высокие частоты "пульса кровотока". показывают завышенный пульс, хотя на самом деле сам "электрический" пульс может быть нормальным, а повышенным он измеряется когда обратная, отраженная волна кровотока становится близка по амплитуде к прямой волне..... это проявляется при даже небольшой нагрузке.
а тут и описан алгоритм управления -ПИД, больше нечего рассказывать, и как управляется мотор, даже очень, очень подробно, в 90-х делал подобным образом на 51 контроллере терморегулятор - точность поддержания температуры 36.6градуса ±0.02 градуса, так что для данной точности и стабильность оборотов - выше крыши.
а двигатели - аналогичные по типу стоят в дрелях.
NetBeans
большое потребление памяти.
по нынешним временам - это не критерий, а на практике - работал с ним а на 4 гигах, и на 8 гигах. проблем не испытывал. при 8-32 гигах настраивал на потребление памяти 1-2 гига , чтоб комфортнее было. Сопрягается с хромом для отладки. (работа на Java)
были проверки по приходу на работу, и в одну из таких проверок один чел так и написал в объяснительной — опоздал на 5 минут, а на написание объяснительной 20, что вызвало задержку начала работы вместо 5 минут 25… Ох и шуму было…
карма убивает желание тут писать, спорить, высказывать мнение отличное от других. а контрольный выстрел кармы - ограничение на возможность что-то вообще писать, отвечать.
в голосовании нет пункта - заткнуть рот не согласному с мнением толпы
а график голосования за карму просто показывает, что возможность голосовать, писать остается всё у более у меньшего количества людей, не говоря уже о желающих это делать
когда нечем возразить, начинают минусовать карму. это по научному, по джентельменски. вот так хабр роет себе могилу.