Как стать автором
Обновить

Комментарии 64

Труд хороший и полезный, продолжайте обязательно! Но как по мне, изучение технологии лучше начинать не с использования готового фреймворка, а с самых основ, примерно как в замечательной бесплатной книге The Node Beginner Book: в ней последовательно раскрывается и асинхронная модель, основы создания модульной системы, роутинг и много чего ещё. Причём, если честно писать или хотя бы копипастить все примеры, то в конце получится хоть и примитивное, но вполне функциональное веб-приложение, и становится понятнее, как работает тот же express.
А мне кажется, что как-раз такого подхода не хватает многим учебным материалам. Сначала заинтересовать, показать какой-то результат, удивить. И если человеку действительно интересно, то он уже обязательно и механизмы работы узучит, и в коде покавыряется.
Если бы речь шла об «академическом» подходе «изучить матчасть -> детально изучить технологию -> написать первую строчку кода» — то да, разумеется, это скучно. Но я имею в виду совсем не это, потому что можно начать с банального helloworld и постепенно дописывать различные функции, попутно разбираясь в механизмах работы. Разве это не самое интересное — не просто быстро получить результат, а понимать, почему всё делается именно так?
Мне кажется, что как-то уж очень поверхностно.
То, что вы написали за 10 минут гуглится без особых проблем.

Создается впечатление, что хотелось сделать сразу много и быстро. Получилось по верхам.
Я бы порекомендовал более подробно пройтись по подключаемым модулям, обработке запроса и т.д.
Жаль котят конечно, но свежих версий в репозиториях к сожалению нет, заморачиваться с описанием сборки пакетов под разные системы не вижу смысла.
В статье вы как бы намекаете, что у вас apt-based дистрибутив, сборка пакетов из сорцев там у всех одинаковая почти. В случае с убунтой я уверен на 99%, что есть ppa, куда были выложены пакеты в тот же день, что и релиз.
Да, я пробовал ставить из неофициальных ппа, но кажется что-то не очень гладко тогда прошло, уже не помню. Наверно стоит попробовать еще раз, если все хорошо пройдет, уберу make install из текста.
или покажите как собрать deb пакет из сорцев.
github.com/joyent/node/wiki/Installing-Node.js-via-package-manager
Тут есть все для установки под убунту:
— описана установка через ppa, в последнее время реально обновляемый с задержкой менее суток,
— и ссылка на apptob.org/, который полезен для собственноручной сборки и установки через .deb.
sudo add-apt-repository ppa:chris-lea/node.js
НЛО прилетело и опубликовало эту надпись здесь
node ставится в /usr, но никто не мешает указать --prefix. Про переменные можно поподробнее, возникли какие-то проблемы при прохождении? Вроде бы последние версии аккуратно встают в path и ничего не требуют, но я наверно все шаги перепроверю на виртуалбоксе.
Вы слишком перемудрили с примером c «Hello world» примером.
Намного проще и понятней пример из репозитория:
var express = require('express');
var app = express();

app.get('/', function(req, res){
  res.send('Hello World');
});

app.listen(3000);
console.log('Express started on port 3000');

Там же можно посмотреть еще 10ток примеров работы с express
Этот пример генерируется автоматически с помощью генератора express, пока что код не писали вообще. Это скажем так «ознакомительная» глава.
Соглашусь, что слишком поверхностно. С одной стороны, такой подход тоже неплох — ссылки указаны, изучай каждую из технологий по мере появления в тексте статьи, потом возвращайся к статье и т.д. В конце получится, что знаком уже с несколькими технологиями сразу. Но с другой стороны, статья в этом случае должна называться не «Web-разработка на node.js и express. Изучаем node.js на практике», а «Основные вещи, которые должен знать каждый, кто хочет писать на node.js и express». Практики тут очень мало. Но в целом, даже за подборку ссылок стоит сказать спасибо.
Я потихоньку начинаю бояться, что все будут считать node.js == express.
Я конечно люблю работы TJ, и сам пользуюсь, но, мне кажется, что все таки надо разграничивать node,js и пакеты для него. А то может складываться неправильное представление о node.js
Я не думаю, что это так уж страшно, в конце концов ассоциация между ruby и rails еще сильнее и ничего ужасного в этом нет
А я больше боюсь, что Node === Socket.IO.

Вообще взлет Express — дело ожидаемое. Львиное большинство же хочет писать веб-приложения, вот и хватаются за веб-фреймворк. Особенно это касается тех, кто приходит из Руби — они ищут аналог Рельсов и начинают клепать поверх Express те же велосипеды, что и под Rails или Sinatra.

Вообще, это еще хорошо, что Express — это только 70% всей node-разработки, а не 90, как в случае с Rails и Ruby*. Все-таки, асинхронный стиль программирования отпугивает довольно много традиционных веб-разработчиков.

*Цифры с потолка, но идея понятна.
Я все понимаю, но:
1) Вашу мать, сколько можно вы про ключи написали хоть что-то?
2) Какой Jade? (В б еще туда всунули coffe). Это должен быть простой пример.
3) Скажите как, вы додумались до такого?

