• Обновился наш плагин для Grafana — Statusmap panel 0.3.0
    0
    Огонь!
  • Обновился наш плагин для Grafana — Statusmap panel 0.3.0
    0
    Кажется, плагин перестал работать с Grafana 7.2 :-(
  • ExpvarMon — консольный мониторинг сервисов на Go
    0
    лучше бы это веб-морда была
  • Кластер, который всегда с собой
    0
    нет, не правильно
  • Реактивный манифест
    0
    В тексте слово «асинхронный» встречается 11 раз. И при внимательном чтении становится понятно, что авторы манифеста нигде не призывают писать код в асинхронном стиле (используя колбэки или future/deferred-магию).
    Но лучше бы они ограничились словами event-driven и concurrent.
  • Реактивный манифест
    +2
    В сфере финансов есть, например, системы автотрейдинга — там быть технологическим слоупоком не выгодно…
  • Взаимодействие клиентов SIP. Часть 1
    0
    Да что тут предложишь…
    Жалкое зрелище… Душераздирающее зрелище… Кошмар! © Ослик Иа
  • Взаимодействие клиентов SIP. Часть 1
    +1
    Одна из фундаментальных проблем SIP-а в том, что это нагормождение различных костылей. Эйфелева башня из костылей. Одна треть костылей устарела, другая треть — никогда не используется. Я занимаюсь VoIP с 1999 года и убедился, что никто из разработчиков — ни клиентов, ни серверов — целиком не понимает всего стэка. А, по правде говоря, никакого стэка и нету. Есть просто десятки разрозненных документов и какие-то реализации.

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

    Ох, как это знакомо :)
    Во всех подобных статьях и книгах про VoIP очень много внимания уделяется SIP-у, а про SDP и RTP никто не пишет — видимо, уже здоровья не хватает :)
    На самом деле реальный кошмар и хаос — это не сам SIP, а SDP и (как правило, кривые) реализации медиа-части в клиентах и серверах.
  • Невидимое око
    +2
    Как страшно жить…
  • Красной таблетки не существует
    +2
    Вам не повезло, если у вас сложилось мнение, что «процессы» — это «болтовня 100 часов в неделю».
    Эффективные процессы на то и эффективные, что они никого не задалбывают, а наоборот, помогают работать и получать наслаждение от стремительного развития проекта. Это как хороший дизайн, который не должен бросаться в глаза.

    А люди, которые не могут работать в команде по определенным правилам не просто разбегутся, а будут мной беспощадно уволены, ибо они неэффективны.
  • Красной таблетки не существует
    +21
    Я за статью поставил плюс, но, по-моему, от таких статей больше вреда чем пользы.

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

    Вы тут пишете про то, как сами перешли на третью стадию. А многие команды и разработчики даже и в первой стадии не находятся. Но, конечно, теперь им будет легче обосновать, почему надо забить на процессы и кодить как попало, без итераций, планирования, ретро и прочей «ненужной мишуры».
  • Кластер, который всегда с собой
    0
    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)
    и шлюз, который сказал провайдер.
  • Монады в Python поподробнее
    +2
    > Если объект имеет метод, который возвращает сам объект, мы можем писать так:
    > some_obj.set_name(«abc»).inrease_age().update_items([1,2,3]).validate().save()
    >
    > Это тоже частный случай монады, просто он более привычен людям, привыкшим к ООП.

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

    Вот всегда так в питоне. Берешь утюг и гладишь. А оказывается, это высокотехнологичный прибор с парогенератором низкого давления и прецизионным термостатом и некоторые диссертации на эту тему защищают.
  • Монады в Python поподробнее
    0
    Что-то мне подсказывает, в реальном мире не существует ни одной реальной задачи, где бы подобная магия была бы уместна. Разве что, как экзотическая зарядка для ума…
  • LTE от Yota в Москве уже с 15 апреля
    +2
    Так вот почему на конференции .тостер {Мобильные приложения} так обильно, под видом ценных призов, раздавались свистки Yota…
  • Какая тема конференции представляет для вас наибольший интерес?
    0
    Хочу переголосовать :)
    Хоть я и отметил сразу несколько (Управление проектами, Дизайн и проектирование и Python), но про Python конференций нету, а про Управление проектами и Дизайн и проектирование уже есть и не одна.
  • Уникальный ключ в условиях распределенной БД
    0
    о, спасибо, поправил
  • Уникальный ключ в условиях распределенной БД
    0
    А вот бы вы нарыли и нам рассказали? :)
  • Уникальный ключ в условиях распределенной БД
    0
    Это очень круто, что вы протестили!
    Очень интересно про python — можно посмотреть на тестовый код?
  • Уникальный ключ в условиях распределенной БД
    0
    Я несколько неверно выразился. Конечно, UUID может генерить и БД — в каких-то случаях это более уместно. Другое дело, что если алгоритм тот же (или столь же годный), то этот UUID можно и клиентом генерить с тем же успехом. Особенно, если хранилище само этого не умеет.
  • Уникальный ключ в условиях распределенной БД
    0
    Так это и есть UUID.
    Тут надо понять, что UUID — это не какой-то конкретный алгоритм. Есть разные реализации и рекомендация RFC-4122. Более того, в общем смысле, UUID — это не обязательно 16 байт, можно и больше сделать, если необходимо.
    Суть в том, что это идентификатор, который генерируется на клиенте и он гарантированно уникален.
  • Уникальный ключ в условиях распределенной БД
    +3
    Вы как-то жестко бредите заблуждаетесь…
    С чего вы взяли, что генерация UUID это «очень дорогая» операцией? Вы точно не путаете UUID с хэш-функцией?

    Я вам, без всякого сарказма, советую мысленно проделать следующее упражнение. Представьте программу на ассемблере, которая формирует UUID. Не в точности до команды, а просто «крупными мазками», чтобы оценить масштаб.
    А после этого представьте всю махину TCP-стека — тоже на ассемблере.
    И сравните, просто по количеству машинных команд, что «дороже» — сходить куда-то за значением по сети или просто его сгенерить.
  • Уникальный ключ в условиях распределенной БД
    0
    Именно так (генератором ключей назначена выделенная БД) делают в Flickr
    code.flickr.com/blog/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/
  • Уникальный ключ в условиях распределенной БД
    +1
    А, ну конечно. В том и затея — посмотреть на варианты и дельные комментарии, чтобы с умом разные варианты применять.
  • Уникальный ключ в условиях распределенной БД
    0
    Кажется, ребята из Twitter рассуждали также и поэтому сделали свой сервер, который генерирует ключи (см. ссылку в тексте).

    Это, по сути, и есть тот самый «арбитр», про который вы говорите, только ходить к нему надо «до», а не «после» (откат закоммиченой транзакции — лучше про это не думать вообще, чтобы с ума не сойти).
  • Уникальный ключ в условиях распределенной БД
    0
    Это вы про какой вариант?
  • Уникальный ключ в условиях распределенной БД
    0
    Как по мне, такое решение ближе к централизованному генератору ключей — есть отдельный компонент, про который еще думать надо, А что будет, если он упадет?
  • Уникальный ключ в условиях распределенной БД
    0
    Что за «случайный хэш» в СouchDB вы имеете ввиду?
  • Уникальный ключ в условиях распределенной БД
    0
    Да, пожалуй, естественный ключ можно рассматривать, как один из вариантов. Со своими плюсами и минусами.
  • Уникальный ключ в условиях распределенной БД
    +2
    В MongoDB ObjectId — 96 бит (12 байт) и скорее похож на самодельный UUID (который 16 байт).
  • Уникальный ключ в условиях распределенной БД
    +5
    Это заблуждение. UUID как раз и придуман для того, чтобы «проверка на сервере» была не нужна (она невозможна в распределенной системе).
    Почитайте как устроен UUID и вы поймете, что надо как-то очень хитро стараться (например, крутить часы), чтобы получить хотя бы не нулевую вероятность сгенерировать два одинаковых UUID.
  • Уникальный ключ в условиях распределенной БД
    0
    Ну, на самом деле я почти согласен везде UUID использовать. Но в том и дело, что не всегда получается или не всегда удобно.

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

    В Tarantool есть снапшоты и WAL. Данные, разумеется, должны влезать в память, поскольку это in-memory database.
  • Уникальные возможности Tarantool
    0
    > Но вообще статью нужно было бы начинать с того, что вы чем-то лучше Redis'а,
    > хотя бы по производительности.

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

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

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

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

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

  • Уникальные возможности Tarantool
    0
    > первичный всегда Hash
    Неа. Он только уникальным должен быть обязательно.
    Я пробовал — можно TREE сделать (выбирать диапазоны по первичному ключу).
  • Уникальные возможности Tarantool
    0
    Я просто уверен, что название получилось так:
    1. На листе бумаги нарисовали кружок: «это, типа, у нас ядро сервера»
    2. К кружочку по сторонам подрисовали палочки «это, типа, TCP-коннекты»
    Получился паучок. Потом игра слов: tul / tool
    :-D

  • Уникальные возможности Tarantool
    0
    Пожалуй, в таких доработках меру надо знать. А то выйдет «пилили-пилили… глядь — а получился MySQL 3.23 образца 2001 года» :)
  • Уникальные возможности Tarantool
    0
    Кстати — это очень часто не принимают во внимание — узким и, потенциально, проблемным местом является не пропускная способность в запросах в секунду, а время отклика на один запрос. В многокомпонентных системах задержки (из-за промежуточной обработки, сетевого обмена и т.п.) вылезают раньше, чем чем будет достингнута предельньная пропускная способность одного компонента. А ведь, в конечном итоге, именно задержки ухудшают user experience.
  • Уникальные возможности Tarantool
    –1
    Или я сам перепутал? :-)