ээ… я что-то не понял, зачем все это? Можно же просто с-xor-ить хвост с головой массива, без всяческих пременных, массивов и рекурсий? Или я что-то не так понял?
Я не доучился, но я внезапно знаю, что такое красно-черные деревья, и трудоемкости различных алгоритмов я неплохо понимаю, и со всем этим я столкнулся именно на работе. И что самое важное, заинтересовала и сподвигла разбираться в этом меня именно работа. Когда я слушал те же самые темы, читаемые нудным голосом, в универе, я пропускал многое мимо ушей. Это вообще сложная тема, если бы мне кто-нибудь обеспечил достаточную для жизни стипендию я может быть и пошел бы в ВУЗ сейчас, уже понимая что я хочу и зачем. Но! я не испытываю никакого желания посещать всяческую культурологию и физкультуру, то есть диплом мне в нашей системе не светит в любом случае, да и вообще… кто же меня кормить то будет )) Так что вот так и живу неучем :)
Некоторое время работал в рок-школе, так вот, мы устраивали для начинающих групп концерты на хороших площадках, и я столько раз видел удивленные глаза детишек, когда они втыкали свои корты, скваеры и епифоны в стек с marshall jcm 2000 к примеру :) Играя на 30-ти ваттных домашних комбиках, вы никогда не поймете разницу между профессиональным и бюджетным инструментом
Согласен что дело не всегда в цене, но уверяю, я например могу отличить сквайр от мексиканского фендера и от american delux. Это как раз приблизительно тот самый разброс 10000, 20000 и 60000. Возможно это были гитары просто разных типов. Для чистоты эксперимента надо было брать однотипные гитары, например три разных страта, или три разных леспола, тогда имеет смысл сравнивать. Но в таком случае, думаю, результат был бы другой. И еще момент, усилитель тоже играет роль, сравнивать надо на хорошем усилке, Дешевые модели усилителей имеют одно характерное свойство, задранные верха и вырезанную середину, специально для того, чтобы дешевые датчики максимально прилично на них звучали. Так что возможен парадокс, при котором дешевая гитара звучит на дешевом усилителе лучше чем дорогая.
Я на самом деле когда искал вариант рекурсивного выполнения тестов наткнулся на issue в репе mocha где tj сам предложил вариант использующийся в мейкфайле
Ну это не велосипеды, так, самокатики. Я же даю ссылки на документацию, там все это написано, а пока человек еще не въехал, мне кажется лучше просто дать набор инструкций и возможность потрогать получающееся приложение, если вдруг заинтересуется — в мелочах потом сам разберется. На самом деле непросто найти оптимальный подход в изложению материала, я в поиске, так что критика приветствуется :)
1. integration и unit тесты в разных поддиректориях будут в дальнейшем, а mocha рекурсивно по директориям не бегает.
2. Дело вкуса на самом деле. Во-первых мне нравится стиль в котором TJ свои проекты оформляет, во вторых тасков много, а писать npm run-script text-cov дольше, чем make test-cov, да и package.json засирается. Makefile лучше для этих целей подходит, имхо.
Это не совсем тот .gitignore который нужен, он заточен под нодовские либы, а у нас к примеру инструментированный код лежит в app-cov, а не в lib-cov. Думаю те кто серьезно займутся разработкой на ноде и сами со временем все плюшки обнаружат, у меня скорее цель заинтересовать.
Мне если честно просто не нравится стиль форматирования с которым создается package.json в этом случае, предпочитаю иметь целостный code-style по всему проекту.
Примеры таких тестов я привел скорее для проверки того, что фреймворки корректно установились, и хелло ворлд не имеет отношения к тому приложению, которое мы будем писать, вы же заметили что перед коммитом я предложил вообще удалить файл с тестом? Это просто подготовка фреймворков а не процесс написания приложения. Неужели вы думаете, что было бы лучше с первых шагов заставлять человека писать hello world с проверкой переменных окружения прятать код в отдельную директорию и делать загрузчик чтобы нормально потом jscoverage интегрировать? Надо постепенно в курс дела вводить, сначала просто дать возможность пощупать фреймворки. На днях выложу 3-ю главу, там уже начнем само приложение писать, все будет ок с тестами. Я на самом деле понимаю желание придраться к этому моменту, мне и самому глаз немного режет, но в контексте всей главы это явно не тянет на основания для того чтобы заявлять «Вы не понимаете что такое TDD».
Основной принцип TDD состоит в том, чтобы написать тесты до того как написан код, таким образом мы можем убедиться в том, что тесты действительно что-то тестируют, а не просто запускают код на выполнение и делают проверки в стиле true.should.be.true.
Я на самом деле предполагал, что кого-то может зацепить такой пример, так что подумаю еще как подшлифовать это место, но все таки стоит целиком текст читать :) В следующей главе будем писать первый контроллер, там уже реальные тесты будут, не беспокойтесь.
PS: Автор хорошо понимает что такое TDD, не беспокойтесь.
github.com/LearnBoost/socket.io/issues/516 вот тикет и он не закрыт, я использовал форк с хаком чтобы обойти эту проблему git://github.com/observing/socket.io.git#86fc49a770aeea4fc29f5d6b823c57b22b3bcf1d
да ладно, в проектах с документированным code-style-ом я конечно не балуюсь, но для себя всегда пишу без точек с запятой и никаких проблем не испытываю, а некоторый код изначально написанный just for fun пошел в продакшн и никто не жалуется, главное понимать как работают операторы js.
Вот нифига не на спичках, socket.io безбожно течет именно из-за пустых элементов хеша с сокетами, которые не удаляются при дисконнекте, и уже на нескольких десятках тысяч коннектов это становится весьма заметно.
Я на самом деле когда искал вариант рекурсивного выполнения тестов наткнулся на issue в репе mocha где tj сам предложил вариант использующийся в мейкфайле
2. Дело вкуса на самом деле. Во-первых мне нравится стиль в котором TJ свои проекты оформляет, во вторых тасков много, а писать
npm run-script text-covдольше, чемmake test-cov, да иpackage.jsonзасирается.Makefileлучше для этих целей подходит, имхо.Так и есть, начнем писать реальное приложение будут и тесты реальные.
Вот ссылочка на недописаную 3-ю главу github.com/DavidKlassen/node-tutorial/wiki/Web-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D0%BA%D0%B0-%D0%BD%D0%B0-node.js-%D0%B8-express#wiki-3.1 можете заранее свое мнение высказать, а можете даже форкнуть и поучаствовать в написании, буду признателен.
Я на самом деле предполагал, что кого-то может зацепить такой пример, так что подумаю еще как подшлифовать это место, но все таки стоит целиком текст читать :) В следующей главе будем писать первый контроллер, там уже реальные тесты будут, не беспокойтесь.
PS: Автор хорошо понимает что такое TDD, не беспокойтесь.