http.createServer(app).listen(app.get('port'), function(){
  console.log("Express server listening on port " + app.get('port'));
});


это express!!!

var app = express.createServer(express.logger());
....
var port = 8000;
app.listen(port, function() {
  console.log("Listening on " + port);
});


Лирика закончена теперь по сути, плохой пример. Heroku плохая платформа, файловая система readonly, чтобы использовать redis или что то еще, еще нужно верифицировать аккаунт с данными о кредитной карте. Очень высокая нагрузка на сервера Heroku дают иногда о себе знать. Кроме этого там квота всего 100мб хотя реальных 97мб. Лучше или nodester или свой.
1) Я имею ввиду как их правильно сделать, как в Linux так и в Windows.
2) Лучше ejs проще да и нагляднее.
3) Вас уже отругали выше…
1. Мм… действительно стоит объяснять как сделать ключи? Ссылки не достаточно? Я подумаю.
2. Дело вкуса, мне нравится jade.
3. ок повторюсь, этот исходник сгенерирован автоматически, так же как и то что генерит например rails new. Цель первой главы познакомиться с технологиями и получить первый работающий пример без написания какого либо кода.
1. Объяснять не надо, просто команду приведите. make install же без объяснений привели и даже без ссылки :)
да, согласен, на этом месте многие застрять могут
Jade лаконичен, понравится тем кто использовал haml на тех же рельсах. Путь html (ejs) => haml (jade) — это путь в один конец. Попишешь на последнем и возвращаться не захочется.
Писать закрывающие теги? Нет, не слышал.
А мне кажется вполне в два.
>чтобы использовать redis или что то еще, еще нужно верифицировать аккаунт с данными о кредитной карте
Никаких проблем с redis на heroku у меня не было, redistogo подключаешь и вперед.
данные о кредитке я тоже не оставлял, правда я давно регистрировался, они что-то изменили?
Да уже поменяли, ввели верификацию.
Продолжайте!

Ннадеюсь, heroku лишь для быстрого старта приведён, а в дальнейшем будет описано как самому развернуть production на голом debian/ubuntu server по ssh.
Я думаю что основная часть будет ориентирована на деплой в heroku, хотя развертывание прода на голом сервере, тоже интересная тема, можно и запланировать такую главу
Имхо, нужно. Часто на этом затыкаются попытки освоить новый стэк. VDSки дешёвы, но новые технологии из коробки не работают, а оплачивать хостинг типа heroku не каждый заказчик захочет.
Добавлю для тех, кто пользуется Windows.

Git:

— Классика жанра — Git for Windows. Можно смело выбирать тот пакет, что слева: для пользователя Git его хватит за глаза.
— Более дружелюбное и современное — GitHub for Windows. Сам не пробовал, но разработчики из GitHub нахваливают этот клиент и утверждают, что он вполне может работать и с другими кодохостингами, в первую очередь с BitBucket, Google Code и CodePlex (и даже показывает граватары для коммитеров).

Node.JS:

— опять же, без необходимости сборки из исходников Node доступен на nodejs.org/#download После установки и node, и npm могут работать из обычной командной строки.

— альтернативный вариант — WebMatrix 2. Из коробки умеет запускать приложения под облегченным IIS в один клик, редактор подсвечивает синтаксис, неплохо автокомплитит, понимает LESS, SASS, CoffeeScript а также имеет два примера проектов с express в качестве стартовых темплейтов. Тут же присутствует интеграция с Windows Azure (облаком от Микрософт).

Замечу также, что одно другому не мешает: у меня на рабочей машине и обычный node, и встроенный в WebMatrix уживаются без каких-либо проблем. Даже если вы не хотите пользоваться IIS, WebMatrix будет для вас очень неплохой и, самое главное, бесплатной альтернативой для WebStorm или SublimeText.
НЛО прилетело и опубликовало эту надпись здесь
Кстати да — по поводу развёртывания проекта есть вопрос: какими средствами удобнее пользоваться для поддержания проекта в запущенном состоянии?
Скажем, cron, который дёргает localhost:3000/ раз в минуту, и перезапускает проект в случае если тот не откликается — по-моему ужасный костыль.
Может для ноды есть отдельные решения, но так нравится Monit
Лично я использую supervisord.
Я же правильно понимаю, что Monit требует обязательного использования pid-файлов. Как Вы его готовите? :)
Нет, необязательно. Тестов всяких много, чаще всего использую запросы прямо к демонам (порты или юникс/сокеты). HTTP, MySQL, Memcache, SSH знает из коробки (список большой это то, что использую), если что-то не знает, то можно просто последовательность байт послать и сравнить ответ с ожидаемым.
НЛО прилетело и опубликовало эту надпись здесь
С Forever всплыли такие проблемы:
1) Нужно было самому писать init.d-скрипты для запуска вместе с системой.
2) Контроль запущенных процессов отказывался работать. Было лень разбираться, почему.

