Константин Черкасов coxx

Огонь!

Кажется, плагин перестал работать с Grafana 7.2 :-(

лучше бы это веб-морда была

нет, не правильно

В тексте слово «асинхронный» встречается 11 раз. И при внимательном чтении становится понятно, что авторы манифеста нигде не призывают писать код в асинхронном стиле (используя колбэки или future/deferred-магию).
Но лучше бы они ограничились словами event-driven и concurrent.

В сфере финансов есть, например, системы автотрейдинга — там быть технологическим слоупоком не выгодно…

Да что тут предложишь…
Жалкое зрелище… Душераздирающее зрелище… Кошмар! © Ослик Иа

Одна из фундаментальных проблем SIP-а в том, что это нагормождение различных костылей. Эйфелева башня из костылей. Одна треть костылей устарела, другая треть — никогда не используется. Я занимаюсь VoIP с 1999 года и убедился, что никто из разработчиков — ни клиентов, ни серверов — целиком не понимает всего стэка. А, по правде говоря, никакого стэка и нету. Есть просто десятки разрозненных документов и какие-то реализации.

> Детальное описание работы протокола SDP заслуживает отдельной статьи

Ох, как это знакомо :)
Во всех подобных статьях и книгах про VoIP очень много внимания уделяется SIP-у, а про SDP и RTP никто не пишет — видимо, уже здоровья не хватает :)
На самом деле реальный кошмар и хаос — это не сам SIP, а SDP и (как правило, кривые) реализации медиа-части в клиентах и серверах.

Как страшно жить…

Вам не повезло, если у вас сложилось мнение, что «процессы» — это «болтовня 100 часов в неделю».
Эффективные процессы на то и эффективные, что они никого не задалбывают, а наоборот, помогают работать и получать наслаждение от стремительного развития проекта. Это как хороший дизайн, который не должен бросаться в глаза.

А люди, которые не могут работать в команде по определенным правилам не просто разбегутся, а будут мной беспощадно уволены, ибо они неэффективны.

Я за статью поставил плюс, но, по-моему, от таких статей больше вреда чем пользы.

Знаете, есть такая японская концепция — Сюхари. Грубо говоря, это принцип обучения: «строго соблюдай правила (процессы)» — «адаптируй правила (процессы)» — «избавься от всех правил (процессов)».

Вы тут пишете про то, как сами перешли на третью стадию. А многие команды и разработчики даже и в первой стадии не находятся. Но, конечно, теперь им будет легче обосновать, почему надо забить на процессы и кодить как попало, без итераций, планирования, ретро и прочей «ненужной мишуры».

1. На хост-машине нужно настроить бридж br0 и связать его с интерфейсом eth0:

auto br0
iface br0 inet static
address 176.9.51.109
netmask 255.255.255.224
gateway 176.9.51.97
bridge_ports eth0
bridge_fd 0
К слову, «up route add», по-моему, здесь не нужен.

2. В конфиге /var/lib/lxc/vm1/config нужно указать ваш IP-адрес (176.9.69.13) и маску (в формате /NN)
lxc.network.link = br0
lxc.network.name = eth0
lxc.network.ipv4 = 176.9.69.13/NN

3. В контейнере в /etc/network/interfaces нужно тоже указать ваш IP-адрес (176.9.69.13), маску (в формате 255.255.255.MMM)
и шлюз, который сказал провайдер.

> Если объект имеет метод, который возвращает сам объект, мы можем писать так:
> some_obj.set_name(«abc»).inrease_age().update_items([1,2,3]).validate().save()
>
> Это тоже частный случай монады, просто он более привычен людям, привыкшим к ООП.

Ох, ну классно! У нас, оказывается, повсюду монады :)

Вот всегда так в питоне. Берешь утюг и гладишь. А оказывается, это высокотехнологичный прибор с парогенератором низкого давления и прецизионным термостатом и некоторые диссертации на эту тему защищают.

Что-то мне подсказывает, в реальном мире не существует ни одной реальной задачи, где бы подобная магия была бы уместна. Разве что, как экзотическая зарядка для ума…

Так вот почему на конференции .тостер {Мобильные приложения} так обильно, под видом ценных призов, раздавались свистки Yota…

Хочу переголосовать :)
Хоть я и отметил сразу несколько (Управление проектами, Дизайн и проектирование и Python), но про Python конференций нету, а про Управление проектами и Дизайн и проектирование уже есть и не одна.

о, спасибо, поправил

А вот бы вы нарыли и нам рассказали? :)

Это очень круто, что вы протестили!
Очень интересно про python — можно посмотреть на тестовый код?

Я несколько неверно выразился. Конечно, UUID может генерить и БД — в каких-то случаях это более уместно. Другое дело, что если алгоритм тот же (или столь же годный), то этот UUID можно и клиентом генерить с тем же успехом. Особенно, если хранилище само этого не умеет.

Так это и есть UUID.
Тут надо понять, что UUID — это не какой-то конкретный алгоритм. Есть разные реализации и рекомендация RFC-4122. Более того, в общем смысле, UUID — это не обязательно 16 байт, можно и больше сделать, если необходимо.
Суть в том, что это идентификатор, который генерируется на клиенте и он гарантированно уникален.

