Вы путаете todo-листы с GTD. Именно от них Аллен и предлагает отказаться. В GTD есть инструмент напоминающий списки дел, но действующий диаметрально противоположно. Вот как раз его менеджить достаточно просто(при условии регулярного ревью). А с todo листами у меня тоже не сложилось(ну разве что списки покупок)
Прочитав три года назад про GTD из подобной статьи я обрадывался. В голове проскачила мысль — «это может быть полезно». Я даже попробовал добавить контексты и теги к своим todo спискам. На том все и кончилось.
Прочитав очередную статью два года назад я взялся за дело серьезнее — специализированные программы, еще несколько статей, много-много пинков под собственный зад и… система НЕ РАБОТАЛА! То ли я недостаточно старался, то ли у меня не та сила самоубеждения, а возможно нет мотивации и тд.
И лишь прочитав полгода назад книгу Аллена я понял в чем была проблема, почему не работали статьи. Все просто, под каждой такой статьей должна быть огромная красная надпись «ПРОЧИТАЙ КНИГУ!» Дядя Аллен не зря ест свой хлеб, GTD это не система тегов, проектов, и контекстов. GTD это даже не инбокс. GTD это очистка и упорядочивание бардака который творится у Вас в голове. И вот с этим книга Аллена справляется прекрасно — местами скучная, местами очевидная, но она РАБОТАЕТ. А уж потом можно братся за теги, контексты, Тickler файл и т.д.
Увы я не знаю как и куда «прифигачивается» Ардуина, и уж тем более зачем «прифигачивать» её к Емаксу, так что сказать точно не могу. Emacs это по сути интерпретатор Lisp'a(хоть и обрезанного), только вместо устройства ввода-вывода не терминал, а окошки текстового редактора.
Можно, но я только предположил. Возможно мы чего-то не знаем =).
Да grunt-reload server при проксировании добавляет во все html'ки js сниппет. И в браузере вы идете не по адресу сервера, а по адресу прокси.
Forever тоже особо не развивается. Последнее время пользуюсь node-dev(он в убунте показывает уведомления через libnotify). Как по мне для девелопмента никакой разницы, хоть node-dev, хоть supervisor, хоть nodemon. Все они делают одно и то же, и достаточно хорошо. А что касается production — то тут уже отдельный разговор и ни одна из этих либ там не нужна.
Пытался откопать в коде, но увы нашел только СSS и картинки. Рою дальше.
Могу предположить что чистится Global scope, и все скрипты загружаются заново.
Во-первых, если разрабатываете на Node.js, не обязательно ставить RubyGems. А вот Grunt стоит почти наверняка(Вы же не разрабатываете на Ruby без Rake? =)
Во-вторых, как на счет кросс-платформенности у guard и guard:livereload? На Винде работать будут?
Кроме того я не видел способа автоматического добавления JS сниппета в html'ки(не считая LiveReload browser extension). Он присутствует?
Решение с grunt-reload можно с легкостью ужать до тех же 4 строк что и у Вас, у меня просто насыщенный пример =)
А в принципе особой разницы нет, просто у Вас Руби скрипт, а у меня Нода)
Ну на счет сложности настройки библиотеки утверждений(assertion library) Вы по-моему перегибаете. Chai подключается одной строчкой(как на клиенте, так и на сервере). Кроме того тот-же Chai реализует несколько стилей assertions: assert, expect, should.
Что же касается Mocha — она реализует замечательный механизм для тестирования асинхронных методов, без использования тайм-аутов: callback done(). Все что нужно — передать done в асинхронный метод и вызвать его по окончании работы метода.
it('should save without error', function(done){
var user = new User('Luna');
user.save(function(err){
if (err) throw err;
done();
});
})
Данный подход не встречал ни у одного другого тест фреймворка для JS. Хотя данная фича на клиенте не так уж и важна, зато для ноды — самое то.
Из-за этого телефона в свое время я даже вёл заметки и ничего не забывал! Скорость и удобство набора невероятные для мобильного устройства. Сейчас андроид планшет и телефон — набираю что-то только в крайнем случае! Скучаю по P1i — спикрали у меня его голодные студенты(
Хм… я видать что-то в жизни пропустил. Я для тех же целей(английский учить!) «Друзей» в оригинале смотрю. Зато точно ничего не отвлекает, довольно интересно, и весело.
Насколько я понял, сама игра — это сильно урезанный старый-добрый "Бойцовский клуб". Таким образом Вы реализуете примитивный игровой процесс на технологии для этого не предназначенной? В чем смысл? Получить навык? Но на очередном клоне «Бойцовского клуба» игроделом Вы не станете, да и использование CMS не по назначению тоже не особо ведет к её пониманию(так мне кажется), только хаков напилите.
С игроделом и web-программированием(но ни с Drupal'ом и PHP) я знаком не понаслышке. Я слабо представляю как вы будете осуществлять взаимодействие между игроками в реальном времени
на основе CMS, проще и эффективнее(и полезнее для личностного роста) писать все руками, благо различные авторизации, профили пользователя и тд. пишутся довольно быстро. Зато в логике игры Вы будете отталкиваться только от потребностей игрового процесса, а не от возможности или невозможности прикрутить что-то к CMS.
Исходя из особенностей Drupal, игра должна быть браузерной. И не просто скрипт или флеш, встроенный в ноду
Вы наверное что-то пропустили — флеш или скрипт это не обязательно клиентские однопользовательские «бродилки-стрелялки-задротки», но еще и полноценные многопользовательские игры. А флеш или js используется для реализации игровой сцены. На стандартных HTMLных кнопочках, списках и чекбоксах много не наделаешь.
Если Вам хочется «активного взаимодействия с пользователем» да еще и в игровом виде посмотрите на игровые JS фреймворки, потом беритесь за какой-нибудь серверный язык, изучайте COMET или сокеты, стройте realtime общение с браузером. В качестве примера могу посоветовать связку CraftyJS + Node.js + Socket.io, но это только один из множества вариантов.
У меня тоже Caps замаплен на Ctrl. Просто я не люблю смещать руки с Home row(«asdf jkl;» клавиши), а тогда приходится Ctrl(Caps) использовать только с буквами и цифрами. У меня все буквы-цифры под Leader замаплены.
Так а где написано иное? Я в комментария выше помянул это уже несколько раз. Ладно, та фраза в которую вы меня ткнули, её я пожалуй исправлю, может она и правду сбивает с толку, но ведь картинку я не зря же рисовал!
Прочитав очередную статью два года назад я взялся за дело серьезнее — специализированные программы, еще несколько статей, много-много пинков под собственный зад и… система НЕ РАБОТАЛА! То ли я недостаточно старался, то ли у меня не та сила самоубеждения, а возможно нет мотивации и тд.
И лишь прочитав полгода назад книгу Аллена я понял в чем была проблема, почему не работали статьи. Все просто, под каждой такой статьей должна быть огромная красная надпись «ПРОЧИТАЙ КНИГУ!» Дядя Аллен не зря ест свой хлеб, GTD это не система тегов, проектов, и контекстов. GTD это даже не инбокс. GTD это очистка и упорядочивание бардака который творится у Вас в голове. И вот с этим книга Аллена справляется прекрасно — местами скучная, местами очевидная, но она РАБОТАЕТ. А уж потом можно братся за теги, контексты, Тickler файл и т.д.
Как говорится: «Работает — не трожь!»
И Вам спасибо на добром слове.
Да grunt-reload server при проксировании добавляет во все html'ки js сниппет. И в браузере вы идете не по адресу сервера, а по адресу прокси.
Могу предположить что чистится Global scope, и все скрипты загружаются заново.
Во-вторых, как на счет кросс-платформенности у guard и guard:livereload? На Винде работать будут?
Кроме того я не видел способа автоматического добавления JS сниппета в html'ки(не считая LiveReload browser extension). Он присутствует?
Решение с grunt-reload можно с легкостью ужать до тех же 4 строк что и у Вас, у меня просто насыщенный пример =)
А в принципе особой разницы нет, просто у Вас Руби скрипт, а у меня Нода)
Что же касается Mocha — она реализует замечательный механизм для тестирования асинхронных методов, без использования тайм-аутов: callback done(). Все что нужно — передать done в асинхронный метод и вызвать его по окончании работы метода.
Данный подход не встречал ни у одного другого тест фреймворка для JS. Хотя данная фича на клиенте не так уж и важна, зато для ноды — самое то.
С игроделом и web-программированием(но ни с Drupal'ом и PHP) я знаком не понаслышке. Я слабо представляю как вы будете осуществлять взаимодействие между игроками в реальном времени
на основе CMS, проще и эффективнее(и полезнее для личностного роста) писать все руками, благо различные авторизации, профили пользователя и тд. пишутся довольно быстро. Зато в логике игры Вы будете отталкиваться только от потребностей игрового процесса, а не от возможности или невозможности прикрутить что-то к CMS.
Вы наверное что-то пропустили — флеш или скрипт это не обязательно клиентские однопользовательские «бродилки-стрелялки-задротки», но еще и полноценные многопользовательские игры. А флеш или js используется для реализации игровой сцены. На стандартных HTMLных кнопочках, списках и чекбоксах много не наделаешь.
Если Вам хочется «активного взаимодействия с пользователем» да еще и в игровом виде посмотрите на игровые JS фреймворки, потом беритесь за какой-нибудь серверный язык, изучайте COMET или сокеты, стройте realtime общение с браузером. В качестве примера могу посоветовать связку CraftyJS + Node.js + Socket.io, но это только один из множества вариантов.