по фронту, если он пишется на веб технологиях, но должен поставляться как десктоп приложение - однозначно 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 недостаточно, нужен еще секретный ключ
даже если Вы посмотрите первый, без второго Вы не авторизуйтесь (и без пользователя кстати тоже)
Denis, код выполняется сверху вниз (за некоторыми исключениями, вроде объявления функций и переменных, о чем стоит почитать отдельно).
логично читать код в той последовательности, в которой он выполняется.
Чтение чужого (или своего) кода занимает примерно 80% времени разработчика непосредственно с кодом. На первых порах важно развить этот навык. Можно проговаривать, что происходит.
Например:
на первых 4 строках в памяти создается объект с тремя значениями, ссылка на этот объект сохраняется в переменной team
на 5 строке число 10 сохраняется в переменную player
на 6 - из объекта team извлекается значение под ключом player (10), результат ('Joe') запоминается в question
на 7 - вызов console.log (вывод в консоль) с передачей question ('Joe') в качестве аргумента, в консоль выведется Joe
