Да, меня этот подход тоже смущает. Где-то в комментариях к исходной статье им посоветовали не делать «горячую» замену кода прямо на production. Вместо этого им предложили убивать процесс node.js и делать полный редеплой, на что автор статьи написал, что к сожалению они пока не могут отказаться от этого legacy подхода.
Ничего не мешает. Но, автор оригинальной статьи хотел использовать хэш-таблицу как раз для того, чтобы не было возможности повесить несколько обработчиков на один маршрут. С одной стороны предложение здравое, а с другой оно бы решало только текущую проблему Netflix с багом в обновлении обработчиков, при этом время поиска осталось бы прежним.
Переписать весь Android это вряд ли, тем более что он написан не на Java. А вот приложения вы можете уже сейчас писать на C/C++ с помощью Android NDK. В Go 1.4 должна появиться поддержка Android NDK, так что можно будет начинать его потихоньку использовать.
Спасибо, это как раз то, что мне сейчас нужно. Постараюсь сам дальше поковыряться.
И еще хотелось бы задать пару вопросов, но уже про server-side, если можно.
Как вы организовали передачу данных между legacy слоем приложения (я так понимаю вы же не все переписали на JavaScript) и собственно node.js?
И какие вы посоветуете посмотреть \ почитать материалы по использованию node.js в highload проектах?
Спасибо, не знал о таком. У нас уже это сделано своими силами: каждый task выглядит как отдельный модуль содержащий в себе вызов функции grunt.loadNpmTask и возвращающий после выполнения объект с опциями. Таким образом нам остается только взять все файлы из папки и выполнить их, а результат отдать в функцию grunt.initConfig.
На самом деле, Андрей, спасибо вам за ваш проект, я думаю у него есть хорошие перспективы.
Мы всерьез рассматривали вариант его внедрения у нас, однако решили отказаться от этого, по причинам того что нам нужны были статичные файлы (все-таки генерация пакетов на лету на большом проекте, пусть и один раз, это не здорово) к тому же не понятно было как быть с continius integration, ловить синтаксические ошибки в runtime тоже не очень хотелось.
Нас тоже приятно радует скорость работы Grunt. В среднем (без скачивания модулей) на TeamCity она составляет 2-3 секунды при проверке кода синтаксическим анализатором и 10-12 секунд при построении deployament package.
Это так, если модуль grunt-cli, будет установлен глобально, то есть с помощью команды:
> npm install -g grunt-cli
В таком случае команда grunt будет добавлена в PATH, мы же в свою очередь устанавливаем все пакеты локально и поэтому используем для запуска этот .cmd файл.
Дело в том, что мы собираемся использовать в качестве CDN Windows Azure, который в свою очередь для этого использует BLOB-storage поэтому запустить какое-либо приложение не представляется возможным.
Да, меня этот подход тоже смущает. Где-то в комментариях к исходной статье им посоветовали не делать «горячую» замену кода прямо на production. Вместо этого им предложили убивать процесс node.js и делать полный редеплой, на что автор статьи написал, что к сожалению они пока не могут отказаться от этого legacy подхода.
И еще хотелось бы задать пару вопросов, но уже про server-side, если можно.
Как вы организовали передачу данных между legacy слоем приложения (я так понимаю вы же не все переписали на JavaScript) и собственно node.js?
И какие вы посоветуете посмотреть \ почитать материалы по использованию node.js в highload проектах?
grunt.loadNpmTaskи возвращающий после выполнения объект с опциями. Таким образом нам остается только взять все файлы из папки и выполнить их, а результат отдать в функциюgrunt.initConfig.Мы всерьез рассматривали вариант его внедрения у нас, однако решили отказаться от этого, по причинам того что нам нужны были статичные файлы (все-таки генерация пакетов на лету на большом проекте, пусть и один раз, это не здорово) к тому же не понятно было как быть с continius integration, ловить синтаксические ошибки в runtime тоже не очень хотелось.
grunt-cli, будет установлен глобально, то есть с помощью команды:В таком случае команда
gruntбудет добавлена вPATH, мы же в свою очередь устанавливаем все пакеты локально и поэтому используем для запуска этот.cmdфайл.