Значит им настоящая безопасность по большому счёту не нужна. Те, кому безопасность действительно нужна, как минимум читают документацию. Много документации)
Ваше решение под капотом использует куки. Авторизоваться через куки можно и без использования basic-авторизации. Здесь речь о ситуациях, когда ни куки, ни oauth, ни что-то ещё подобное не доступно.
Тут вопрос то не в том, где правильнее логаут делать: на клиенте или сервере. Логаут — это прежде всего серверное действие. Но клиент его тоже должен отрабатывать правильно
В нашем случае мы работаем со сторонним бэкендом, графаной. В этом случае возможности чисто серверной реализации сильно ограничены
Я установил пакет mail-notification. Дока утверждает, что должны были появиться нотификации в правом верхнем углу. У меня не появились. mail-notification я удалил, и тогда у меня появились "красные кружочки" в панели задач на иконке Thunderbird) После перезагрузки "кружочки" всё равно продолжали работать)
TopIcons у меня устанавливаться не захотел. Жмёшь "установить" и… ничего не происходит. Потом необходимость отпала, "красные кружочки")))
Спасибо за информацию, взял на заметку. Брал ноду 8 только потому, что она LTS. Скорее всего 10-ка тоже вот-вот перейдёт в LTS статус, не вижу причин не перейти на неё.
По поводу утечек памяти скажу, что при наших объёмах (террабайты в сутки) утечки обязательно проявили бы себя. Значит либо в 8-й ноде утечки пофиксили, либо вы делаете что-то очень специфическое
Отчасти Вы правы, отчасти нет. Несомненно хорошо бы стараться поддерживать приложение в актуальном состоянии. Но если приложение работает и справляется с возложенными на него обязанностями, зачем его трогать? Можно бесконечно рефакторить старый код. Вопрос: кто будет разрабатывать новый функционал? Иногда проще дать приложению выработать себя по максимуму и потом переписать с нуля.
Опять же, всё зависит от Ваших конкретных текущих задач и ресурсов. Универсальной формулы нет.
Задача сложнее, чем просто парсинг логов. Например, подшивка к логу юзера, обработку различных хуков и построение реалтаймовых агрегаций. И нода вполне с задачей справляется. Но вы совершенно правы, что расход в 5ГБ оперативы — это не нормально. Обычный рабочий расход памяти у данного компонента — менее одного гига. Перерасход происходит только в определённых исключительных ситуациях. И дело здесь не в языке, а в архитектурной недоработке. Мы знаем об этой недоработке, но более простым решением оказалось установить параметр --max-old-space-size в более высокое значение.
Да, Вы совершенно правы. Делать что-то только ради эстетики и развития кругозора можно тогда, когда для этого есть время. А если приходится выбирать между первоочередными задачами и желательными "хотелками", "хотелки" как правило откладываются в долгий ящик. Для сдвига бизнес-планов нужны веские основания. Плюс любая существенная переработка как правило предполагает баги и большие риски, что для работающего процесса может быть критично
Искал. Но информации, достаточной для принятия решения не нашёл. Впрочем, это критерий слишком субъективный. Окончательное решение о переходе было скорее интуитивным, чем основывалось на реальных фактах. Плюс желание иметь нормальные возможности отладки, которые появились в ноде только с версии 0.12
Проект состоит из нескольких модулей, практически все из которых уже были практически готовы к такому переходу, кроме одного центрального, объёмом более 10к строк кода. В результате суммарно на переработку всего проекта ушло около полутора недель и ещё примерно неделя на обкатку и тестирование перед заливкой на продакшн
Синтаксис fork() почти аналогичен синтаксису метода spawn(), за одним исключением: здесь не нужна команда, потому что fork() предполагает, что все процессы относятся к Node.js:
var fs = require('fs')
var process = require('child_process')
var p = process.fork('program.js')
p.stdout.on('data', function(data)) {
console.log('stdout: ' + data)
})
У потомка stdout и stderr равны null, и код выдаст ошибку:
Убунту основано на тестируемой, то есть следующей версии дебиана. Как я говорил, в ней php5-readline вернули. Данный способ же относится к текущей стабильной.
Значит им настоящая безопасность по большому счёту не нужна. Те, кому безопасность действительно нужна, как минимум читают документацию. Много документации)
Ваше решение под капотом использует куки. Авторизоваться через куки можно и без использования basic-авторизации. Здесь речь о ситуациях, когда ни куки, ни oauth, ни что-то ещё подобное не доступно.
В чистом виде её обычно никто и не использует
Тут вопрос то не в том, где правильнее логаут делать: на клиенте или сервере. Логаут — это прежде всего серверное действие. Но клиент его тоже должен отрабатывать правильно
В нашем случае мы работаем со сторонним бэкендом, графаной. В этом случае возможности чисто серверной реализации сильно ограничены
У меня сильно тормозила только убунта 14. Что к 16 на юнити, что к тем более 18 на гноме претензий по скорости вообще нет
Я установил пакет mail-notification. Дока утверждает, что должны были появиться нотификации в правом верхнем углу. У меня не появились. mail-notification я удалил, и тогда у меня появились "красные кружочки" в панели задач на иконке Thunderbird) После перезагрузки "кружочки" всё равно продолжали работать)
TopIcons у меня устанавливаться не захотел. Жмёшь "установить" и… ничего не происходит. Потом необходимость отпала, "красные кружочки")))
Спасибо за информацию, взял на заметку. Брал ноду 8 только потому, что она LTS. Скорее всего 10-ка тоже вот-вот перейдёт в LTS статус, не вижу причин не перейти на неё.
По поводу утечек памяти скажу, что при наших объёмах (террабайты в сутки) утечки обязательно проявили бы себя. Значит либо в 8-й ноде утечки пофиксили, либо вы делаете что-то очень специфическое
Отчасти Вы правы, отчасти нет. Несомненно хорошо бы стараться поддерживать приложение в актуальном состоянии. Но если приложение работает и справляется с возложенными на него обязанностями, зачем его трогать? Можно бесконечно рефакторить старый код. Вопрос: кто будет разрабатывать новый функционал? Иногда проще дать приложению выработать себя по максимуму и потом переписать с нуля.
Опять же, всё зависит от Ваших конкретных текущих задач и ресурсов. Универсальной формулы нет.
Задача сложнее, чем просто парсинг логов. Например, подшивка к логу юзера, обработку различных хуков и построение реалтаймовых агрегаций. И нода вполне с задачей справляется. Но вы совершенно правы, что расход в 5ГБ оперативы — это не нормально. Обычный рабочий расход памяти у данного компонента — менее одного гига. Перерасход происходит только в определённых исключительных ситуациях. И дело здесь не в языке, а в архитектурной недоработке. Мы знаем об этой недоработке, но более простым решением оказалось установить параметр --max-old-space-size в более высокое значение.
Да, Вы совершенно правы. Делать что-то только ради эстетики и развития кругозора можно тогда, когда для этого есть время. А если приходится выбирать между первоочередными задачами и желательными "хотелками", "хотелки" как правило откладываются в долгий ящик. Для сдвига бизнес-планов нужны веские основания. Плюс любая существенная переработка как правило предполагает баги и большие риски, что для работающего процесса может быть критично
Искал. Но информации, достаточной для принятия решения не нашёл. Впрочем, это критерий слишком субъективный. Окончательное решение о переходе было скорее интуитивным, чем основывалось на реальных фактах. Плюс желание иметь нормальные возможности отладки, которые появились в ноде только с версии 0.12
Проект состоит из нескольких модулей, практически все из которых уже были практически готовы к такому переходу, кроме одного центрального, объёмом более 10к строк кода. В результате суммарно на переработку всего проекта ушло около полутора недель и ещё примерно неделя на обкатку и тестирование перед заливкой на продакшн
Ну это же не художественный роман) Цель статьи — дать какую-то обратную связь тем людям, которые ещё стоят перед выбором и сомневаются
Вот после этого в коде примера ошибка:
У потомка stdout и stderr равны null, и код выдаст ошибку:
TypeError: Cannot read property 'on' of null