Так что отказался от него в пользу supervisord.
НЛО прилетело и опубликовало эту надпись здесь
Мне кажется, что все подобные решения ужасные костыли. Мониторинг конечно нужен, чтобы узнать о падении. Первые версии node.js страдали от утечек и падений, но, к счастью, это уже в прошлом. Сейчас в 99.9% случаев падение происходит из-за своей ошибки. И правильный подход будет — вычислить её и исправить. Разного рода «перезапускатели» создают вокруг node.js атмосферу ненадёжности, хотя это не так. Я публиковал цикл статей о разработке сайта на node.js. Так вот, он работает месяцами и я перезапускаю его, только когда нужно что-то обновить. Падения были в самом начале, но из за ошибок в самом приложении и все они были исправлены.
Сейчас в 99.9% случаев падение происходит из-за своей ошибки. И правильный подход будет — вычислить её и исправить.

Ну разумеется :) Просто не хочется быть разбуженным посреди ночи звонком из-за упавшего сайта. Лучше утром следующего дня увидеть что сервер падал, глянуть лог и исправить ошибку.

Разного рода «перезапускатели» создают вокруг node.js атмосферу ненадёжности, хотя это не так.

Да к чёрту атмосферу — те кто написал что-то более-менее серьёзное на ноде, понимает что из себя представляет этот инструмент, и это зачастую положительная оценка.
Тот же популярный apache тоже временами падает, и ничего.

В общем, я конечно же за правильный код, но перестраховаться не помешает.
Я использую Runit для этого. Удобно и просто. Хотя по хорошему в node уже появился cluster и демонизировать можно и наверное нужно через него, но пока лень.
А под node.js ещё не написано какое-нибудь подобие rvm под ruby?
Для установки лучше всего использовать nvm. Преимущество — легко переключаться между установленными версиями.

Для размещения лучше www.dotcloud.com/ У них два бесплатных инстанса, т.е. можно еще и с базой данных бесплатно поработать. Если интересно, могу описать деплоймент подробнее.
НЛО прилетело и опубликовало эту надпись здесь
Очень правильный подход. В начале обучения всегда хотелось начать писать что-то более менее рабочее. Тонкость только в том, что не зная языка и среды, тяжело делать отладку, что тоже отбивает энтузиазм. А после винды make install сам по себе вызывал у меня ужас и панику. Поэтому посоветую добавлять в конце уроков более академичную информацию: всегда легче скопировать, а потом разобраться как работает, чем усвоить в голове как что-то работает, а потом это воплощать.

Желаю успехов!
Расскажите, пожалуйста, чуть подробнее про package.json.
Его смысл я понимаю, но практическая ценность не совсем ясна: в частности, вместо того чтобы указывать в нём версии и зависимости, я, подключаю модули не из node_modules, а из папки ./lib своего проекта (конечно же, предварительно положив туда их исходные коды).
Таким образом при развёртывании проекта на сервере я не забочусь об установленных пакетах и их версиях, а просто копирую всю папку проекта со своей машины — и потому получаю стопроцентно работающий проект.
Какие плюсы-минусы и такого подхода?
конечно же, предварительно положив туда их исходные коды

Ненужный этап. Обновление также проще.
Да, но при таком подходе не столкнусь с проблемой, что на боевом сервере программа будет работать некорректно из-за того что на локальной машине (на которой всё тестировалось), другие версии модулей.
Обновил lib локально, проверил, работает? — закидывай на сервер и будь уверен в работоспособности.
Версии модулей у вас зафиксированы :)
НЛО прилетело и опубликовало эту надпись здесь
Смысл приблизительно такой: та софтина, которая разворачивает проект на сервере, вызовет npm install project.json и в вашем инстансе будут установлены именно те модули (и те версии) которые вы указали. Кроме того, для heroku все равно нужен package.json, чтобы указать версию самого node.js.

Минус вашего подхода — нужно таскать в проекте кучу лишних исходников. Плюс — в системе не будут появляться всякие лишние команды (типа того же автогенератора express).
Простите, я честно признаюсь, что только начал читать статью и возможно дальше все поясняется (в таком случае заранее прошу прощения), но если вы используете Ubuntu 12.04 (как и я), то зачем собирать node из исходников, если можно установить его так:
sudo apt-get install nodejs
0.6.12 vs 0.8.1?
Да, это я заметил. А подскажите, велика ли разница между этими двумя версиями для написания учебного приложения (потому что я в ноде пока что ноль)? Или експрес-фремворк не стартонет без актуальной версии ноды?
упс, ниже ответил
0.8 вышел совсем недавно, так что пока все заточено под 0.6. И, как мне кажется, разработчики не будут ломать совместимость с ним в ближайшее время.
0.8.1 легко ставится из ppa:chris-lea/node.js
на 0.6.12 стартанет, но например в 10.10 если не ошибаюсь версия 0.4.х, а там уже траблы будут. Хотя это скорее всего просто привычка с того времени, когда все очень быстро менялось и было по большей части нестабильно. Я думаю, что перепишу эту часть и опишу установку последней версии из ppa, в таком случае я думаю ни у кого не будет претензий :)
Понятно, спасибо за ответ!
С нетерпением жду продлжения статьи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории