В тексте слово «асинхронный» встречается 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()
>
> Это тоже частный случай монады, просто он более привычен людям, привыкшим к ООП.
Ох, ну классно! У нас, оказывается, повсюду монады :)
Вот всегда так в питоне. Берешь утюг и гладишь. А оказывается, это высокотехнологичный прибор с парогенератором низкого давления и прецизионным термостатом и некоторые диссертации на эту тему защищают.
Что-то мне подсказывает, в реальном мире не существует ни одной реальной задачи, где бы подобная магия была бы уместна. Разве что, как экзотическая зарядка для ума…
Хочу переголосовать :)
Хоть я и отметил сразу несколько (Управление проектами, Дизайн и проектирование и Python), но про Python конференций нету, а про Управление проектами и Дизайн и проектирование уже есть и не одна.
Я несколько неверно выразился. Конечно, UUID может генерить и БД — в каких-то случаях это более уместно. Другое дело, что если алгоритм тот же (или столь же годный), то этот UUID можно и клиентом генерить с тем же успехом. Особенно, если хранилище само этого не умеет.
Так это и есть UUID.
Тут надо понять, что UUID — это не какой-то конкретный алгоритм. Есть разные реализации и рекомендация RFC-4122. Более того, в общем смысле, UUID — это не обязательно 16 байт, можно и больше сделать, если необходимо.
Суть в том, что это идентификатор, который генерируется на клиенте и он гарантированно уникален.
Вы как-то жестко бредите заблуждаетесь…
С чего вы взяли, что генерация UUID это «очень дорогая» операцией? Вы точно не путаете UUID с хэш-функцией?
Я вам, без всякого сарказма, советую мысленно проделать следующее упражнение. Представьте программу на ассемблере, которая формирует UUID. Не в точности до команды, а просто «крупными мазками», чтобы оценить масштаб.
А после этого представьте всю махину TCP-стека — тоже на ассемблере.
И сравните, просто по количеству машинных команд, что «дороже» — сходить куда-то за значением по сети или просто его сгенерить.
Кажется, ребята из Twitter рассуждали также и поэтому сделали свой сервер, который генерирует ключи (см. ссылку в тексте).
Это, по сути, и есть тот самый «арбитр», про который вы говорите, только ходить к нему надо «до», а не «после» (откат закоммиченой транзакции — лучше про это не думать вообще, чтобы с ума не сойти).
Как по мне, такое решение ближе к централизованному генератору ключей — есть отдельный компонент, про который еще думать надо, А что будет, если он упадет?
Это заблуждение. UUID как раз и придуман для того, чтобы «проверка на сервере» была не нужна (она невозможна в распределенной системе).
Почитайте как устроен UUID и вы поймете, что надо как-то очень хитро стараться (например, крутить часы), чтобы получить хотя бы не нулевую вероятность сгенерировать два одинаковых UUID.
Ну, на самом деле я почти согласен везде UUID использовать. Но в том и дело, что не всегда получается или не всегда удобно.
> Требования по увеличения (вместо случайности) скорей всего не являются значимыми.
> В случае распределённых данных эти требования невозможно выполнить.
Распределение зачастую делается по хэшу, а не по самому ключу. Я имел ввиду ситуацию, когда у нас (на уровне приложения) уже есть список ключей, то иногда было бы круто при помощи простой сортировки получить их естественную последовательность.
> Но вообще статью нужно было бы начинать с того, что вы чем-то лучше Redis'а,
> хотя бы по производительности.
Я для себя решил, что нет смысла сравнивать инструменты в стиле «X, лучше чем Y».
Надо смотреть на возможности, стабильность, возможно, роадмэп. И, если не хочется первопроходцем — на то, кто уже это использует и для чего.
А «лучше-хуже» — это оценка применимости к конкретной задаче.
На счет производительности: в докладе кое-что есть. И это надо делать ну уж ооочень большую систему, чтобы имело забивать голову разницей в производительности ± 10 процентов. На мой взгляд фичи важнее (по-моему, потенциально самое полезное — это вторичные индексы).
Фразой про Nginx я как раз и хотел сказать, что пока славы и признания нет, и я хочу помочь этому проекту получить известность, а затем, возможно, признание и славу.
Мне реально по человечески очень интересно, почему список «Чем я могу помочь» у Вас вызвал отторжение (лучше не надо говорить от имени неких «читателей»).
Я делаю прямой призыв к сообществу: помогайте, кто чем может и совокупный результат достанется каждому. Повторюсь — я не имею никакого отношение к mail.ru.
У меня есть простой интерес: если проект получится раскачать, то я лично смогу пользоваться всеми благами open source, поддержкой сообщества и с уверенностью использовать эту систему в своих проектах.
И, поверьте, я свой вклад в этот open source проект вношу не только написанием статьи.
Я просто уверен, что название получилось так:
1. На листе бумаги нарисовали кружок: «это, типа, у нас ядро сервера»
2. К кружочку по сторонам подрисовали палочки «это, типа, TCP-коннекты»
Получился паучок. Потом игра слов: tul / tool
:-D
Кстати — это очень часто не принимают во внимание — узким и, потенциально, проблемным местом является не пропускная способность в запросах в секунду, а время отклика на один запрос. В многокомпонентных системах задержки (из-за промежуточной обработки, сетевого обмена и т.п.) вылезают раньше, чем чем будет достингнута предельньная пропускная способность одного компонента. А ведь, в конечном итоге, именно задержки ухудшают user experience.