Вы как-то жестко бредите заблуждаетесь…
С чего вы взяли, что генерация UUID это «очень дорогая» операцией? Вы точно не путаете UUID с хэш-функцией?

Я вам, без всякого сарказма, советую мысленно проделать следующее упражнение. Представьте программу на ассемблере, которая формирует UUID. Не в точности до команды, а просто «крупными мазками», чтобы оценить масштаб.
А после этого представьте всю махину TCP-стека — тоже на ассемблере.
И сравните, просто по количеству машинных команд, что «дороже» — сходить куда-то за значением по сети или просто его сгенерить.

Именно так (генератором ключей назначена выделенная БД) делают в Flickr
code.flickr.com/blog/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/

А, ну конечно. В том и затея — посмотреть на варианты и дельные комментарии, чтобы с умом разные варианты применять.

Кажется, ребята из Twitter рассуждали также и поэтому сделали свой сервер, который генерирует ключи (см. ссылку в тексте).

Это, по сути, и есть тот самый «арбитр», про который вы говорите, только ходить к нему надо «до», а не «после» (откат закоммиченой транзакции — лучше про это не думать вообще, чтобы с ума не сойти).

Это вы про какой вариант?

Как по мне, такое решение ближе к централизованному генератору ключей — есть отдельный компонент, про который еще думать надо, А что будет, если он упадет?

Что за «случайный хэш» в СouchDB вы имеете ввиду?

Да, пожалуй, естественный ключ можно рассматривать, как один из вариантов. Со своими плюсами и минусами.

В MongoDB ObjectId — 96 бит (12 байт) и скорее похож на самодельный UUID (который 16 байт).

Это заблуждение. UUID как раз и придуман для того, чтобы «проверка на сервере» была не нужна (она невозможна в распределенной системе).
Почитайте как устроен UUID и вы поймете, что надо как-то очень хитро стараться (например, крутить часы), чтобы получить хотя бы не нулевую вероятность сгенерировать два одинаковых UUID.

Ну, на самом деле я почти согласен везде UUID использовать. Но в том и дело, что не всегда получается или не всегда удобно.

> Требования по увеличения (вместо случайности) скорей всего не являются значимыми.
> В случае распределённых данных эти требования невозможно выполнить.
Распределение зачастую делается по хэшу, а не по самому ключу. Я имел ввиду ситуацию, когда у нас (на уровне приложения) уже есть список ключей, то иногда было бы круто при помощи простой сортировки получить их естественную последовательность.

Не вполне понятно, какой вы смысл вкладываете в слово «Persistance».

В Tarantool есть снапшоты и WAL. Данные, разумеется, должны влезать в память, поскольку это in-memory database.

> Но вообще статью нужно было бы начинать с того, что вы чем-то лучше Redis'а,
> хотя бы по производительности.

Я для себя решил, что нет смысла сравнивать инструменты в стиле «X, лучше чем Y».
Надо смотреть на возможности, стабильность, возможно, роадмэп. И, если не хочется первопроходцем — на то, кто уже это использует и для чего.
А «лучше-хуже» — это оценка применимости к конкретной задаче.

На счет производительности: в докладе кое-что есть. И это надо делать ну уж ооочень большую систему, чтобы имело забивать голову разницей в производительности ± 10 процентов. На мой взгляд фичи важнее (по-моему, потенциально самое полезное — это вторичные индексы).

Статью написал я и я не сотрудник mail.ru.

Фразой про Nginx я как раз и хотел сказать, что пока славы и признания нет, и я хочу помочь этому проекту получить известность, а затем, возможно, признание и славу.

Мне реально по человечески очень интересно, почему список «Чем я могу помочь» у Вас вызвал отторжение (лучше не надо говорить от имени неких «читателей»).

Я делаю прямой призыв к сообществу: помогайте, кто чем может и совокупный результат достанется каждому. Повторюсь — я не имею никакого отношение к mail.ru.
У меня есть простой интерес: если проект получится раскачать, то я лично смогу пользоваться всеми благами open source, поддержкой сообщества и с уверенностью использовать эту систему в своих проектах.
И, поверьте, я свой вклад в этот open source проект вношу не только написанием статьи.

> первичный всегда Hash
Неа. Он только уникальным должен быть обязательно.
Я пробовал — можно TREE сделать (выбирать диапазоны по первичному ключу).

Я просто уверен, что название получилось так:
1. На листе бумаги нарисовали кружок: «это, типа, у нас ядро сервера»
2. К кружочку по сторонам подрисовали палочки «это, типа, TCP-коннекты»
Получился паучок. Потом игра слов: tul / tool
:-D

Пожалуй, в таких доработках меру надо знать. А то выйдет «пилили-пилили… глядь — а получился MySQL 3.23 образца 2001 года» :)

Кстати — это очень часто не принимают во внимание — узким и, потенциально, проблемным местом является не пропускная способность в запросах в секунду, а время отклика на один запрос. В многокомпонентных системах задержки (из-за промежуточной обработки, сетевого обмена и т.п.) вылезают раньше, чем чем будет достингнута предельньная пропускная способность одного компонента. А ведь, в конечном итоге, именно задержки ухудшают user experience.

Или я сам перепутал? :-)