Сегодня эта технология играет ключевую роль в сервисах, используемых миллиардами людей по всему миру.
Речь идёт о языке программирования Erlang.Читать полностью »
В.А.Крюков
Догмы спокойного прошлого не годятся для бурного настоящего.
А. Линкольн
«Предлагаемый труд вовсе не есть плод какого–нибудь «внутреннего побуждения»[1]Читать полностью »
Для протокола: заголовок я позаимствовал у Цицерона, в Oratio in Catilinam Prima in Senatu Habita.
В реальной жизни мы часто имеем дело с временны́ми интервалами. Свиданки с зубным врачом, бронирование гостиничных номеров, даже ежедневный обеденный перерыв: планирование всего этого — задача подгонки временно́го интервала в ряд других временны́х интервалов.
Вдруг вы не знали, но в языке, на котором вы пишите, вы можете использовать _ в цифрах. Например, следующий код на PHP:
<?php
print(1_00);
print(100);Выведет 100100 (проверить онлайн). Этот синтаксический сахар появился в Ada в 1980 году, и он имел переменный успех последние 40 лет. Но, за последний год его добавили в javascript, PHP, Go, Scala и даже консервативный Erlang. Я не могу объяснить, что послужило всплеском популярности, поэтому в статье просто опишу историю разделителей в цифрах.
12 июля 2018 года увидел свет первый коммит проекта :telemetry. Автор коммита — Аркадий Гил, но README утверждает, что авторское право принадлежит © 2018 Chris McCord and Erlang Solutions, а последний коммит по состоянию на сегодня был сделан Жозе Валимом.
Библиотека представляется следующим образом:
Telemetry — это динамическая библиотека диспетчеризации метрик и инструментария. Она легковесная, небольшого размера, и может быть использована в любом проекте эрланга иди эликсира.
Главным преимуществом библиотеки является то, что она действительно очень проста. Вы просто регистрируете событие, которое «состоит из числового значения и прикрепленных метаданных», и просто посылаете соответствующее сообщение всякий раз, когда это необходимо. Сообщение будет доставлено в обработчик, который может делать все, что угодно; обычно это запись в журнал или что-то типа того. Разделение бизнес-логики и метрик в лучшем виде.
Все свои публичные выступления (благо, их не так много) я начинаю с явного или неявного упоминания тезиса “Наша индустрия — сложная, проблемы могут вскрыться на любом, даже самом очевидном шаге, а оптимистично предполагать, что все будет просто и легко — наивно”. Как ни странно, эта простая мысль, полученная многолетним набиванием шишек, порой является откровением и для более опытных специалистов, хотя, казалось бы, весь оголтелый задор и вера в непогрешимость собственных идей и практик должна была выветриться уже давно. Расскажу байку на этот счет, пример простого, с первого взгляда, проекта.
Привет!
Если вы читали наши предыдущие посты (читали же?), то точно помните, что мы в RBK.money очень сильно за опенсорс. Настолько, что выложили в открытый доступ наш антифрод в виде открытых исходников под лицензией Apache 2.0.
Как вы понимаете, нам понравилось. Одного антифрода нам показалось мало, поэтому мы взяли и выложили в опенсорс всю нашу платежную платформу. Вообще всю. От самого первого микросервиса до навороченных систем аналитики, маршрутизации платежей, системы обработки и хранения карточных данных и десятков других микросервисов и пользовательских интерфейсов. Это именно тот код, на котором сейчас, в этот момент работает наш процессинг.
Зачем мы это сделали? Как это работает внутри? Как теперь жить дальше? Читайте под катом. Я гарантирую, что такого вы еще не встречали — еще никто в мире не опенсорсил платежную систему такого уровня.
История меняется прямо сейчас на ваших глазах!
Привет!
Не так давно мы писали в нашем блоге про антифрод и его устройство. В этом посте я хотел бы затронуть критерии идеального антифрода, который бы и клиентам жизнь упрощал, не блокируя платежи и при этом защищая их средства, и платежной системе время и ресурсы экономил. Мы поговорим о том, как относятся к фроду платежные системы и что может прилететь от них в сторону компании, как с фродом принято бороться сейчас и как бы хорошо это делать в будущем.
Добрый день! Хочу поделиться учебником-справочником знаний, которые мне удалось собрать по RabbitMQ и сжать в короткие рекомендации и выводы.
Хочешь сделать что-то полезное и рабочее — сделай его так, чтобы другие люди могли этим полноценно пользоваться, нормально это ревьювить, да и вообще вспоминать тебя добрым словом, а не темной стороной своего словарного запаса.
Для этого, кроме того, чтобы просто хорошо делать свою работу, писать правильный код, не бояться использовать современные технологии и в целом не тупить, надо обязательно обращать внимание на две штуки — документация и API. Без них человеку будет трудно понять, с чем вообще он имеет дело, как оно всё работает и что лучше не трогать вообще никогда. Конечно, можно гуглить, что обозначает та или иная спецификация, можно проверять в бою, чего и как (а потом так же бодро откатываться на предыдущую рабочую версию), но лучше, когда человеку дали подробную документацию.
Так вот, о чем я сегодня. В этом посте я расскажу, почему мы в RBK.money используем Swagger, как он помогает нам в работе и какие у него есть косяки.
