Для того, что бы не ставить Chef ручками и не заливать каждый раз обновленные coockbooks на сервер лучше использовать Knife. Для Chef-Solo даже есть Knife-Solo с полезными командами. Так же, что бы не хранить все coockbooks в репозитории (поскольку этот набор папок и файлов в 99% случаев не меняется), а только свои кастомные и не следить за их зависимостями (у многих кукбуков есть зависимости, которые тоже нужно скачивать) лучше использовать Librarian. Для таких статей лучше начинать со структуры кухни (kitchen), что бы новички понимали как «эта магия» работает.
Спасибо за статью.
Please note that SkypeKit was created to accelerate Skype use in the consumer electronics space. At this time, the following use cases outside of consumer electronics are prohibited:
Regulated Telephony Products or Services
Web Applications
Server Based Products
Mobile Applications
Tablet Applications
Products that compete with Skype's Paid Features
Можно скрестить WYSIWYG c Jeditable, добавил на его инициализацию при редактировании дополнительно инициализировать WYSIWYG. Для примера у Jeditable есть функция «data», через которую можно переопределять значение для редактирования. В ней можно инициализировать WYSIWYG.
(Mixed) data: Form data passed as parameter. Can be either a string or function returning a string. Can be useful when you need to alter the text before editing.
$(".editable").editable("http://www.example.com/save.php";, {
data: function(value, settings) {
/* Initialize WYSIWYG here */
return value;
}
});
PivotalTracker рассчитывает поинты команды за неделю автоматически. Например после двух недель робот на проектом он будет сообщать, что за неделя у команда успевает выполнить 10 поинтов. Это позволяет на следующие итерации раскидывать задачи так, что бы их сумарная сложность не превышала 10 поинтов в неделю.: например две задачи по 5 поинтов или 10 задач по одному поинту команда выполнит в неделю.
Картинки то можно обслуживать даже при работах, да и на самой странице maintenance могут использоватся картинки с сервера: set $maintenance 0;
if (-f $document_root/system/maintenance.html) { set $maintenance 1; }
if ($request_uri ~* (jpg|jpeg|gif|png|js|css)$) { set $maintenance 0; }
if ($maintenance) { rewrite ^(.*)$ /system/maintenance.html; break; }
Что происходит? То что база помечает документ как удалённый. Как она это делает? Она считывает документ, удаляет все поля из документа, вставляет дополнительное свойство _deleted:true и записывает документ под новой ревизией.
И это отлично. У CouchDB это одна из основных фишек.
Если WRITE у вас не самая редкая операция, то имея в дереве несколько миллионов документов вы неожиданно (причём именно неожиданно) можете обнаружить, что база начинает сильно тормозить. Например вы используете CouchDB, чтобы хранить документы с низкой продолжительностью жизни (сессии, лок-файлы, очереди).
Хранить в CouchDB документы с низкой продолжительность жизни — не лучшая для него задача.
А насчет тормозов вы имеете ввиду долгий ответ views при огромном количестве документов (милионы записей...)? Тогда stale=update_after в помощь, и будет он быстр даже на огромных колекциях.
«очень часто используемые данные» — я не знаю, что это значит в вашем понимании, но Я кладу очень часто используемые данные в Redis или MemcacheDB, поскольку они точно будут быстрее MongoDB в подобном случае.
У меня в библиотеке более чем три файла, я не вижу остальные дифы…
Скажем так, кормить троля мне не сильно хочется. Если Вам не нужно — не пользуйтесь. Если нужно, но данное решение не нравися — пишите свое, но то оно и опен сорс. Это решает любые проблемы.
Интересно глянуть на скорость — чей вариант быстрее :)
Спасибо за статью.
И как вы с этим разобрались?
(Mixed) data: Form data passed as parameter. Can be either a string or function returning a string. Can be useful when you need to alter the text before editing.
$(".editable").editable("http://www.example.com/save.php";, {
data: function(value, settings) {
/* Initialize WYSIWYG here */
return value;
}
});
set $maintenance 0;
if (-f $document_root/system/maintenance.html) { set $maintenance 1; }
if ($request_uri ~* (jpg|jpeg|gif|png|js|css)$) { set $maintenance 0; }
if ($maintenance) { rewrite ^(.*)$ /system/maintenance.html; break; }
И это отлично. У CouchDB это одна из основных фишек.
Хранить в CouchDB документы с низкой продолжительность жизни — не лучшая для него задача.
А насчет тормозов вы имеете ввиду долгий ответ views при огромном количестве документов (милионы записей...)? Тогда stale=update_after в помощь, и будет он быстр даже на огромных колекциях.
«очень часто используемые данные» — я не знаю, что это значит в вашем понимании, но Я кладу очень часто используемые данные в Redis или MemcacheDB, поскольку они точно будут быстрее MongoDB в подобном случае.
P.S. Повторяю линку для Вас: blog.mongodb.org/post/172254834/mongodb-is-fantastic-for-logging?91e05470
2. В конце README файла.
3. И да, моя разработка. Как и www.padrinorb.com/ чья-та и прочее.
4. У меня по данному треду все :)
Скажем так, кормить троля мне не сильно хочется. Если Вам не нужно — не пользуйтесь. Если нужно, но данное решение не нравися — пишите свое, но то оно и опен сорс. Это решает любые проблемы.