Сейчас никак, мы только планируем это делать. Сейчас у нас персентили считает каждый сервер сам по себе, что не совсем удобно, когда хочется посмотреть общую картину. Тут есть несколько вариантов:
1. Проксировать «персентильные» метрики конвенционально по имени (скажем, если есть суффикс «histogram»)
2. На уровне конфига statsd/аналога перечислять список метрик (возможно, со звездочками) которые пойдут на центральную считалку. Тут Heka выглядит более удобным инструментом для таких дел. Поскольку помимо метрик если еще и логи, которые тоже нужно доставлять, а с Хекой их еще можно сразу превращать и в метрики за компанию.
3. В логике приложения я бы этого не делал. У нас несколько десятков сервисов на разных языках, работают над ними разные команды. Данную логику лучше инкапсулировать на уровне платформы и протокола, чтобы минимизировать риск что-то сделать не так. Суффикс «histogram» кажется приемлемым компромиссом.
А вообще, не совсем понятно, зачем агрегировать метрики со всех серверов на одном бедном statsd/brubeck/whatever? Мы держим statsd на каждом сервере, агрегируем на месте и складываем оттуда напрямую в графит. Проблем с произвотидельностью statsd не было, даже на балансерах, где проскакивает 2600 метрик в секунду. Не 4.3 миллиона, конечно, но у нас столько и не будет никогда с одного сервера.
Один общий statsd/аналог следует держать рядышком для подсчета гистограм/персентилей, ибо их нужно агрегировать в одном месте. «Гистограммные» метрики — это около 5% от всех наших метрик, что пишем. Так что, statsd там тоже хватит.
Таким образом, для того, чтобы обновить ВСЕ приложения, запущенные на одном base image, вам нужно всего лишь перезапустить контейнеры
Нет, перезапустить контейнеры будет не достаточно. Потому что слои ссылаются на уникальные идентификаторы образов, которые имеют мало общего с «тэгами», которые мы используем в «FROM».
Чтобы обновить базовый образ для 10 работающих контейнеров, следует пересобрать образы для каждого из них (docker build), затем удалить все и создать заново. Потому что нельзя сделать restart контейнера, подменив ему идентификатор образа.
И это не баг, а фича «immutable infrastructure», гарантирующая неизменяемость базового слоя контейнера в процессе его жизни. Конечно, можно зайти через «nsenter» или «docker exec -ti bash» или «ssh» или, боже упаси, напрямую в файловую систему верхнего слоя контейнера на хостовой машине, но это будет не «by design».
С другой стороны, необходимость пересоздавать контейнеры для обновлений образа это большая боль, сводящая на нет такие красивые концепции, как "--volumes-from" и "--link".
В итоге, лобая система, используящая Докер более-мение серьезно, обрастает кучей костылей тут и там.
По поводу цивфовых подписей, Докеры же сделали это в 1.6 и Registry 2.0.
К моему удивлению, Angular ведет себя в данном случае довольно непредсказуемо:
— при переключении на template1 он вызывает функцию symbolsLength() дважды
— при переключении на template1 — единожды (а нужно, чтоб вообще не вызывал)
Но если установить изначальное значение templateName в 'template2' — тогда не вызовет symbolsLength() ни разу, что правильно.
Я сам знаком с Angular не больше недели, и мне интересно, почему так получается. Думаю, задам вопрос на stackoverflow. Видимо, на то есть свои причины, но xdenser все-таки прав касательно отсутствия объективных преимуществ обоих подходов.
1. Насчет POJO — это не совсем верно, поскольку в контроллер нам подсовывают клон объекта с предыдущей итерации.
Не клон, а наследник, имеющий родительский scope в качестве prototype.
Дело в том, что POJO — это то, что мы объявляем в этом scope (который подсунули). Scope — это, по сути, контейнер: jsfiddle.net/W3aMj/
$scope.model — это объект, который мы создали сами, с ним мы и работаем.
И кстати эти контроллеры в глобальном пространстве имен выглядят подозрительно. Надеюсь, их можно спрятать.
Да, меня это тоже сначала обескуражило, а потом оказалось, что можно по-нормальному. Все равно удивляюсь, почему в документации примеры с глобальными переменными. Наверное, чтоб продемонстрировать, как все просто :) jsfiddle.net/ayJqy/1/
Насчет того что множественное обновление массива вызывает обновление UI на каждой итерации… Что в Angular на этот счет?
Дык он на следующем тике все обновит, делая «dirty check». В этом же и фишка. В текущем тике можно менять хоть 1000 раз — ни чего не произойдет.
Как такое сделать в Knockout кстати?
В общем я думаю подход Angular vs Knockout это тема скорее для холивара. Потому что объективных преимуществ нет ни у того ни у другого.
Для меня объективное преимущество Angular — отсутствие недостатотков Knockout. Недостатков такого масштаба у Angular пока не вижу. Наверное, это единственная причина, по которой я продолжаю этот разговор :)
А вообще действительно, давайте закругляться. Если у вас есть вопросы касательно того, как устроен Angular, постараюсь на них ответить.
Сначала был в восторге от Backbone. Потом от Knockout. Потом от Knockback. С развитием приложений и усложнением интерфейсов я начал сталкиваться с сюрпризами и ограничениями, которые приходилось решать набором всяческих самописных костылей. Иногда конечно оказывалось, что я протупил и проблема решалась просто заменой computed на fn(), но все равно в итоге почему-то получалась каша. Работающая, но каша.
Недавно наткнулся на эту статью и решил попробовать AngularJS. Ребята, так это же совсем другое дело. Порог вхождения, конечно, выше — нужно сначала въехать в ряд сомнительных на первый взгляд понятий и принципов — но в итоге получается нечто более структурированное, стабильное, «бескостыльное».
Если не знакомы, советую поиграться, как минимум, для осведомленности :)
Молодцы! Социальный RSS-ридер — интересная и нетривиальная задача.
Два года назад мы с коллегой делали Eventr, но спустя год мы переключились на разработку другого проекта, после чего перестали поддерживать «старика», поскольку это оказалось довольно дорого и нерентабельно.
Самый коварный момент многопользовательского RSS-ридера заключается в том, что независимо от того, пользуются вашей системой или нет, вам все равно приходится обрабатывать тонны данных ежедневно. Для того, чтобы оптимизировать данный процесс, необходимо вводить всякие хитрые проверки и эластичные аглоритмы. Это сильно усложняет логику системы, следовательно, поддерживать ее с каждым днем становится все сложнее.
Неблагодарное это дело. Тут нужно либо море бабла, либо океан энтузиазма — чего вам и желаю! :)
Зашел на z-music.ru, ввел имя своего любимого исполнителя «Debussy», увидел треки, автором которых он не является z-music.ru/search/?q=debussy
Например, трек под названием «Claude Debussy — My Love» — это вообще саундрек Амели (Yann Tiersen).
Кстати, придумал более изящный способ реализации синхронного readFileByLines:
function readFileByLinesSync(path, fn) {
var input = fs.createReadStream(path);
var remaining = '';
input.on('data', function(data) {
remaining += data;
var index = remaining.indexOf('\n');
while (index > -1) {
fn(remaining.substring(0, index)); // process line
remaining = remaining.substring(index + 1);
index = remaining.indexOf('\n');
}
});
// Yield here
input.once.sync(input, 'end');
// process last line
if (remaining.length > 0) {
fn(remaining);
}
}.async(); // <-- important
function readFileByLinesSync(path, fn) {
var future = new Sync.Future();
var input = fs.createReadStream(path);
var remaining = '';
input.on('data', function(data) {
remaining += data;
var index = remaining.indexOf('\n');
while (index > -1) {
var line = remaining.substring(0, index);
remaining = remaining.substring(index + 1);
fn(line);
index = remaining.indexOf('\n');
}
});
input.on('end', function() {
if (remaining.length > 0) {
fn(remaining);
}
// End
future();
});
future.yield();
}.async(); // <-- important
//----------------
// My sync code
var Sync = require('sync');
Sync(function(){
// This will block until all lines will be passed
readFileByLinesSync('text', function(data) {
//add data to mysql if data.type = foo
//...
});
// do something else..
})
1. Проксировать «персентильные» метрики конвенционально по имени (скажем, если есть суффикс «histogram»)
2. На уровне конфига statsd/аналога перечислять список метрик (возможно, со звездочками) которые пойдут на центральную считалку. Тут Heka выглядит более удобным инструментом для таких дел. Поскольку помимо метрик если еще и логи, которые тоже нужно доставлять, а с Хекой их еще можно сразу превращать и в метрики за компанию.
3. В логике приложения я бы этого не делал. У нас несколько десятков сервисов на разных языках, работают над ними разные команды. Данную логику лучше инкапсулировать на уровне платформы и протокола, чтобы минимизировать риск что-то сделать не так. Суффикс «histogram» кажется приемлемым компромиссом.
Один общий statsd/аналог следует держать рядышком для подсчета гистограм/персентилей, ибо их нужно агрегировать в одном месте. «Гистограммные» метрики — это около 5% от всех наших метрик, что пишем. Так что, statsd там тоже хватит.
Нет, перезапустить контейнеры будет не достаточно. Потому что слои ссылаются на уникальные идентификаторы образов, которые имеют мало общего с «тэгами», которые мы используем в «FROM».
Чтобы обновить базовый образ для 10 работающих контейнеров, следует пересобрать образы для каждого из них (docker build), затем удалить все и создать заново. Потому что нельзя сделать restart контейнера, подменив ему идентификатор образа.
И это не баг, а фича «immutable infrastructure», гарантирующая неизменяемость базового слоя контейнера в процессе его жизни. Конечно, можно зайти через «nsenter» или «docker exec -ti bash» или «ssh» или, боже упаси, напрямую в файловую систему верхнего слоя контейнера на хостовой машине, но это будет не «by design».
С другой стороны, необходимость пересоздавать контейнеры для обновлений образа это большая боль, сводящая на нет такие красивые концепции, как "--volumes-from" и "--link".
В итоге, лобая система, используящая Докер более-мение серьезно, обрастает кучей костылей тут и там.
По поводу цивфовых подписей, Докеры же сделали это в 1.6 и Registry 2.0.
Не развалится, если эксплицитно объявить этот массив в текущем $scope, что и подразумевается.
К моему удивлению, Angular ведет себя в данном случае довольно непредсказуемо:
— при переключении на template1 он вызывает функцию symbolsLength() дважды
— при переключении на template1 — единожды (а нужно, чтоб вообще не вызывал)
Но если установить изначальное значение templateName в 'template2' — тогда не вызовет symbolsLength() ни разу, что правильно.
Я сам знаком с Angular не больше недели, и мне интересно, почему так получается. Думаю, задам вопрос на stackoverflow. Видимо, на то есть свои причины, но xdenser все-таки прав касательно отсутствия объективных преимуществ обоих подходов.
Не клон, а наследник, имеющий родительский scope в качестве prototype.
Дело в том, что POJO — это то, что мы объявляем в этом scope (который подсунули). Scope — это, по сути, контейнер: jsfiddle.net/W3aMj/
$scope.model — это объект, который мы создали сами, с ним мы и работаем.
Да, меня это тоже сначала обескуражило, а потом оказалось, что можно по-нормальному. Все равно удивляюсь, почему в документации примеры с глобальными переменными. Наверное, чтоб продемонстрировать, как все просто :) jsfiddle.net/ayJqy/1/
Дык он на следующем тике все обновит, делая «dirty check». В этом же и фишка. В текущем тике можно менять хоть 1000 раз — ни чего не произойдет.
Как такое сделать в Knockout кстати?
Для меня объективное преимущество Angular — отсутствие недостатотков Knockout. Недостатков такого масштаба у Angular пока не вижу. Наверное, это единственная причина, по которой я продолжаю этот разговор :)
А вообще действительно, давайте закругляться. Если у вас есть вопросы касательно того, как устроен Angular, постараюсь на них ответить.
Возможно, но есть пара нюансов.
> То же относится и к AngularJS — вам дают готовый рецепт структурирования
Это, пожалуй, самый главный плюс для меня.
Недавно наткнулся на эту статью и решил попробовать AngularJS. Ребята, так это же совсем другое дело. Порог вхождения, конечно, выше — нужно сначала въехать в ряд сомнительных на первый взгляд понятий и принципов — но в итоге получается нечто более структурированное, стабильное, «бескостыльное».
Если не знакомы, советую поиграться, как минимум, для осведомленности :)
Два года назад мы с коллегой делали Eventr, но спустя год мы переключились на разработку другого проекта, после чего перестали поддерживать «старика», поскольку это оказалось довольно дорого и нерентабельно.
Самый коварный момент многопользовательского RSS-ридера заключается в том, что независимо от того, пользуются вашей системой или нет, вам все равно приходится обрабатывать тонны данных ежедневно. Для того, чтобы оптимизировать данный процесс, необходимо вводить всякие хитрые проверки и эластичные аглоритмы. Это сильно усложняет логику системы, следовательно, поддерживать ее с каждым днем становится все сложнее.
Неблагодарное это дело. Тут нужно либо море бабла, либо океан энтузиазма — чего вам и желаю! :)
Таким образом фильтруется поток людей с хабра, дабы не было хабраэффекта и люди могли спокойно пользоваться сервисом.
Зашел на z-music.ru, ввел имя своего любимого исполнителя «Debussy», увидел треки, автором которых он не является z-music.ru/search/?q=debussy
Например, трек под названием «Claude Debussy — My Love» — это вообще саундрек Амели (Yann Tiersen).
Что-то у вас там напуталось.
А без sync тут будут макароны.
Кстати, придумал более изящный способ реализации синхронного readFileByLines:
Но если серьезно, ваша реализация построчного чтения файла будет глючить с большими строками — нужен буффер. Вот, пример: blog.jaeckel.com/2010/03/i-tried-to-find-example-on-using-node.html
«синхронная» реализация readFileByLinesAsync: