Спасибо. Tinytest часто встречал, пока искал про Laika материалы, видимо, довольно популярная штука. По поводу того, что не запустилась под Windows есть предположение — может, путей в переменных окружения не хватает? В частности, к phantomjs, он сам туда не прописывается, насколько я помню.
В чем смысл написания настолько стандартных комментариев? Они не несут абсолютно никакого смысла и только занимают время читающих. Вы надеялись на другой исход?
Для тех, кто не понял, почему по ссылке выше мы только пишем зависимости в packages.json, и не устанавливаем их затем по старинке через npm install — надо идти дальше по шагам и подправить код, вызвав зависимость через Meteor.require('пакет');, после чего запустить meteor как обычно. Во время запуска он и установит указанные пакеты. Делал это при выключенном метеоре и сначала не понял, почему нет пункта про установку. Очевидно, это сделано для живой перезагрузки. Т.е. не выключая сервер, можно даже установить пакет. Очень удобно для обновления сайта.
Спасибо за статью! Ждем продолжения, фреймворк очень интересный!
Попробовал сделать небольшое приложение на метеор, все оказалось более чем просто, но возник вопрос — какой модуль лучше использовать для работы с изображениями, например, создание миниатюр (thumbnails) и водяных знаков?
Нашел еще одну книгу по Meteor, опубликована в декабре 2012 — www.packtpub.com/getting-started-with-meteor-javascript-framework/book
Вообще, интересный фреймворк. Возник вопрос к тем, кто на нем хоть что-нибудь пробовал делать — использование в одном месте кода для сервера и клиента не превращается в конечном итоге в мешанину (в духе PHP начала двухтысячных годов)?
Например, тут мы еще видим, что происходит, а если будут добавляться дополнительные условия и т.п.?
var Messages = new Meteor.Collection("messages");
if(Meteor.isServer) {
Meteor.publish("messages", function() {
return Messages.find({});
});
}
if(Meteor.isClient) {
Meteor.subscribe("messages");
}
Код взял отсюда: andrewscala.com/meteor/
Либо получится файл, в котором сначала идет код для сервера, а потом для клиента, и это мало чем отличается от других решений… И еще вопрос тем, кто активно следит за его развитием — чем он еще лучше, например, связки NodeJS+Express+AngularJS, кроме автоматического обмена данными с сервером (это большущий плюс) и уменьшения количества кода на сервере и клиенте? Удобно ли это?
У меня абсолютно такие же действия — переходишь на сайт, читаешь, всплывает окошко, закрываешь сайт и открываешь следующий в поисковике — зачастую он оказывается без рекламы и остаешься дочитывать на нем.
Если уж цель сайта — получить регистрации/email'ы/еще что-то от пользователей, то лучшим вариантом будет выделить определенный блок (сверху, слева, справа, где угодно) и обычным баннером показывать крутую акцию или красивую картинку для «сверхбыстрой регистрации». Или кнопку «подписаться», таким образом, пользователь не забудет про сайт и можно будет иногда напоминать о себе. Если же это была информация, нужная только здесь и сейчас, то он в любом случае не вернется на сайт и получится «мертвая душа».
Интересно! Попробую сделать подобный парсинг в своей библиотечке habrahabr.ru/post/204162/ когда буду в отпуске (в конце декабря). Тоже увлекался в свое время написанием ботов/парсеров текстов, очень интересная тема.
Спасибо за код и идею!
var date = new Date(Date.UTC(2012, 11, 20, 3, 0, 0));
var options = {weekday: "long", year: "numeric", month: "long", day: "numeric"};
alert(new Intl.DateTimeFormat("de-DE", options).format(date));
// → "Donnerstag, 20. Dezember 2012"
Пример отсюда: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat#Example:_Using_options
Вообще, тут есть один большой плюс — можно не заморачиваться и отображать дату в понятном и привычном человеку формате минимум усилий, но и такой же минус — если потребуется сделать шаг в сторону, где потребуется немного другое форматирование, то это не получится. Я правильно понял?
Мне кажется, что это не очень удобно и лучше бы сделали реализацию как в других ЯП. Ну и плюсом, если его включать в свое веб-приложение, то в остальных браузерах придется реализовывать аналогичное представление своим способом и надо учитывать все локали, на которых это приложение будет использоваться и тестировать всевозможные комбинации форматов — где, что и как он отображает.
Вот это меня и смущает. Если неправильно понял описание и примеры, то не могли бы вы пояснить?
И следующим анонсом от Amazon будет почтовый гексакоптер с двумя пулеметами на борту «в целях самозащиты».
В целом, очень интересная идея, но, думаю, она не сможет окупиться на данный момент. Тут выгоднее будет брать на борт несколько посылок для доставки в какой-то определенный район города, выбор кому что отдать, а это увеличит размеры. Либо стоимость такой доставки будет очень высокой.
Вынес переводы в отдельный файл, лежит рядом с библиотекой — translations.json. Переводы можно использовать в нем. Также, этот файл автоматом подгружается из той же директории, где и библиотека. Можно запретить автоподгрузку, если использовать следующий вид подключения скрипта:
т.е. с GET-параметром loadTranslations=false. В иных случаях подгружается. Также, можно руками подгрузить переводы из объекта или по урлу из JSON-файла, используя функцию loadTranslations — docs.tempusjs.org/documentation/docs/tempus/tempus.global:loadTranslations
Спасибо! По поводу своей функции перевода — хорошая идея!
Думаю, что тогда надо делать так:
— переводы оформить как JSON-файл, который можно подключать отдельно (или вообще не подключать, если не требуется) — да и проще его изменить будет, используя только нужные переводы для конкретного сайта. Думаю, что лучше тогда будет генерировать также версию «все в одном».
— функция tempus.translate(text), которую можно перекрывать своей функцией — то, о чем вы сказали.
Месяцы с 1 плохо для поддержки кода новыми разработчиками, ибо отличается от нативной реализации.
Типичный холивар с 1 в месяцах в js :) Тут можно и использовать, и не использовать, все зависит от принятых в конкретном веб-приложении стандартов. Отключается вполне легко:
tempus.options('monthFromZero', true);
Генерация может пригодиться, хотя пока не понимаю где.
Мне, например, требуется настраиваемый календарик, который генерируется без участия сервера, а пользователь на нем может отмечать некоторые события, которые затем отправляются на сервер (дата-событие).
Для этого можно использовать between и calc, примеры есть в статье выше. between по сути является разностью двух дат, а calc — смещением даты от заданной на какой-либо промежуток.
packages.json, и не устанавливаем их затем по старинке черезnpm install— надо идти дальше по шагам и подправить код, вызвав зависимость черезMeteor.require('пакет');, после чего запуститьmeteorкак обычно. Во время запуска он и установит указанные пакеты. Делал это при выключенном метеоре и сначала не понял, почему нет пункта про установку. Очевидно, это сделано для живой перезагрузки. Т.е. не выключая сервер, можно даже установить пакет. Очень удобно для обновления сайта.Попробовал сделать небольшое приложение на метеор, все оказалось более чем просто, но возник вопрос — какой модуль лучше использовать для работы с изображениями, например, создание миниатюр (thumbnails) и водяных знаков?
Вообще, интересный фреймворк. Возник вопрос к тем, кто на нем хоть что-нибудь пробовал делать — использование в одном месте кода для сервера и клиента не превращается в конечном итоге в мешанину (в духе PHP начала двухтысячных годов)?
Например, тут мы еще видим, что происходит, а если будут добавляться дополнительные условия и т.п.?
Код взял отсюда: andrewscala.com/meteor/
Либо получится файл, в котором сначала идет код для сервера, а потом для клиента, и это мало чем отличается от других решений… И еще вопрос тем, кто активно следит за его развитием — чем он еще лучше, например, связки NodeJS+Express+AngularJS, кроме автоматического обмена данными с сервером (это большущий плюс) и уменьшения количества кода на сервере и клиенте? Удобно ли это?
Если уж цель сайта — получить регистрации/email'ы/еще что-то от пользователей, то лучшим вариантом будет выделить определенный блок (сверху, слева, справа, где угодно) и обычным баннером показывать крутую акцию или красивую картинку для «сверхбыстрой регистрации». Или кнопку «подписаться», таким образом, пользователь не забудет про сайт и можно будет иногда напоминать о себе. Если же это была информация, нужная только здесь и сейчас, то он в любом случае не вернется на сайт и получится «мертвая душа».
Спасибо за код и идею!
Если верить ей, то в FF и Safari вообще не поддерживается, в IE только последнем, а на мобильных вообще никто, кроме хрома, не поддерживает. Это имел в виду.
Вообще, как я понял, там нельзя сделать свое форматирование? Только передаешь локаль и что показывать:
Пример отсюда: developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat#Example:_Using_options
Вообще, тут есть один большой плюс — можно не заморачиваться и отображать дату в понятном и привычном человеку формате минимум усилий, но и такой же минус — если потребуется сделать шаг в сторону, где потребуется немного другое форматирование, то это не получится. Я правильно понял?
Мне кажется, что это не очень удобно и лучше бы сделали реализацию как в других ЯП. Ну и плюсом, если его включать в свое веб-приложение, то в остальных браузерах придется реализовывать аналогичное представление своим способом и надо учитывать все локали, на которых это приложение будет использоваться и тестировать всевозможные комбинации форматов — где, что и как он отображает.
Вот это меня и смущает. Если неправильно понял описание и примеры, то не могли бы вы пояснить?
В целом, очень интересная идея, но, думаю, она не сможет окупиться на данный момент. Тут выгоднее будет брать на борт несколько посылок для доставки в какой-то определенный район города, выбор кому что отдать, а это увеличит размеры. Либо стоимость такой доставки будет очень высокой.
т.е. с GET-параметром loadTranslations=false. В иных случаях подгружается. Также, можно руками подгрузить переводы из объекта или по урлу из JSON-файла, используя функцию loadTranslations — docs.tempusjs.org/documentation/docs/tempus/tempus.global:loadTranslations
Думаю, что тогда надо делать так:
— переводы оформить как JSON-файл, который можно подключать отдельно (или вообще не подключать, если не требуется) — да и проще его изменить будет, используя только нужные переводы для конкретного сайта. Думаю, что лучше тогда будет генерировать также версию «все в одном».
— функция tempus.translate(text), которую можно перекрывать своей функцией — то, о чем вы сказали.
Типичный холивар с 1 в месяцах в js :) Тут можно и использовать, и не использовать, все зависит от принятых в конкретном веб-приложении стандартов. Отключается вполне легко:
Мне, например, требуется настраиваемый календарик, который генерируется без участия сервера, а пользователь на нем может отмечать некоторые события, которые затем отправляются на сервер (дата-событие).
Не видел, спасибо
Тут можно попробовать использовать поиск по геолокации html5demos.com/geo (плохо, т.к. браузер спрашивает, можно ли запросить местоположение) или по IP www.ipinfodb.com/ (требуются большие базы или запросы) или использовать подобную мини библиотеку bitbucket.org/pellepim/jstimezonedetect/overview