Кстати хотел бы заметить одну неприятную особенность. Когда скачиваются, необходимые для обновления данные, с Windows Store (а это порядка 2.44 Гб), то нельзя выходить на рабочий стол, надеяться на то, что будет производится закачка в фоне не получится, скачивание с Windows Store откладывается (приостанавливается). Пришлось даже отключить выключение дисплея, в этом случае тоже приостановка происходила. В общем во время обновления, работать за компом не возможно.
А так в общем очень хорошие впечатления. Единственно теперь не понятно, как отключать «Выключение жестких дисков», нет опции «No», только возможность установки кол-ва минут, после истечения которых диски уснут.
В целом управляемость меню стало намного лучше. Появилась моя любимая кнопочка «Пуск». Папки «Документы», «Изображения» и т.д. вынесены в окно эксплорера, при открытии проводника, в окне которого отображается две области. Верхняя с папками «Документы», «Изображения» и т.д., а нижняя с информацией о ваших дисках. Мне показалось очень удобным! Скорость работы IE 11 очень порадовала! В общем я рад выходу Windows 8.1 preview!
Спасибо большое! Для меня эта тема была актуальна. Я использовал флеш для написания контрола, если флеш не поддерживался показывался стандартный контрол, но вот до такого не додумался. Отлично все работает, особенно превью :)
Я заметил что при изменении ширины окна браузера в сторону уменьшения, картинки плавно уменьшаются и при фиксации размера окна браузера нормально заполняют области. Но вот если увеличивать размер окна, то картинки начинают расширяться и налазить друг на друга :( не очень то смотрится.
Win8 Chrome 23.0.1271.64 m
Никто не говорил про сложные тесты :) Я лишь говорил про реальные тесты. Да собственно я и не нападал на автора, лишь выразил свое мнение. Я вижу что, статья автора хорошая и ничего не имею ни против автора ни против статьи :) Я лишь указал на недостатки, на которых я посчитал нужным заострить внимание :) Ваше мнение я тоже уважаю :).
— Теперь все же хочу заострить ваше внимание на проверке работоспособности тестовых (да и любых фреймворков), для их проверки необходимо запускать тесты идущие в репозитории с фреймворком, к примеру у supertest есть тесты проверяющие корректность работы фреймворка. Потому я бы очень хотел, чтобы авторы таких статей все же более правильнее относились к тому, как преподносить информацию. У should.js тоже есть свои тесты, потому что эти фреймворки пишут достаточно грамотные и активные люди.
Потому будьте профессионалами, не забывайте про назначение тех или иных средств. Не стройте велосипеды с откровенно плохими «проверками» работоспособности. :)
И опять же судить, о том прав я или нет — Вам! Я не могу что то навязать, я лишь советую.
Ну извините, если я Вас обидел, честно сказать не хотел. Мне просто всегда говорили, если что то хочешь показать, рассказать продумай все! (совсем все продумать конечно не получается, но минимализировать кол-во ошибок можно). Т.е. Вы понимали, что все таки, то что Вы выложили не совсем корректно, но однако не хотите понять, то что даже для того чтобы пощупать фреймворки, не надо выкладывать откровенно пустой и ничему не учащий код. Я не говорю что Вам надо сразу все показывать, но если Вы решили показать как писать тесты, то лучше бы взяли бы какой нибудь простенький класс на JavaScript и тут показали бы преимущества TDD, но не на тех тестах, которые Вы привели.
============================================================================================
И потом я ничего не услышал в Вашем комментарии по поводу того факта, что Вы указали реализацию app.js и server.js, а потом показали тест на GET запрос (Это явно не в стиле TDD).
============================================================================================
Посмотрите подкасты по TDD и Вы увидите, авторы не делают себе поблажек или осечек или приписки («не хочется сразу все показывать»), они стараются показать пример другим, чтобы людям было приятно посмотреть. И чтобы не было таких вот замечаний по поводу корректности представленного.
По этому, раз уж заговорили про TDD будьте добры в тексте, показывать шаги: RED, GREEN, REFACTOR касаемо тестируемой сущности (у Вас к сожалению нет ничего такого по отношению к тестированию того же GET запроса на главную страницу. Я вижу единственный тест.).
А иначе это просто можно назвать «показ того как можно тест написать ради забавы (исследовани возможностей фреймворка)»
Ну в общем то вывод делать Вам :) Я лишь высказал свое мнение. :) Спасибо что выслушали :)
Я внимательно читал :) Извиняюсь, если задел своим комментарием, но Вы написали первый и единственные тест после того как указали реализацию app.js и server.js. А должны были для начала написать тест красной полосы именно для проверки GET запроса. Вместо этого вы пишите якобы тесты «true есть true» и «foo не равно bar» — это все к вашему тестовому проекту ну никак не относится. Так что извините, но судя по статье я не очень верю в то, что Вы действительно понимаете что такое TDD. Ничего личного, лишь моя объективная оценка.
Пусть меня простят хабровчане, но не мог я пройти мимо заголовка «Автоматизированные тесты». Честно сказать, язык не поворачивается назвать тестами, то что предложил автор статьи:
describe('Truth', function () {
it('should be true', function () {
true.should.be.true
})
it('should not be false', function () {
true.should.not.be.false
})
})
и запустим его
$ ./node_modules/.bin/mocha --require should --reporter spec tests/test.js
Вполне естественно, что такой тест пройдет, так что заменим его на что-то неработающее
describe('foo variable', function () {
it('should equal bar', function () {
foo.should.equal('bar')
})
})
Если автор хотел показать знание TDD и умение писать тесты, то ему следует все таки в качестве примера приводить реальные тесты, пусть даже для тестового приложения. И у меня честно сказать сложилось впечатление, что автор не понимает что такое TDD. Почему я так подумал, а вот доводы: Во первых TDD не подразумевает написание «липовых» тестов, которые пройдут. Во вторых, не надо писать тест красной полосы только для того чтобы на фейковых данных показать что он не проходит. Это может не правильно трактоваться новичками, кто будет изучать TDD. И потом, не нужно подгонять тест под реализацию, реализация должна подчиняться тесту. Ибо тест — это контракт.
Так как картинки по каким то загадочным причинам сюда вставить не получается… выкладывают Plain текст :)
Anonymous Operations: Since @AnonymousOwn3r is getting anal raep, we'd like to announce vacancy for the post of our beloved 134d3r. All newfags & feds may apply.
Netcake: Watch out… We got a bad ass over here. > @AnonymousOwn3r
Anonymous Operations: Please redirect your godaddy hate to @AnonymousOwn3r He is the 'leader' of Anonymous and a faggot. #derp Have #lulz with that.
Похоже аноны не довольны тем, что некий Own3r объявил себя Security лидером группы и похоже они устроили ему, что то не очень приятное :) Твиты прилагаю. Между прочим аноны указывают на Own3r, что свое негодование по поводу GoDaddy предъявляйте ему :)
Посмотрел на скидки, на популярные продукты меньше 50% скидку дают.
Например ReSharper без скидки стоит $199, а со скидкой $149 и это 26% скидка
Зато на PhpStorm: стоит $99, со скидкой получается $49 а тут примерно 50% скидка получается :)
Обязательно попробуйте, я вот к сожалению не додумался до такой реализации проверки на изменения. Посмотрев код dirtyFlag был приятно удивлен, простотой и в тоже время функциональностью :)
Не знаю, я провел эксперимент, убрал папки пакетов, socket.io и socket.io-client, которых не хватало и запустил команду npm install -d, но после ее запуска и завершения не обнаружил эти пакеты в папке node_modules. Так что эта команда не помогает в решении проблемы отсутствующих пакетов (даже npm) в текущей ситуации. Если мы заглянем внутрь файл package.json, то увидим внутри, в разделе mappings, следующие строчки
судя по всему данные настройки, может обрабатывать sm менеджер. Но при помощи чистого npm не получится получить эти пакеты, даже с опцией -d. Я проверил сам это утверждение, убрав пакеты: treehugger, vfs-architect, socket.io, socket.io-client и при запуске команды, она не подтянула эти пакеты. В общем вот такие вот выводы.
Я извиняюсь, но из-за минусовой кармы, я имею право 1 раз в час отвечать на комментарии, потому решил ответить Вам в обновлении статьи. Пока что неполадок не обнаружил, т.е. получается что Cloud9 ide можно запустить и на Node.js 0.8.8. Позволю себе сравнить успех, с таким предположением: если взять китайскую культуру, то у них число 8 — счастливое :) и означает процветание, потому на этой версии Node.js — возможны чудеса. А тут целых две 8 :)
А так в общем очень хорошие впечатления. Единственно теперь не понятно, как отключать «Выключение жестких дисков», нет опции «No», только возможность установки кол-ва минут, после истечения которых диски уснут.
В целом управляемость меню стало намного лучше. Появилась моя любимая кнопочка «Пуск». Папки «Документы», «Изображения» и т.д. вынесены в окно эксплорера, при открытии проводника, в окне которого отображается две области. Верхняя с папками «Документы», «Изображения» и т.д., а нижняя с информацией о ваших дисках. Мне показалось очень удобным! Скорость работы IE 11 очень порадовала! В общем я рад выходу Windows 8.1 preview!
Опечатка в заголовке: «Скидки и промо-коды для актЫвных участников»
Скрин прикладываю:
Win8 Chrome 23.0.1271.64 m
— Теперь все же хочу заострить ваше внимание на проверке работоспособности тестовых (да и любых фреймворков), для их проверки необходимо запускать тесты идущие в репозитории с фреймворком, к примеру у supertest есть тесты проверяющие корректность работы фреймворка. Потому я бы очень хотел, чтобы авторы таких статей все же более правильнее относились к тому, как преподносить информацию. У should.js тоже есть свои тесты, потому что эти фреймворки пишут достаточно грамотные и активные люди.
Потому будьте профессионалами, не забывайте про назначение тех или иных средств. Не стройте велосипеды с откровенно плохими «проверками» работоспособности. :)
И опять же судить, о том прав я или нет — Вам! Я не могу что то навязать, я лишь советую.
Оссу!
============================================================================================
И потом я ничего не услышал в Вашем комментарии по поводу того факта, что Вы указали реализацию app.js и server.js, а потом показали тест на GET запрос (Это явно не в стиле TDD).
============================================================================================
Посмотрите подкасты по TDD и Вы увидите, авторы не делают себе поблажек или осечек или приписки («не хочется сразу все показывать»), они стараются показать пример другим, чтобы людям было приятно посмотреть. И чтобы не было таких вот замечаний по поводу корректности представленного.
По этому, раз уж заговорили про TDD будьте добры в тексте, показывать шаги: RED, GREEN, REFACTOR касаемо тестируемой сущности (у Вас к сожалению нет ничего такого по отношению к тестированию того же GET запроса на главную страницу. Я вижу единственный тест.).
А иначе это просто можно назвать «показ того как можно тест написать ради забавы (исследовани возможностей фреймворка)»
Ну в общем то вывод делать Вам :) Я лишь высказал свое мнение. :) Спасибо что выслушали :)
describe('Truth', function () {
it('should be true', function () {
true.should.be.true
})
it('should not be false', function () {
true.should.not.be.false
})
})
и запустим его
$ ./node_modules/.bin/mocha --require should --reporter spec tests/test.js
Вполне естественно, что такой тест пройдет, так что заменим его на что-то неработающее
describe('foo variable', function () {
it('should equal bar', function () {
foo.should.equal('bar')
})
})
Если автор хотел показать знание TDD и умение писать тесты, то ему следует все таки в качестве примера приводить реальные тесты, пусть даже для тестового приложения. И у меня честно сказать сложилось впечатление, что автор не понимает что такое TDD. Почему я так подумал, а вот доводы: Во первых TDD не подразумевает написание «липовых» тестов, которые пройдут. Во вторых, не надо писать тест красной полосы только для того чтобы на фейковых данных показать что он не проходит. Это может не правильно трактоваться новичками, кто будет изучать TDD. И потом, не нужно подгонять тест под реализацию, реализация должна подчиняться тесту. Ибо тест — это контракт.
Anonymous Operations: Since @AnonymousOwn3r is getting anal raep, we'd like to announce vacancy for the post of our beloved 134d3r. All newfags & feds may apply.
Netcake: Watch out… We got a bad ass over here. > @AnonymousOwn3r
Anonymous Operations: Please redirect your godaddy hate to @AnonymousOwn3r He is the 'leader' of Anonymous and a faggot. #derp Have #lulz with that.
Например ReSharper без скидки стоит $199, а со скидкой $149 и это 26% скидка
Зато на PhpStorm: стоит $99, со скидкой получается $49 а тут примерно 50% скидка получается :)
«vfs»: [«npm», «github.com/c9/vfs/tarball/61841e99eda6ea9a8b801fd145b9a0af286ad324»],
«vfs-architect»:[«npm», «github.com/c9/vfs-architect/tarball/43bd19b9e7b2ddb95bdc1116143ce7fb22c6a5d3»],
«treehugger»: [«npm», «github.com/ajaxorg/treehugger/tarball/8026fea03e87a5a773e87ae9d78e29fab912d52e»],
«socket.io»: [«npm», «github.com/ajaxorg/socket.io/tarball/7aa252bab49e6bbc314dc2678b108b6e0876007a»],
«socket.io-client»: [«npm», «github.com/ajaxorg/socket.io-client/tarball/35f0763ffcaa7ccc3c664460667577e77da82b10»]
судя по всему данные настройки, может обрабатывать sm менеджер. Но при помощи чистого npm не получится получить эти пакеты, даже с опцией -d. Я проверил сам это утверждение, убрав пакеты: treehugger, vfs-architect, socket.io, socket.io-client и при запуске команды, она не подтянула эти пакеты. В общем вот такие вот выводы.