Асинхронность Node.js — это его идеология и даёт ему уникальные преимущества по сравнению с синхронными платформами.
К Node.js нужно привыкнуть, иначе, как вы и сказали, это может превратиться в callback hell.
Всякие promises и fibers — это попытки сделать так, чтобы ваш код выглядел синхронно. И испольуются в основном теми, кто мыслит в категориях синхронных платформ.
В умелых руках node.js код красив и прозрачен.
Скучность — это довольно субъективное понятие. В том видео, на которое я вам дал ссылку, один пожилой человек с огромным опытом в IT утверждает, например, что JavaScript — это очень веселый язык, просто недооцененный.
Спасибо, что разобрался. Это будет полезно многим.
Ну вот, как я и предполагал, использование в одном приложении разных версий пакетов — особенность JS.
Правильно говорят, что это всего лишь дело привычки. Со временем ты перестанешь переживать на этот счет.
Я думаю если ты только начинаешь разбираться, то посмотреть на голый node.js проект полезно. И посмотреть их доки.
Так же нужно понимать концепцию middleware connect.js.
Посмотреть на голый express.js проект.
На голом node.js можно писать, но он довольно низкоуровневый и тебе прийдется изобретать кучу вещей за ново (велосипедить). Для большинства проектов этого делать не надо, так как уже всё придумано до нас. Но в некоторых случаях, если это так нужно, то node.js позволяет опустить на уровень ниже.
Обычно node.js оборачивают в connect.js, его в свою очередь в express.js. Derby.js — это обвертка над express.js.
Каждый новый уровень добавляет возможностей, хотя немножко сложнее в понимании, чем предыдущий.
У людей, которые мало знают JavaScript, есть много мифов относительно него.
Я вам рекомендую посмотреть это.
Люблю JavaScript. Сам пишу на CoffeeScript`е. От него чуть больше удовольствия.
Традиционные способы работы с ООП — это дело привычки. Ничем не лучше, чем, например, прототипная модель.
Это не то чтобы для извращенцев. Если так, то почти все node.js программисты — извращенцы в какой-то степени :-)
В каждом более менее большом проекте очень сложное дерево зависимостей. Это возможно связано с node.js и javascript, Мне трудно сравнивать с Ruby, я на нем почти не программировал, а разбираться сейчас уже не вижу смысла. В общем пакет A может иметь зависимостью пакеты B и С, а пакет B тоже зависим от пакета C. Это могут быть разные версии C. Если одна и та же версия, то он установится один раз в пакет A, а если разные то 2 раза (в A и B), Я думаю теоритически можно найти и другие способы разрешения таких ситуаци — какое-нибудь глобальное хранилище пакетов с возможностью сосуществования разных версий или еще как-то. Разные решения наверно имеют разные плюсы и минусы. Но в npm решили сделать так. Спроси у него почему. Что я тебе точно могу сказать это то, что npm очень молод и создавался с оглядкой и по опыту других пакетных менеджеров.
Эх. Тебе же рекомендовали все пакеты устанавливать локально для каждого приложения. :-) Как в воду глядели.
Ты пошел своим путем. :-) Зато разобрался с npm и я тоже вместе с тобой :-) sudo npm install -g — эта штука не устанавливает все зависимости глобально. Их нужно устанавливать по очереди.
У npm такая идеология. Это позволяет использовать разные версии пакетов для разных приложений и в пределах одного приложения.
Если не будешь увлекаться созданием приложений, то в реальности это не так много места.
Я же сказал, что в основном не хранят в репозитарии. Но бывают исключения. Я, например, не храню.
Как сделать derby new так, чтобы использовался единый локальный репозиторий в системе?
Ты имеешь ввиду единый глобальный репозитарий? Попробуй derby new -n. Это создаст проект без установки зависимостей.
Какой командой установить зависимости при деплое этого проекта на сервер?
npm installТут доки
Если просто версии обновить, то: npm updateТут доки
Что за проблемы с Redis под Windows? Здесь уже чего-то обсуждали про это.
node_modules — это место храниение npm пакетов. То есть всех зависимостей твоего приложения.
Ты можешь установить все свои зависимости глобально, по примеру npm install -g derby, тогда они будут лежать в общей папке (в разных ос в разных местах) и использоваться всеми приложениями. Но тут рекомендуют так делать только для пакетов, которые используются в shell (как derby утилита, например). Остальные пакеты обычно устанавливаются локально (в node_modules твоего приложения).
Обычно node_modules добавляют в .gitignore, Но если ты деплоишь из git, то возможно лучше чекинить.
Самописные модули ты выкладываешь на github и в package.json прописываешь git-путь.
Да, Saas — это определенно будущее для всех приложений.
Но банкиры скажут «слишком большие риски». Попробуй им объяснить.
Технологии уже созрели. Теперь надо подождать пока в головах поменяется.
По проводам передаются даже не данные, а операции OT, которые ловятся через pub-sub редиса и раскидываются по клиентам. В redis лежит кэш этих операций.
«Спагетти» — это больше навыки программирования (в данном случае на js/node.js). Стркутура кода сильно зависит от приложения. Для социальной сети она будет одна, для игры другая. Ну а SOLID конечно соответствуйте, Derby вам тут, как минимум, не помешает.
Я попробую написать что-то из реальной жизни.
В чем вы видите преимущества Postgres для блога в сравнении с Mongo?
К Node.js нужно привыкнуть, иначе, как вы и сказали, это может превратиться в callback hell.
Всякие promises и fibers — это попытки сделать так, чтобы ваш код выглядел синхронно. И испольуются в основном теми, кто мыслит в категориях синхронных платформ.
В умелых руках node.js код красив и прозрачен.
Скучность — это довольно субъективное понятие. В том видео, на которое я вам дал ссылку, один пожилой человек с огромным опытом в IT утверждает, например, что JavaScript — это очень веселый язык, просто недооцененный.
Ваши опасения напрасны. На практике это не занимает много места.
Ну вот, как я и предполагал, использование в одном приложении разных версий пакетов — особенность JS.
Правильно говорят, что это всего лишь дело привычки. Со временем ты перестанешь переживать на этот счет.
Я думаю если ты только начинаешь разбираться, то посмотреть на голый node.js проект полезно. И посмотреть их доки.
Так же нужно понимать концепцию middleware connect.js.
Посмотреть на голый express.js проект.
На голом node.js можно писать, но он довольно низкоуровневый и тебе прийдется изобретать кучу вещей за ново (велосипедить). Для большинства проектов этого делать не надо, так как уже всё придумано до нас. Но в некоторых случаях, если это так нужно, то node.js позволяет опустить на уровень ниже.
Обычно node.js оборачивают в connect.js, его в свою очередь в express.js. Derby.js — это обвертка над express.js.
Каждый новый уровень добавляет возможностей, хотя немножко сложнее в понимании, чем предыдущий.
Я вам рекомендую посмотреть это.
Люблю JavaScript. Сам пишу на CoffeeScript`е. От него чуть больше удовольствия.
Традиционные способы работы с ООП — это дело привычки. Ничем не лучше, чем, например, прототипная модель.
Что вы хотели сказать вашим примером кода?
В каждом более менее большом проекте очень сложное дерево зависимостей. Это возможно связано с node.js и javascript, Мне трудно сравнивать с Ruby, я на нем почти не программировал, а разбираться сейчас уже не вижу смысла. В общем пакет A может иметь зависимостью пакеты B и С, а пакет B тоже зависим от пакета C. Это могут быть разные версии C. Если одна и та же версия, то он установится один раз в пакет A, а если разные то 2 раза (в A и B), Я думаю теоритически можно найти и другие способы разрешения таких ситуаци — какое-нибудь глобальное хранилище пакетов с возможностью сосуществования разных версий или еще как-то. Разные решения наверно имеют разные плюсы и минусы. Но в npm решили сделать так. Спроси у него почему. Что я тебе точно могу сказать это то, что npm очень молод и создавался с оглядкой и по опыту других пакетных менеджеров.
Эх. Тебе же рекомендовали все пакеты устанавливать локально для каждого приложения. :-) Как в воду глядели.
Ты пошел своим путем. :-) Зато разобрался с npm и я тоже вместе с тобой :-)
sudo npm install -g— эта штука не устанавливает все зависимости глобально. Их нужно устанавливать по очереди.Но я всё равно тебе не рекомендую так делать. Удали уже пару фильмов или музыку там какую-нибудь и найди место.
Если не будешь увлекаться созданием приложений, то в реальности это не так много места.
Я же сказал, что в основном не хранят в репозитарии. Но бывают исключения. Я, например, не храню.
Ты имеешь ввиду единый глобальный репозитарий? Попробуй
derby new -n. Это создаст проект без установки зависимостей.npm installТут докиЕсли просто версии обновить, то:
npm updateТут докиsudo. Спасибо за замечание.Что за проблемы с Redis под Windows? Здесь уже чего-то обсуждали про это.
node_modules— это место храниение npm пакетов. То есть всех зависимостей твоего приложения.Ты можешь установить все свои зависимости глобально, по примеру
npm install -g derby, тогда они будут лежать в общей папке (в разных ос в разных местах) и использоваться всеми приложениями. Но тут рекомендуют так делать только для пакетов, которые используются в shell (как derby утилита, например). Остальные пакеты обычно устанавливаются локально (вnode_modulesтвоего приложения).Обычно
node_modulesдобавляют в.gitignore, Но если ты деплоишь из git, то возможно лучше чекинить.Самописные модули ты выкладываешь на github и в
package.jsonпрописываешь git-путь.Но банкиры скажут «слишком большие риски». Попробуй им объяснить.
Технологии уже созрели. Теперь надо подождать пока в головах поменяется.
Пацан сказал, пацан сделал :-)
Задал ваш вопрос Joseph`у. Он ответил. Предлагаю переместить нашу дискуссию туда.
И это было последней каплей для перехода на Linux :-) Рекомендую.