Да у меня серверный дистрибутив, насколько я понимаю для него рекомендуется использовать как раз networkd. Поэтому предпочту второй вариант, как более явный и надёжный.
У вас какое имя сетевого интерфейса, реально существующего в системе? enp1s0f0 или ens1? Вы добавляете в бридж enp1s0f0, но это точно правильно? Посмотрите командой ip a
Насколько понимаю enp1s0f0
# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: enp1s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether XXXXXX brd ff:ff:ff:ff:ff:ff
inet xxx.xxx.xxx.7/27 metric 100 brd 141.105.68.31 scope global dynamic enp1s0f0
valid_lft 847758sec preferred_lft 847758sec
inet6 XXXXXXXX/64 scope link
valid_lft forever preferred_lft forever
3: enp1s0f1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether XXXXXXXX brd ff:ff:ff:ff:ff:ff
4: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether XXXXXXXX brd ff:ff:ff:ff:ff:ff
inet6 XXXXXXXX/64 scope link
valid_lft forever preferred_lft forever
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether XXXXXXXX brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
SEOVirus, да, без году неделя. Вопрос требований к стабильности вашего предложения.
Я так понимаю, поддержка до сих пор сугубо экспериментальная, и вопрос что будет с обратной совместимостью открытый.
SEOVirus, с чего бы компилируемому решению с поддержкой многопоточности, не быть шустрее чем интерпретируемое, однопоточное?
Моя мысль основная в том, что для первой реализации стоит использовать то что лучше знаешь. Быстро запилил прототип, потестировал. Не взлетает: искать альтернативу.
А по ресурсам:
У C# лучше с типизацией, в то время как NodeJs умеет только в динамическую. По памяти C# должен быть экономнее.
C# - компилируется, NodeJs - интерпретируется виртуальной машиной (с оговорками). У первого варианта больше возможностей по оптимизации. NodeJs проектировался для выполнения в одном потоке. По CPU C# потенциально должен быть эффективнее.
PS: рассуждаю как сторонний наблюдатель, очки на стройке нашёл.
Дополню такой аналогией. Если знаете ООП, и первую букву из SOLID.
Образ - это класс.
Контейнер - объект.
Единая ответственность сервиса(контейнера/образа), такая же хорошая практика как и в ООП, и даёт те же преимущества: локализация изменений и проблем, лучшая декомпозиция задач и логики.
Pyatachok, да, спасибо.
Если у соискателя адекватный github / habr / stackoverflow / toster и в целом общение, то мы тестовое тоже не заставляем делать.
Но если есть сомнения, и нет публичных проектов-исходников, то тестовое -- лучший вариант понять, что не только на словах он Лев Толстой.
Про сертификаты спасибо, забыл что у битрикс есть такая тема.
С использованием классов внутри библиотеки, у меня проблем не возникает.
Затруднения в использовании кода через npm-пакет. Как правильно скомпилировать свой код, чтобы подключить его при помощи require - вот в чём вопрос.
Ну, конкретнее, насколько я понимаю, вы используете глобальный массив $_SESSION как хранилище для корзины пользователя. Пусть так. Хотя лучше абстрагироваться от сессии, введя специальный объект корзины. Задача, судя по имеющемуся коду - при добавлении товара, если такой уже был, увеличить его счётчик. Я предлагаю хранить объекты вместо примитивов.
Я для того и использую TypeScript, чтобы абстрагироваться от нативного js)
В актуальной версии есть поддержка namespace, синтаксически близкая к тому что мне хорошо знакомо по другим языкам, почему бы её не использовать, раз она позволяет использовать Foo.Builder и Bar.Builder не беспокоясь о коллизиях.
Дмитрий Байбухтин: да пробовал, знаю. Сейчас легаси проект на Yii1.
Да, в Yii многое завязано на магии и публичных свойствах, но это не очень хорошо влияет на объектно-ориентированный дизайн. Так что где возможно, стараюсь эту особенность не эксплуатировать: например вместо публичных свойств компонентов использовать приватные + сеттеры. Это улучшает интерфейс классов и в итоге влияет положительно на тестируемость.
Так-то фреймворк неплохой, особенно для быстрого прототипирования, когда database first подходит. Но если приложение большое, или доменная логика сложная, там уже Active Record начинает напрягать - не самый удачный шаблон проектирования, т.к. большая зона ответственности у классов. Хочется через DDD разрабатывать и иметь более абстрагированный от БД слой моделей - ORM, который бы позволял code first подход и соблюдение принципа persistance ignorance.
Дмитрий Байбухтин: Ну, я бы в этом случае сделал метод setServers(array $servers);
а вообще этот конкретный случай уже похоже тянет на интеграционное тестирование, не юнит, т.к. компонент взаимодействует со сторонней подсистемой.
Дмитрий Байбухтин: А можете ссылку на код дать, так мне будет проще понять ситуацию.
У нас как-то без конфигов компоненты.
Вообще я пришёл к тому что в виде юишного компонента реализую только фабрики для каждого сервиса, и именно она доступна через синглтон контейнера. А в юнитах, напрямую инстанцирую объект сервиса, либо, когда сервис должен быть специальным образом сконфигурирован, в тесте получаю его через фабрику.
Дмитрий Байбухтин: А что мешает инстанцировать объект компонента и тестить его методы, как обычно в юнитах?
В первом Yii так делаем. Прошлый проект был на двойке, уже плохо помню, но принципимальных отличий вроде бы нет - компонент это сервис, а Yii::app() - сервис локатор.
"Родной" не обязан. Но вполне себе может. Зависит от требований к фронтенду. Для современных js-фреймворков это более чем приемлемая архитектура взаимодействия с сервером. И если рестовый бэкэнд уже есть, то это возможное решение для фронтенда.
Но не если, кроме вебморды, других клиентов не предполагается, то такая архитектура не всегда может быть оптимальной. Иногда достаточно и более монолитной архитектуры, без клиент-серверного разделения, если речь именно о веб-сайте. Более традиционное решение тогда - любой серверный MVC фреймворк.
Есть ещё третий вариант: рестовое апи есть, было, и будет есть, но вебморда сервиса может быть построена без использованbя оного. Примеры: GitHub, BitBucket, Jira. Redmine (?).
Это клиентский код. А запущен ли сервер, который должен обслуживать сокет?
Почитайте (здесь например learn.javascript.ru/websockets) вводную информацию по ws.
Да у меня серверный дистрибутив, насколько я понимаю для него рекомендуется использовать как раз networkd. Поэтому предпочту второй вариант, как более явный и надёжный.
Насколько понимаю enp1s0f0