по п.1: насколько знаю Google Fonts как и прочие сервисы Google заблокированы в Китае
по п.2: если тексты будет наполнять переводчик, у него уже должна быть клавиатура с соответствующими символами
по п.3: отреагирует нормально, для него это такие же символы юникода, однако стоить проверить поддержку глифов используемым в нем шрифтом
по п.4: первое что приходит в голову - длина текста на Китайском будет заметно короче в большинстве случаев - соответственно будет много пространства пустовать
по фронту, если он пишется на веб технологиях, но должен поставляться как десктоп приложение - однозначно electron.js
по бэку, если он будет на Вашем сервере - пока сами не откроете код, его никто не увидит
и java и c# компилируются в байт код своих виртуальных машин, востановить исходник - не проблема, лучше посмотреть в сторону того, что компилится в нативный код проца - c++, go, rust
Петр, в обычном режиме ест 90-100 ват/ч, при вычислительной нагрузке может расти до 180 ват/ч
правда одно но... я мерял на розетке, и я сэкономил на БП при сборке, как итог - у меня лишнее потребление уходит в тепло...
но и однозначно, если нужен чисто роутер, лучше решения на arm архитектуре, у той же banana pi потребление не превышает 15-20 ват/ч
Антон Спирин, решение от Interface - в самом худшем варианте массив проходится 3 раза, при увеличении, на Вашем тесте у меня он самый медленный (гонял только в Chrome 66)
вариант Виталий Архипов пробегает массив 2 раза, у меня Ваш тест дал примерно одинаковые результаты между моим и его вариантом
Голый for по массиву предсказуемо работает быстрее всего
Откуда такие цифры то?
Интуитивно, по максимальному количеству итераций на длину массива n
Ваш тест показывает, что моя интуиция меня подвела... Очевидно дело во внутренней реализации reduce
Yustas Alexu, Каждому свое, добавлю так же, что у них несколько противоположные подходы к работе с данными:
React - это про иммутабельность данных, чистые функцие, прочие ФП приблуды, ООП добавляется только по вкусу как вспомогательный инструмент
Vue - наоборот мутабельность данных и реакция на изменения, ООП приблуды вроде событий, ФП - по настроению, как вспомогательный
Ну и еще момент, React мне не нравится за jsx... а писать производный код руками - то еще удовольствие
Vue же дает мне достаточно свобод в плане выбора технологий, например я могу в одном проекте писать на TypeScript те компоненты, которые будут переиспользоваться, и не тратить время на типы, для того что сделается один раз, для здесь и сейчас
Interface, помню, что собирал по статье с хабра, но к сожалению не добавил в закладки
поиск по хабру навел вот на такой вариант: https://habr.com/post/151661/
на мой взгляд весьма неплохо расписано
nezzard, можно
Вы можете как перенаправить стандартный ввод/вывод пользователю, так и управлять им программно. Почитайте документацию к модулю на сайте node.js
Однако, есть но:
1. мне бы, как пользователю Вашего приложения, непонравилось, что что-то делается втихаря, без моего ведома
2. на большинстве ОС на базе linux для установки ПО потребуются права суперпользователя
3. windows не очень то лояльна к CLI приложениям, скорее всего установщик отобразит GUI
4. npm может пометить такой пакет вредоносным
Сергей Соколов, а никто и не хранит секретный ключ на клиенте
1. клиент запрашивает авторизацию у авторизующей стороны
2. авторизующая сторона делает запрос на сервер и передает код автоматизации
3. сервер делает запрос на авторизующую сторону, передает секретный ключ и код, в замен получает токен
дальше сервер волен распоряжаться токеном как угодно, может передать на клиент, а может делать запросы к апи сам
Сергей Соколов, одного app id недостаточно, нужен еще секретный ключ
даже если Вы посмотрите первый, без второго Вы не авторизуйтесь (и без пользователя кстати тоже)
по п.2: если тексты будет наполнять переводчик, у него уже должна быть клавиатура с соответствующими символами
по п.3: отреагирует нормально, для него это такие же символы юникода, однако стоить проверить поддержку глифов используемым в нем шрифтом
по п.4: первое что приходит в голову - длина текста на Китайском будет заметно короче в большинстве случаев - соответственно будет много пространства пустовать