Pull to refresh
235
0
Timur Shemsedinov @MarcusAurelius

Chief Technology Architect at Metarhia

Send message
В варианте #D есть логика и на клиенте и на сервере, он от варианта #B отличается только одноранговым взаимодействием клиентов и дополнительной функцией сервера — быть брокером в одноранговом взаимодействии.

Вообще, конечно, для ERP лучше разделить логику, что и предложено в «Hybrid Application». С разной пропорцией можно выделить:
— Логику модели (она запускается и на клиенте и на сервере, там, где работает модель)
— Логику бизнес-процессов (которую для ERP удобнее реализовывать на сервере)
— Логику интерфейса (которая запускается только на клиенте и абстрагирована от прочей логики)
И эти три вещи не можно так построить, что они не будут пересекаться и «знать» друг о друге.
Конечно же проектирование БД, Olga_ol, это же не курс о том, как написать PostgreSQL. В видео БД написано, нужно заголовки править и в ютюбчике тоже.
HANA это очень хороший пример архитектуры, комплексный, состоящий из сервера приложений, СУБД, веб-сервера. Но я не специалист в SAP и глубоко не расскажу, а что точно понятно, что все компоненты там работают отдельно, как разные службы, без встраивания, о котором я пишу в статье, и такое решение застряло в середине нулевых годов, хотя, на то время было очень передовым. Разные процессы требуют постоянного межпроцессового взаимодействия, а это не только существенная потеря ресурсов, но и ограничения, например, сервер приложений должен дублировать в модель предметной области в памяти, а вообще она в БД хранится, так зачем же дублировать и синхронизировать. Все идет к интеграции.
Про QNX непонятно, поясните, к чему она тут?
Это плохо: const Car = { ... };
Это хорошо: const car = { ... };
Объекты называем в lowerCamelCase, а классы и конструкторы прототипов в UpperCamelCase.
По такой логике можно было бы добавить хабы: Разработка веб-сайтов, HTML, jQuery. Те, кто хочет читать статьи по JavaScript, тот подписывается на JavaScript. А если человек подписан на Node.js, но не подписан на JavaScript, то он не хочет видеть эти статьи.

Вот лучше добавить: Совершенный код, Проектирование и рефакторинг.
И уберите со всех статей теги: ReactJS, AngularJS. Ни одна из них ни каким боком к ним не отностися. Вас же минусуют за них.

Можно оставить тег Node.JS только для этой статьи, а на других тоже уберите, это все про чистый JavaScript и только про JavaScript.
Отступы, длинные строчки, описательные пременные. Лучше взять примеры тут, я поправил: tshemsedinov/clean-code-javascript/tree/max-line-length-80
Райан уже оправдывается за свои примеры на гитхабе ryanmcdermott/clean-code-javascript. Но вообще, делать require в функциях, в колбеках от ввода/вывода, и на промисах — это не то, чтобы не чистый код, это лютый ужас. А новички, которым эта книга предназначена, такого почитают и потом мы встречаем require внутри циклов или внутри Array.map()
Вызывайте функцию age() через runInNewContext и будут ограничивать.
Так в отдельном процессе на другом языке и по JSTP с ноды высылать запрос или адон на Си сделать, но в js не самая лучшая математика для алгоритмов.
Считать пи на ноде, серьезно?
Таймауты нужно ставить на: парсинг, исполнение кода и вызовый функций, которые из этого кода экспортируются, но все это скрыто от разработчика, делается рантаймом.
Как из анекдота «чем такого лечить, проще нового сделать». Добавить не очень сложно, но они очень долго не будет поддерживаться всеми, а значит, на нее нельзя будет рассчитывать. Да и ID это только одна проблема, нужно еще объединять мелкие пакеты в один и бить большие пакеты на части, потому, что один большой ответ может забить собой соединение на долго, не пропуская маленькие ответы. Еще нужно возможность отменять долгие запросы, да вообще слишком много чего нужно.
У нас: несколько сишников, несколько питонистов, несколько свифтовцев, несколько джавистов, несколько обджективсишников, по одному го и хаскелевцев.
Сравните диаграммы
Так протокол остается блокирующим, проблема называется «head-of-line blocking», это для API совершенно не применимо, это для загрузки статики ускорит. А если через соединение отправить запрос, то до его возврата новый не отправить все равно. Pipelining позволяет отправить пачку запросов разом и так же разом ожидать на них ответ. По сути это отправка одного запроса, склеенного и получение на него одного большого ответа. Как только запрос или пачка отправлены, то соединение заблокировано до получения последнего из них. Смысл API в том, чтобы посылать запросы тогда, когда это нужно, в произвольное время.
Тсс… пусть сам делает лабу, а не паленую сдает, я его уже почти обучил.
Так че, заработало?
Это таймаут на парсинг, а теперь на исполнение скрипта
let exported = js.runInNewContext(sandbox, { timeout: 1000 });

Доки читайте.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity